Upload
others
View
11
Download
0
Embed Size (px)
Citation preview
REPUBLIKA E SHQIPËRISË
UNIVERSITETI I TIRANËS
FAKULTETI I EKONOMISË
DEPARTAMENTI I STATISTIKËS DHE INFORMATIKËS SË ZBATUAR
DISERTACION
ZHVILLIMI DHE TESTIMI I APLIKACIONEVE TË
BIZNESIT NË CLOUD
Në kërkim të gradës shkencore “Doktor i shkencave”
Kandidati: Udhëheqës:
Orges Çiço Prof. Dr. Zamir Dika
Tiranë 2019
i
DEKLARATË E ORIGJINALITETIT
Deklaroj me përgjegjësi të plotë që kontributet e dhëna në këtë punim janë tërësisht
origjinale dhe të prodhuara si rezultat i hulumtimeve shkencore të kryera. Materialet e
tjera të cilat kanë kontribuar në aspektet teorike në mbështetje të eksperimenteve të
kryera janë cituar në mënyrë të plotë dhe strikte, sipas rekomandimeve bashkëkohore
në kuadër të citimit të punimeve shkencore. Materiale të tjera ndihmëse të cilat kanë
lejuar në ndërtimin e këtij punimi mund të vendosen në dispozicion të lexuesit sipas
kërkesës.
Orges Çiço
Tiranë, 2019
© Copyright: Orges Çiço, Tiranë, 2019
Përmbajtja e këtij punimi është plotësisht autentike. Të gjitha të drejtat e rezervuara.
ii
ABSTRACT
Cloud-based system will shape the future of computing in the next generations to come. The novelty
started during the past decade due to the advantages cloud systems offer related to reduced setup time,
cost, high scalability, elastic resources on demand allocation with a pay-as-you-go fashion. Nowadays,
the main initial concerns in cloud systems have been related to security issues. However, recently the
need for high availability has become a hot topic which obviously has a direct cost impact. Cloud
providers face several challenges regarding the availability of their system in fulfilling the Service
Level Agreement (SLA). Developers could contribute while exploiting cloud Software as a Service
(SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS). Thus, moving business
applications, but not only, to the cloud will soon face the need for a framework and approaches to be
adopted to ensure the development of qualitative and highly reliable software. Plenty of scientific
researches and experiments have provided a proper evaluation of the different cloud infrastructure and
reliability. There have rarely been standardized fault tolerant techniques or evaluation of the current
ones on real case studies. In this dissertation work, it is presented the exploitation of the design, data
and temporal diversity and other similar Fault-Tolerant Techniques. The evaluation has been based on
the well-known Software Reliability Engineering (SRE) process widely discussed in the past 40 years.
Usually distributed applications represent a great challenge to build a correct and complete operational
profile, but in our experiments and evaluated systems, we have put our focus mainly on the most
critical operations and have applied the Fault Tolerant techniques only to the most critical components.
In order to address some of the challenges for business applications to be moved to the cloud, in this
dissertation we propose the concept of a new model Reliability as a Service (RaaS) on cloud software
systems. The idea is backed up by common fault tolerant approaches which should be adopted as part
of the cloud software system architecture in order to confirm reliability close to the five 9s (99,999%)
at software level as stated by the Software Availability Forum (SAF). Since there is no particular need
for every software system architecture, the RaaS could constitute the building blocks for highly
available cloud systems, by adopting and recommending possible optimal techniques. The flexibility in
adopting the approaches should become a balance between software development costs and reliability
requirements. Another significant contribution to the dissertation work is also the proposal and
implementation of the new cloud service model for cloud software development known as IDEaaS. The
service contributes to the emergence of new business models such as Pay as you go Coding (PaygoC)
and On Demand Coding (ODC). The dissertation backs up most of the statements on several case
studies where each chapter has answered the corresponding research questions and proved the
corresponding hypothesis derived from the research gap identified within the literature review.
Keywords: cloud computing, software reliability, fault tolerant software, high availability frameworks
iii
ABSTRAKT
Sistemet e bazuara në cloud do të ndikojnë në organizimin e gjeneratave të ardhshme të sistemeve
kompjuterike. Kjo risi ka nisur gjatë dekadës së kaluar si rezultat i përparësive që ofrojnë sistemet
cloud: kosto e ulët dhe konfigurim i shpejtë, përshkallëzim i lartë dhe burimeve të adoptueshme gjatë
alokimit dhe pagesës sipas përdorimit të tyre. Në ditët e sotme, problemet kryesore në sistemet cloud
janë të lidhura kryesisht me ato të sigurisë. Por, nevoja për një disponueshmëri të lartë është një
kërkesë e rëndësishme, e cila ka ndikim të drejtpërdrejtë në koston e shërbimit cloud. Ofruesit e cloud-
it përballen me disa sfida, të cilat lidhen me disponueshmërinë e sistemit në cloud si dhe përmbushjen e
Marrëveshjes Ofrues-Klient për nivelin e shërbimit (“Service Level Agreement” - SLA). Zhvilluesit e
softuerëve mund të kontribuojnë duke shfrytëzuar softuer si shërbim (“Software as a Service” - SaaS),
platformë si shërbim (“Platform as a Service” - PaaS) ose infrastruktura si shërbim (“Infrastructure as
a Service” - IaaS). Kështu, transferimi i aplikacioneve të bizneseve në cloud, së shpejti do të
ballafaqohet me nevojën për një strukturë sa më të mirë që të sigurohet zhvillimi i softuerit cilësor dhe
me besueshmëri të lartë. Shumë hulumtime dhe eksperimente bashkëkohore japin një vlerësim të plotë
të infrastrukturës cloud dhe besueshmërisë së saj. Megjithatë, duhet vënë në dukje se nuk ekziston një
standardizim i teknikave tolerante ndaj të metave apo një vlerësim i tyre në raste konkrete studimi në
cloud. Në punim parashtrohet shfrytëzimi dhe projektimi i teknikave të tolerancës ndaj të metave në
cloud. Vlerësimi i tyre bazohet në normat e vendosura nga Inxhinieria e besueshmërisë të softuerit
(“Software Reliability Engineering” - SRE), të përdorura gjerësisht 40 vitet e fundit. Aplikacionet e
shpërndara zakonisht paraqesin një sfidë komplekse në ndërtimin e një profili të saktë dhe të plotë
operacional. Ne, në eksperimentet dhe sistemet e vlerësuara, e kemi orientuar vëmendjen kryesisht
drejt operacioneve më kritike duke zbatuar teknikat tolerante ndaj të metave vetëm për komponentët
më kritikë. Gjithashtu në këtë punim propozojmë konceptin e një modeli të ri, besueshmëria si shërbim
(“Reliability as a Service” - RaaS), duke ju referuar disa prej sfidave në zhvendosjen e aplikacioneve
të biznesit në cloud. Koncepti mbështetet nga teknikat e tolerancës ndaj të metave, të cilat duhet të
miratohen si pjesë e arkitekturës softuerike të sistemit cloud për të konfirmuar një besueshmëri të rendit
me pesë nënta (99,999%) në nivelin e softuerit, siç vihet në dukje në forumin e disponueshmërinë të
softuerit (“Software Availability Forum” - SAF). Fleksibiliteti në adoptimin e qasjeve duhet të bëhet në
ekuilibër midis kostove të zhvillimit të softuerit dhe kërkesave të besueshmërisë. Një tjetër kontribut i
rëndësishëm në këtë punim është edhe propozimi dhe zbatimi i një modeli të ri shërbimi në cloud për
zhvillimin e softuerit i quajtur ambient i integruar i zhvillimit të kodit (“Integrated Development
Environment” - IDE) si shërbim (“Integrated Development Environment as a Service” – IDEaaS). Ky
lloj shërbimi ofron modele të reja të biznesit si “paguaj sipas kohës të kodimit” (“Pay as you go
Coding” - PaygoC) dhe kodim sipas kërkesës (“On Demand Coding” - ODC). Punimi mbështet
shumicën e propozimeve të mësipërme nëpërmjet disa rasteve studimore të lidhura me bizneset, ku në
çdo kapitull kanë marrë përgjigje pyetjet shkencore dhe janë vërtetuar hipotezat përkatëse të ngritura
nga ana jonë.
Fjalë Kyçe: “cloud computing”, besueshmëria e softuerit, toleranca ndaj të metave e softuerit,
struktura pune me disponueshmëri të lartë
iv
FALENDERIME
Rrugëtimi në përmbylljen e këtij punimi ka qenë sfidues dhe plot me entuziazëm. Të
shumtë janë ata që do doja të falënderoja, mbështetja e të cilëve e kanë bërë këtë
rrugëtim shkencor më të lehtë.
Fillimisht një falënderim i posaçëm shkon drejt udhëheqësit tim Prof. Dr. Zamir Dika,
i cili në mënyrë të vazhdueshme ka pasur besim të plotë në ecurinë time shkencore.
Vazhdimisht ai ka qenë pjesë e këtij rrugëtimi si në rekomandimet e vyera dhe me
pjesëmarrje aktive.
Falënderime të përzemërta i shkojnë babait tim Prof. Dr. Betim Çiço, që më ka
motivuar çdo ditë për të punuar me përkushtim dhe më ka mësuar pasionin e vërtetë
për kryerjen e një pune shkencore gjithnjë e më cilësore. Falë tij duhet të them që kam
arritur të jap maksimumin në këtë punim.
Një falënderim gjithashtu i sinqertë i shkon të gjithë kolegëve të Departamentit SIZ
duke përmendur në veçanti Prof. Dr. Kozeta Sevrani, e cila përveç mbështetjes të
dhënë ndër vite ka reflektuar dashamirësinë dhe suportin e plotë për angazhimin tim
në këtë departament.
Një falënderim tepër i veçante është për vajzën dhe bashkëshorten, të cilat më kanë
mirëkuptuar për momentet që nuk kam qenë pranë tyre gjatë orëve të gjata për
përfundimin e këtij punimi. Së bashku me to dua të falënderoj familjarët e mi të
dashur dhe të pandarë nga zemra ime qofshin afër apo larg, të pranishëm apo jo në
këtë rrugëtim.
v
PËRMBAJTJA
DEKLARATË E ORIGJINALITETIT ................................................................... I ABSTRACT .............................................................................................................. II ABSTRAKT............................................................................................................. III FALENDERIME..................................................................................................... IV PËRMBAJTJA ..........................................................................................................V LISTA E TABELAVE ......................................................................................... VIII LISTA E FIGURAVE............................................................................................. IX LISTA E SHKURTIMEVE ................................................................................... XI KAPITULLI 1: PËRMBLEDHJE E STUDIMIT .............................................. 1
1.1. Hyrje ....................................................................................................... 1 1.2. Qëllimi i studimit .................................................................................... 1 1.3. Objektivat e kërkimit .............................................................................. 2 1.4. Rishikimi i literaturës, pyetjet kërkimore dhe hipotezat ........................ 2 1.5. Metodologjia e përdorur ......................................................................... 3 1.6. Kontributet e studimit ............................................................................. 3 1.7. Publikime ................................................................................................ 7 1.8. Organizimi i punimit .............................................................................. 9
KAPITULLI 2: NJOHURITË THEMELORE ................................................. 10 2.1. Hyrje ..................................................................................................... 10 2.2. Përkufizime .......................................................................................... 10 2.2.1.1 Pamje historike e CC ....................................................................... 10 2.2.1.2 Përkufizimet dhe përparësitë e CC .................................................. 11 2.2.1.3 Arkitektura e CC ............................................................................. 12 2.2.1.4 Mjetet për zhvillimin në Cloud ....................................................... 14 2.2.1.5 Gjuhët dhe teknologjitë e programimit cloud .................................. 15 2.2.2.1 Pengesat: Të metat, gabimet dhe dështimet .................................... 16 2.2.2.2 Atributet: Disponueshmëria, besueshmëria, siguria, konfidencialiteti,
integriteti, mirëmbajtja ................................................................................. 18 2.2.2.3 Mjetet: parandalimi i të metave, largimi i të metave, toleranca ndaj të
metave, parashikimi i të metave/dështimeve ............................................... 19 2.2.3.1 Koha mesatare e dështimit të sistemit ............................................. 24 2.2.3.3 Mirëmbajtja ..................................................................................... 25 2.2.3.4 Disponueshmëria ............................................................................. 26 2.2.4 Modelet e besueshmërisë së softuerit ................................................. 27 2.2.5.1 Diversiteti në kohë ........................................................................... 27 2.2.5.2 Diversiteti në projektim ................................................................... 28 2.2.5.3 Redundanca ..................................................................................... 29 2.2.5.4 Riprodhimi i të dhënave .................................................................. 29 2.2.5.5 Monitorimi ....................................................................................... 30 2.2.5.6 Identifikimi i dështimeve ................................................................. 30 2.2.5.7 Rikuperimi ....................................................................................... 30 2.2.5.8 Blloqet e rikuperimit - RcB ............................................................. 31 2.2.5.9 Blloqet e shpërndarë të rikuperimit DRcB ...................................... 31 2.2.5.10 Blloqet e riprovës - RtB ................................................................. 31 2.2.5.11 Teknika të tjera .............................................................................. 31 2.3 Rishikimi Literaturës - Metodat më bashkëkohore të aplikuara në cloud
për zhvillimin e aplikacioneve tolerantë ndaj gabimeve ............................. 32 2.4 Procesi SRE adaptuar për aplikime me besueshmëri të lartë në cloud . 32 2.4.1 Përcaktimi i objektivit të besueshmërisë ............................................ 34
vi
2.4.1.1 Identifikimi i FSC ............................................................................ 34 2.4.1.2 Përcaktimi i FIO .............................................................................. 35 2.4.1.3 Zhvillimi i profilit operacional ........................................................ 35 2.4.2 Realizimi i testimit operacional .......................................................... 38 2.4.2.1 Krijimi i rasteve të testimit .............................................................. 40 2.4.3 Mbledhja e të dhënave dhe vlerësimi i parametrave .......................... 40 2.4.3.1 Të dhënat e dështimeve ................................................................... 40 2.4.4 Aplikimi i mjeteve të besueshmërisë së softuerit për të zgjedhur
modelet e duhura për vlerësimin e besueshmërisë ...................................... 41 2.4.5 Përcaktimi nëse objektivi i besueshmërisë është arritur ..................... 42 2.5 Përmbledhje ........................................................................................... 42
KAPITULLI 3: TESTIMI I BESUESHMËRISË TË SOFTUERIT - RASTE
STUDIMI .............................................................................................. 44 3.1. Hyrje ..................................................................................................... 44 3.2. Zhvillimi i sistemeve të besueshme IoT. Rast studimi: ’SunProtect UV’
44 3.2.1 Konceptimi i sistemit .......................................................................... 44 3.2.2 Rasti studimit: SunProtect UV ........................................................... 46 3.3 Testimi i besueshmërisë të një sistemi satelitor .................................... 50 3.3.1 Përgatitja eksperimentale dhe vlerësimi ............................................. 50 3.3.2.1 Zhvillimi i profilit operacional për ACS ......................................... 53 3.3.2.2 Rezultatet e testimit të ACS ............................................................ 53 3.4 Performanca dhe testimi i ngarkesës së platformave cloud përkundrejt
serverëve klasikë. Rast studimi: Aplikimi i një rrjeti social ........................ 56 3.4.1 Aplikacioni dhe përshkrimi funksional i platformës .......................... 56 3.4.1.1 Zhvillimi i profilit operacional .................................................... 57 3.5 Përmbledhje ........................................................................................... 60
KAPITULLI 4: BESUESHMËRIA SI MODEL SHËRBIMI - RAAS ........... 61 4.1. Hyrje ..................................................................................................... 61 4.2. Modeli dhe ambient i punës të RaaS .................................................... 61 4.2.1. Besueshmëria si model shërbimi në cloud - RaaS ............................ 61 4.2.2. Besueshmëria si model strukture në cloud ........................................ 62 4.2.3. Rast studimi: “WINDFARMDESIGNS” .......................................... 63 4.2.4. Krahasimi i rezultateve ...................................................................... 68 4.3. Diskutime ............................................................................................. 69 4.4. Përmbledhje .......................................................................................... 69
KAPITULLI 5: MJEDISI I ZHVILLIMIT TË INTEGRUAR SI NJË
SHËRBIM - IDEAAS ............................................................................................. 71 5.1. Hyrje ..................................................................................................... 71 5.2.1. IDEaaS - Modeli i propozuar ............................................................ 72 5.3. Metodologjia e implementimit ............................................................. 72 5.4. Përgatitja e eksperimentit dhe vlerësimi i strukturës të propozuar ...... 75 5.4.1. Migrimi i GAE në cloud .................................................................... 75 5.4.2. Funksionalitetet e ofruara .................................................................. 76 5.4.3. Arkitektura e përdorur ....................................................................... 78 5.4.4. Modelet e biznesit për sistemet e informacionit të bazuar në cloud . 80 5.5. Përmbledhje .......................................................................................... 84
KAPITULLI 6: PËRFUNDIME DHE OBJEKTIVA PËR TË ARDHMEN . 85 6.1. Përfundime ........................................................................................... 85
vii
6.2. Objektiva për të ardhmen ..................................................................... 86 REFERENCAT ....................................................................................................... 87
APENDIKS / SHTOJCA ............................................................................. 91 Shtojca A ..................................................................................................... 91
viii
LISTA E TABELAVE
Tabela 2-1: Gjuhët e programimit në PaaS për ofrues të ndryshëm të shërbimeve
cloud ............................................................................................................................. 15
Tabela 2-2: Klasifikimi i klasave të riskut së sistemit ................................................. 35
Tabela 2-3: Klasifikimi i klasave të riskut së sistemit ................................................. 36
Tabela 2-4: Tabela operacionale .................................................................................. 37
Tabela 2-5: Dokumentimi i rasteve të testimit ............................................................. 40
Tabela 3-1: Tabela e shërbimit GATT ......................................................................... 47
Tabela 3-2: Raportimi i FSC-ve të mundshme ............................................................ 52
Tabela 3-3: Profili i Operacional të ACS ..................................................................... 53
Tabela 3-4: Shëmbull dokumenti testimi ..................................................................... 54
Tabela 3-5: Dokumenti përmbledhës i testimeve ........................................................ 55
Tabela 3-6: Krahasimi i platformave cloud vs server klasik ....................................... 57
Tabela 3-7: Profili operacional për 30 përdorues ........................................................ 57
Tabela 3-8: Profili operacional për 200 përdorues ...................................................... 58
Tabela 4-1: Profili Operacional ................................................................................... 65
Tabela 4-2: Rezultatet e testimeve ............................................................................... 67
Tabela 4-3: Teknikat e tolerancës ndaj gabimeve adaptuar nëpërmjet një strukture
cloud ............................................................................................................................. 69
Tabela 4-4: Gjuhët e programimit në PaaS për ofrues të ndryshëm të shërbimeve
Cloud ............................................................................................................................ 69
ix
LISTA E FIGURAVE
Figura 2-1 Paraqitje eliptike e shërbimeve cloud dhe ndërlidhja e tyre me përdoruesit
fundor ........................................................................................................................... 13
Figura 2-2 Varësia: Pengesat, atributet, mënyrat, modelet .......................................... 16
Figura 2-3 Marrëdhënia ndërmjet të metës, gabimit, dështimit ................................... 17
Figura 2-4 Marrëdhënia ndërmjet të metave, gabimeve dhe dështimeve brenda një
komponenti softuerik ................................................................................................... 18
Figura 2-5 Hapat e tolerancës ndaj gabimeve .............................................................. 21
Figura 2-6 Paraqitja grafike e besueshmërisë .............................................................. 22
Figura 2-7 Paraqitja grafike e mungesës të besueshmërisë ......................................... 23
Figura 2-8 Paraqitja grafike e mungesës të besueshmërisë ......................................... 23
Figura 2-9 Paraqitja grafike e MTTF, MTTR dhe MTBR........................................... 26
Figura 2-10 Diversiteti në kohë me hyrje të njëjta ...................................................... 28
Figura 2-11 Diversiteti në kohë me hyrje të njëjta ...................................................... 29
Figura 2-12 Procesi SRE .............................................................................................. 33
Figura 2-13 Hapat e ndërtimit të profilit operacional .................................................. 38
Figura 2-14 Shpërndarja e rasteve të testimit .............................................................. 39
Figura 3-1 Arkitektura e adoptuar për të ndërlidhur infrastrukturën ekzistuese cloud
me pajisjet embedded duke u mbështetur në protokollin e komunikimit BLE ............ 45
Figura 3-2 Arkitektura e sistemit IoT .......................................................................... 46
Figura 3-3 Programimi i pajisjes nëpërmjet Nordic Semiconductor Development Kit
...................................................................................................................................... 47
Figura 3-4 Arkitektura e aplikacionit mobile SunProtectUV ...................................... 49
Figura 3-5 Arkitektura e aplikacionit mobile SunProtectUV ...................................... 49
Figura 3-6 Arkitektura e aplikacionit në Google cloud ............................................... 50
Figura 3-7 Diagrami i rasteve të përdorimit për ACS .................................................. 51
Figura 3-8 Diagrami i klasave për ACS ....................................................................... 51
Figura 3-9 Diagrami i bllokut të besueshmërisë të komponentëve të sistemit të
softuerit ACS ............................................................................................................... 52
Figura 3-10 Rastet e përfunduara të testimit ................................................................ 55
Figura 3-11 Testi i performancës cloud përkundrejt serverit për 30 dhe 200 përdorues.
...................................................................................................................................... 59
Figura 4-1 Besueshmëria si model shërbimi në cloud RaaS ........................................ 62
Figura 4-2 Besueshmëria si model shërbimi në cloud RaaS ........................................ 63
Figura 4-3 Ndërfaqja WINDFARMDESIGNS duke përpunuar të dhënat e
pozicionimit të turbinave të erës .................................................................................. 64
Figura 4-4 Diagrami i rasteve të përdorimit ................................................................ 64
x
Figura 4-5 Diagrami sekuencial ................................................................................... 65
Figura 4-6 Diagrami i komponentëve të “Windfarmdesings” ..................................... 66
Figura 4-7 Rezultatet e testimeve ................................................................................ 68
Figura 5-1 Platforma IDEaaS ....................................................................................... 73
Figura 5-2 IDE si SaaS ................................................................................................ 74
Figura 5-3 IDE si shtresë shërbimi në cloud ................................................................ 74
Figura 5-4 Përdorimi i OAuth2 për autentifikimin e serverit web ............................... 77
Figura 5-5 Karakteristikat e zhvilluara aktualisht të SDK online ................................ 78
Figura 5-6 Arkitektura e adaptuar e GAE Launcher bazuar në modelet IDEaaS ........ 79
Figura 5-7 Integrimi i IDEaaS me shërbimet bazë të cloud për menaxhimin dhe
vendosjen e kodit ......................................................................................................... 80
Figura 5-8 IDE online si pjesë e shërbimeve bazë të cloud ......................................... 80
Figura 5-9 Modelet e biznesit PaygoC dhe ODC ........................................................ 82
Figura 5-10 Të ardhurat nga Google dhe AWS të marra nga Statista ......................... 83
Figura 5-11 Të ardhurat nga Google dhe AWS të marra nga Statista ......................... 83
xi
LISTA E SHKURTIMEVE
ACS Attitude Control System
API Application Programming Interface
AT Acceptance Test
AWS Amazon Web Services
BLE Bluetooth Low Energy
C/S Client Server
CASRE Computer Aided Software Reliability Engineering
CASE Computer Aided Software Engineering
CC Cloud Computing
CLI Command Line Interface
CPU Central Processing Unit
DRcB Distributed Recovery control Block
FIO Failure Intensity Objective
FMEA Failure Mode Effect Analysis
FSC Failure Severity Class
FTA Fault Tree Analysis
GAE Google App Engine
GAP Generic Access Profile
GATT Generic Attribute Profile
GCE Google Compute Engine
GCS Google Cloud Storage
GCSQL Google Cloud Structured Query Language
GUI Graphical User Interface
HR High Reliability
I/O Input/Output
IDE Integrated Development Environment
IDEaaS Integrated Development Environment as a Service
IoT Internet of Things
ISO International Organization for Standardization
IaaS Infrastructure as a Service
KLOC Kilo Lines of Code
MATLAB Matrix Laboratory
MBaaS Mobile Backend as a Service
NCP N-copy programming
xii
NVP N-Version Programming
ODC On Demand Coding
OS Operating System
PaygoC Pay as you go Coding
PM Project Management
PaaS Platform as a Service
RBD Reliability Block Diagram
RcB Recovery control Block
REST Representational state transfer
RtB Retry control Block
RaaS Reliability as a Service
SAF Service Availability Forum
SDK Software Development Kit
SLA Service Level Agreement
SoC System on Chip
SRE Software Reliability Engineering
SaaS Software as a Service
URI Uniform Resource Identifier
UV Ultra Violet
V&V Verification and Validation
VM Virtual Machine
WDT Watch Dog Timer
1
KAPITULLI 1: PËRMBLEDHJE E STUDIMIT
1.1. Hyrje
Sistemet e bazuara në cloud do të ndikojnë në organizimin e gjeneratave të ardhshme
të sistemeve kompjuterike. Kjo risi ka nisur gjatë dekadës së kaluar si rezultat i
përparësive që ofrojnë sistemet cloud: kosto e ulët dhe konfigurim i shpejtë;
përshkallëzim i lartë dhe burime të adoptueshme gjatë alokimit dhe pagesë sipas
përdorimit të tyre. Në ditët e sotme, problemet kryesore në sistemet cloud janë të
lidhura kryesisht me ato të sigurisë. Por, nevoja për një disponueshmëri të lartë është
një kërkesë e rëndësishme, e cila ka ndikim të drejtpërdrejtë në koston e shërbimit
cloud. Ofruesit e cloud-it përballen me disa sfida, të cilat lidhen me disponueshmërinë
e sistemit në cloud si dhe përmbushjen e Marrëveshjes Ofrues-Klient për Nivelin e
Shërbimit (“Service Level Agreement” - SLA). Zhvilluesit e softuerëve mund të
kontribuojnë duke shfrytëzuar Softuer si Shërbim (SaaS), Platformë si Shërbim
(PaaS) ose Infrastruktura si Shërbim (IaaS). Kështu, transferimi i aplikacioneve të
bizneseve në cloud, së shpejti do të ballafaqohet me nevojën për një strukturë sa më të
mirë që të sigurohet zhvillimi i softuerit cilësor dhe me besueshmëri të lartë. Shumë
hulumtime dhe eksperimente bashkëkohore japin një vlerësim të plotë të
infrastrukturës cloud dhe besueshmërisë së saj.
Megjithatë, duhet vënë në dukje se nuk ekziston një standardizim i teknikave tolerante
ndaj gabimit apo një vlerësim i tyre në raste konkrete studimi në cloud. Në punim
parashtrohet shfrytëzimi dhe projektimi i teknikave të tolerancës ndaj të metave në
cloud. Vlerësimi i tyre bazohet në normat e vendosura nga inxhinieria e besushmërisë
të softuerit (“Software Reliability Engineering” – SRE), të përdorura gjerësisht 40
vitet e fundit. Aplikacionet e shpërndara zakonisht paraqesin një sfidë komplekse në
ndërtimin e një profil të saktë dhe të plotë operacional. Ne, në eksperimentet dhe
sistemet e vlerësuara, e kemi orientuar vëmendjen kryesisht drejt operacioneve më
kritike duke zbatuar teknikat tolerante ndaj gabimeve vetëm për komponentët më
kritikë. Gjithashtu propozojmë në këtë punim konceptin e një modeli të ri, duke iu
referuar disa prej sfidave në zhvendosjen (transferimin) e aplikacioneve të biznesit në
cloud: Besueshmëria si Shërbim (RaaS) në sistemet softuerike cloud. Koncepti
mbështetet nga teknikat e tolerancës ndaj të metave, të cilat duhet të miratohen si
pjesë e arkitekturës softuerike të sistemit cloud për të konfirmuar një besueshmëri të
rendit me pesë nënta (99,999%) në nivelin e softuerit, siç vihet në dukje në Forumin e
Disponueshmërinë të Softuerit (“Software Availability Forum” - SAF). Fleksibiliteti
në adoptimin e qasjeve duhet të ofrojë një ekuilibër midis kostove të zhvillimit të
softuerit dhe kërkesave të besueshmërisë. Punimi mbështet shumicën e propozimeve
të mësipërme nëpërmjet disa rasteve studimore të lidhura me bizneset.
1.2. Qëllimi i studimit
Qëllimet e këtij punimi janë:
• Rritja e interesit për zhvillim të Sistemeve të Informacionit në Cloud për
bizneset.
2
• Rritja e besueshmërisë të përdorimit të Cloud-it nëpërmjet shërbimeve,
modeleve si dhe strukturave të reja.
1.3. Objektivat e kërkimit
Ky studim do të realizohet përmes arritjes sipas objektivave në vijim:
• Parashtrimi i shërbimeve të reja në cloud së bashku me strukturat
(“framework-et”) përkatëse për të thjeshtësuar implementimin e Sistemeve të
Informacionit me besueshmëri të lartë, duke marrë parasysh aspektet kryesore,
që lidhen me besueshmërinë e softuerit dhe disponueshmërinë e tyre në
infrastrukturën e Cloud-it sipas SLA.
• Implementimi konkret i zgjidhjeve nëpërmjet rasteve të studimit për
aplikacione cloud të bizneseve ekzistuese.
• Propozimi i zgjidhjeve të qëndrueshme në të ardhmen për zhvillimet e
sistemeve cloud, që sigurojnë besueshmëri të lartë.
1.4. Rishikimi i literaturës, pyetjet kërkimore dhe hipotezat
Në mjediset cloud, burimet në dispozicion mundësojnë implementimin e
aplikacioneve me tolerancë ndaj të metave. Si plotësim i përpjekjeve të mëparshme
kërkimore, të cilat janë kryesisht të përqendruara në hartimin e strategjive të
tolerancës ndaj të metave, ne kemi identifikuar nevojën për dy shërbime të reja cloud:
1. Besueshmëria si shërbim (“Reliability as a Service” - RaaS)
2. Mjedis i integruar i zhvillimit si shërbim (IDEaaS)
Dhe modelet e biznesit ku ato mund të mbështeten:
1. Paguaj për kohën e kodimit (“Pay as you go Coding” - PaygoC)
2. Kodim sipas kërkesës (“On Demand Coding” - ODC)
modele këto të mbështetura nga një infrastrukturë online për ndërtimin e
aplikacioneve tolerante ndaj gabimeve në cloud. Të dy shërbimet e ofruara duhet të
lehtësojnë zhvillimin e aplikacioneve për bizneset dhe të përmirësojnë mundësinë e
përdorimit të teknikave tolerante ndaj të metës. Në literaturën e shfletuar nuk
paraqiten mjaftueshëm shfrytëzimi i teknikave ekzistuese të tolerancës të të metave të
softuerit për të përmirësuar disponueshmërinë e përgjithshme të sistemit, për
aplikacionet e biznesit që funksionojnë në cloud. Testimi i besueshmërisë mund të
sigurojë vlerë të shtuar për aplikimin e biznesit që do të zhvendoset në cloud, por lind
nevoja për adoptimin e teknikave të tilla në rastet e studimeve reale. Krijimi i
infrastrukturave dhe shërbimeve do të lehtësonte shfrytëzimin e këtyre teknikave.
Gjatë studimit është shfletuar një literaturë e gjerë. Bazuar në diskutimet e mësipërme
si dhe hulumtimin e literaturës bashkëkohore, u formuluan dhe u parashtruan pyetjet
kërkimore dhe hipotezat e mëposhtme:
Pyetja 0: A e përmbushin shërbimet aktuale nevojën e bizneseve për implementimin e
sistemeve të informacionit në cloud?
Hipoteza 0: Shërbimet e reja e rrisin besueshmërinë e bizneseve për implementimin e
sistemeve të informacionit në cloud.
3
Pyetja 1: Cilat janë mënyrat dhe mjetet për zhvillimin e aplikacioneve në cloud dhe si
bizneset mund t’i shfrytëzojnë ato?
Hipoteza 1: Mundësia për zhvillim të drejtpërdrejtë të aplikacioneve në cloud në
formën e shërbimit rrit interesin e bizneseve për migrim të sistemeve të informacionit.
Pyetja 2: A janë teknikat për testimin e besueshmërisë të softuerit në cloud të
përshtat- shme për rritjen e pranueshmërisë të tyre në biznese?
Hipotezat 2: Teknikat e tolerancës ndaj të metave në kuadër të testimit për
besueshmërinë e softuerëve në cloud rrisin pranueshmërinë e zhvillimit të sistemeve të
informacionit në cloud.
Pyetja 3: Cilat janë përfitimet për bizneset dhe vetë cloud-in nga përdorimi i
shërbimeve për zhvillimin e aplikacioneve drejtpërdrejt në cloud të kombinuara me
teknikat e tolerancës ndaj të metave?
Hipoteza 3: Zhvillimi i aplikacioneve në mënyrë të drejtpërdrejt në cloud minimizon
kostot paraprake për bizneset dhe rrit kapacitetin për menaxhim projekti si dhe të
ardhurat për vetë ofruesit e shërbimeve në cloud.
1.5. Metodologjia e përdorur
Metodologjia e ndjekur në zhvillimin e këtij studimi pas rishikimit të literaturës
bashkëkohore është mbështetur në pesë hapa kryesorë:
1. Përzgjedhja e procesit më të përshtatshëm për tu përdorur në testimin e
besueshmërisë të aplikacioneve në cloud. Në këtë rast është përdorur SRE e
propozuar nga (Lyu and others 1996).
2. Vlerësimi paraprak i këtij procesi nëpërmjet rasteve të studimit për aplikacione
reale në fusha të ndryshme zbatimi.
3. Përdorimi i teknikave tolerante ndaj të metave, pjesë e procesit SRE, për
rritjen e besueshmërisë të aplikacioneve në cloud për bizneset.
4. Realizimi i një pyetësori në rajonin e Ballkanit për të vlerësuar nevojën e
këtyre shërbimeve.
5. Ndërtimi i platformave dhe strukturave të punës eksperimentale për të
mundësuar zhvillimin e kodit (IDEaaS) dhe tolerancën ndaj të metave (RaaS)
si pjesë e shërbimeve kryesore të cloud.
6. Propozimi i modeleve ekonomike PaygoC dhe ODC për shfrytëzimin e këtyre
platformave.
Nga propozimet e bëra si dhe nga eksperimentet e kryera, është mundësuar hedhja e
hapave kryesorë drejt parashtrimit të metodologjisë dhe infrastrukturës të aplikimit të
metodave tolerante ndaj të metave për sistemet e informacionit në cloud. Duke rritur
besueshmërinë e përdorimit të tyre nga bizneset dhe sistemet me kërkesa kritike.
1.6. Kontributet e studimit
Disa prej kontributeve kryesore në këtë disertacion, bazuar në sfidat e identifikuara në
literaturë si dhe pyetjet, hipotezat shkencore të parashtruara në seksionet e
mëparshme, janë:
4
• Modele dhe teknikat për të vlerësuar besueshmërinë e sistemeve
softuerike. Rast Studimi: Sistemi i kontrollit satelitor
Qëllimi kryesor i këtij punimi është vlerësimi i teknikave të besueshmërisë të softuerit
si dhe vlerësimi i efektivitetit të tyre nëpërmjet rasteve të studimit konkrete. SRE ka si
sfidë kryesore realizueshmërinë e tij në projekte reale. Si pengues kryesor mund të
përmendim koston e lartë për implementimin e softuerit, kompleksitetin e teknikave të
përdorura, aplikimin në mjedise të ndryshme si dhe kualifikimin e stafit të përfshirë.
Ndryshe nga vlerësimi i besueshmërisë të harduerit, i cili është trajtuar gjerësisht
gjatë dekadave të fundit, softueri paraqet disa sfida për shkak të natyrës së tij jo-
materiale. Shumica e modeleve dhe teknikave janë përshtatur nga ato të tolerimit të
gabimeve/dështimeve të huazuara nga hardueri, të cilat janë aktualisht në përdorim.
Megjithatë, efikasiteti i tyre duhet ende të provohet nëpërmjet rasteve konkrete të
studimeve, sidomos për sisteme softuerike me natyrë kritike. Modelimi dhe testimi i
besueshmërisë të sistemit të kontrollit (“Attitude Control System” - ACS) të një nano
sateliti përbën një rast studimi të këtij punimi. Metodologjia për vlerësimin e
besueshmërisë është bazuar në Procesin e SRE (“SRE Process”).
• Zhvillimi i sistemeve të besueshëm IoT për përmirësimin e cilësisë së jetës
përmes shfrytëzimit cloud, mobile dhe teknologjive BLE. Rast i studimit:
Sun-Protect UV
Ndërlidhja e objekteve të ndryshme inteligjente në një ekosistem gjithashtu inteligjent
përbën një prirje të njohur tashmë si internet i pajisjeve (“Internet of Things” - IoT).
Ky ekosistem lehtëson përdorimin e pajisjeve të lëvizshme, cloud dhe atyre të
integruara. Gjithashtu kjo prirje ka lejuar, që të trajtohen fusha si shëndetesia, cilësia e
jetës, qytetet inteligjente (smart cities), etj. Në këtë punim ne parashtrojmë një rast
studimi, i cili bazohet në një aplikacion mobile, cloud dhe pajisjeve të integruara për
të siguruar shëndetin e lëkurës të individëve, që janë të ekspozuar ndaj diellit për
periudha të gjata kohore. Ky punim nuk paraqet vetëm inovacionin teknologjik, por
edhe përftimet shëndetësore që lidhen me këtë sistem inteligjent.
• Performanca dhe testimi i ngarkesës cloud përkundrejt platformave
bazuar në server klasik. Rast studimi: Aplikimi i një rrjeti social
Migrimi nga platformat e serverit klasik në teknologjitë e reja cloud kanë qenë sfidat
më të zakonshme gjatë viteve të fundit. Shumë biznese dhe përdorues fundor janë të
interesuar për atë që tashmë cloud ofron. Zhvendosja e biznesit dhe të dhënave në një
platformë të re cloud përmban disa sfida për t’u kapërcyer, të tilla si siguria,
integriteti, besueshmëria dhe përshkallëzimi. Shumica e kompanive që ofrojnë
zgjidhje cloud, pretendojnë se kanë kapërcyer shumë pengesa duke siguruar një
infrastrukturë plotësisht elastike, por këto pretendime duhet të provohen nëpërmjet
rasteve konkrete studimore si dhe qasjeve ekzistuese në inxhinierine e softuerit. Në
këtë punim ne paraqesim matjet e përftuara nga testimi i ngarkesës dhe performancës
të të dyja infrastrukturave, cloud dhe server klasik, duke ofruar një krahasim ndërmjet
dy platformave për të njëjtin shërbim ndaj përdoruesve fundorë. Rasti i studimit të
përzgjedhur, një rrjet social universitar, është mjaft i përshtatshëm për të nxjerr në pah
një vlerësim në lidhje me domosdoshmërinë e përshkallëzimit të infrastrukturës cloud
përkundrejt serverëve klasik. Ky rast studimi jo vetëm konfirmon rezultatet nga autorë
5
të mëparshëm, por parashtron dhe pyetje të tjera në aspektin e kostove, besueshmërisë
dhe qasjeve më të përshtatshme për implementime në të ardhmen.
• Teknikat e tolerimit të të metave/dështimeve të diversitetit në kohë dhe të
dhënave të përdorura për të rritur besueshmërinë e aplikacioneve cloud.
Rast Studimi: Windfarmdesigns
Infrastruktura cloud shfrytëzohet gjerësisht në nivel softueri si shërbim (SaaS), për
aplikime të cilave ju nevojitet një përshkallëzim i lartë i burimeve kompjuterike.
Megjithatë, zhvillimi i aplikacioneve të shpërndara në cloud ballafaqohet me sfida, të
cilat derivojnë si rrjedhojë e limitimeve të vetë infrastrukturës apo gabimeve në
nivelin e rrjetit. Ekzistojnë disa qasje të cilat mund të ndihmojnë në shmangien
plotësisht të këtyre gabimeve. Dy më kryesoret, të cilat vlejnë të përmenden, janë
diversiteti në kohë dhe ai në projektim. Të dy këto teknika të tolerimit ndaj gabimeve
të përdorura gjatë zhvillimit të sistemit softuerik, kanë provuar efikasitetin e tyre të
lartë. Ky punim ka si qëllim zbatimin e këtyre dy teknikave, gjerësisht të përdorura
për sistemet harduer, nëpërmjet një rasti studimi konkret në cloud, duke rritur
besueshmërinë e aplikacioneve cloud. Aplikacioni cloud Windfarmdesigns është
zhvilluar në gjuhën e programimit Python dhe ambientin e punës Django. Në këtë
aplikacion është shfrytëzuar teknika e tolerimit të përkohshëm për të reduktuar
gabimet apo dështimet, që vijnë nga infrastruktura cloud. Ndërkohë teknika tjetër e
përdorur është ajo e diversitetit në projektim, e cila është adoptuar për komponentë
softuerik të lidhura me përllogaritje algoritmike të fuqishme. Të dyja teknikat kanë
siguruar një përmirësim të besueshmërisë të sistemit softuerik. Nga kjo pikëpamje ato
mund të jenë gjithashtu një qasje e mirë për të ardhmen në implementimin e
aplikacioneve cloud
• Qasja me besueshmëri të lartë në aplikimet cloud për bizneset -
Besueshmëria si model shërbimi (RaaS)
Në ketë punim prezantojmë konceptin e një modeli të ri RaaS në sistemet e softuerëve
cloud. Aplikacionet e shpërndara zakonisht paraqesin një sfidë të madhe për të
ndërtuar një profil operacional korrekt dhe të plotë, por në rastin e studimit tonë kemi
marrë në shqyrtim operacionet më kritike dhe kemi zbatuar teknikat e përmendura më
parë vetëm për komponentët më kritike të sistemit softuerik. Windfarmdesigns është
zhvilluar nëpërmjet ‘framework-ut Django’. Softueri përfshin një algoritëm unik që
kryen optimizimin e vendosjes të turbinave në një kamp ere (wind farm layouts).
Algoritmi është implementuar nga dy ekipe zhvillimi në dy gjuhë programimi të
ndryshme Python dhe MATLAB (“Matrix Laboratory” - MATLAB), bazuar në
teknikën e diversitetit në projektim me N-Versione. Algoritmet ekzekutohen
paralelisht në të njëjtën instancë të GCE (“Google Compute Engine” - GCE).
Arkitektura e shpërndarë e sistemit është një shembull i mirë për të provuar
efikasitetin e teknikave të diversitetit në kohë dhe të te dhënave për të përmirësuar
disponueshmërinë/besueshmërinë e sistemit në përgjithësi. Këto teknika mund të
aplikohen në nivel krijimi të instancave të makinave virtuale në cloud. Pra, teknikat e
tjera të aplikuara lidhen me diversitetin në kohë dhe atë të të dhënave, të cilat bazohen
në blloqet e kontrollit për riprovim dhe rikuperim (“Retry control Block” - RtB,
“Recovery control Block” - RcB) gjatë krijimit të instancave cloud. Të gjitha teknikat
6
e zbatuara dhe metodologjia e propozuar nga procesi SRE dëshmojnë për efikasitetin
e tyre gjatë eksperimenteve të kryera.
• Mjedisi i zhvillimit të integruar si një shërbim (IDEaaS) - Modelet dhe
arkitekturat - Migrimi i Google cloud IDE/SDK në cloud
Ky punim propozon zbatimin e një shërbimi të ri IDEaaS si pjesë e shërbimeve
ekzistuese të cloud. Ne kemi hulumtuar ofruesit kryesor të cloud (Amazon, Google,
Azure) si dhe qasjet e tyre ekzistuese për zhvillimin e softuerëve. Disa kanë provuar
të jenë më të avancuar ndër të tjerët, por asnjëri prej tyre nuk ka integruar plotësisht
një mjedis bashkëpunues për zhvillimin e kodit drejtpërdrejt në infrastrukturën cloud.
Deri më tani janë adoptuar zgjidhje sipas rastit (“ad-hoc”), ose zgjidhje të bazuara në
palë të treta. Sidoqoftë, të dy alternativat nuk kanë arritur të ofrojnë një integrim të
plotë me infrastrukturën e cloud ose nuk ofrojnë një model të duhur biznesi, që u
përshtatet më së miri qiramarrësve cloud apo përdoruesve fundorë. Ky punim
përshkruan arkitekturën IDEaaS dhe krahason dy modele të mundshme për të
integruar mjedisin e zhvillimit të kodit në cloud, duke u bërë kështu pjesë e
infrastrukturës së re cloud si një SaaS, ose si një shërbim i ri në vetvete. Integrimi i
IDE ofrohet gjithashtu nëpërmjet një shërbimi eksperimental që funksionon në GAE
("Google App Engine" – GAE) të quajtur “GAE Launcher”. Mjeti është transferuar
nga versioni i tij desktop në platformën cloud duke ofruar si funksione të ngjashme
me ato ekzistuese, po ashtu dhe funksione të reja. Aktualisht ky mjet funksionon me
(“Software Development Kit” - SDK) të Python, por mund të shtohen dhe gjuhë të
tjera programimi me të njëjtën qasje. Struktura e re lejon gjithashtu krijimin e
modeleve të reja të biznesit, të ngjashme me ato ekzistuese. Dy propozime tonat janë
PaygoC si dhe ODC për realizimin e projekteve softuerike duke ofruar mundësi të
reja për të deleguar punën te palët e treta (outsourcing).
• Sistemet e informacionit të bazuara në cloud vs serverit të dedikuar -
Një studim për Shqipërinë, Kosovën, Maqedoninë e Veriut, Malin e
Zi
Sistemet e bazuara në cloud vazhdojnë të konkurrojnë me serverat e dedikuar në
kompanitë të cilat kanë nevojë për implementimin e sistemeve të informacionit. Këto
kompani kanë nevoja në rritje për kapacitetin e diskut, përpunimit të të dhënave si dhe
kohë më të shkurtra për konfigurimin e sistemit apo besueshmëri të lartë. Shërbimet
cloud shpesh kanë provuar efikasitetin e tyre, por përshtatja e tyre në nivele të
kompanive në rajonin e Ballkanit shpesh nuk është e qartë. Megjithatë, ajo çfarë vihet
re gjithnjë e më shumë, është se sistemet e informacionit bazuar në cloud mund të
zvogëlojnë në mënyrë drastike buxhetin e IT për kompanitë si dhe jenë më fleksibël
ndaj nevojave të tyre. Këto krahasime janë mbështetur nga pyetësorët tonë të
plotësuar nga kompani të ndryshme në Shqipëri, Maqedoninë e Veriut, Kosovë dhe
Mal të Zi. Punimi synon të vlerësojë gjendjen aktuale të depërtimit të sistemit cloud
për korporatat brenda rajoneve të Ballkanit, duke dhënë rekomandime për të ardhmen
e përshtatjes të shërbimeve cloud ekzistuese dhe atyre të propozuara nga ne.
7
1.7. Publikime
Në realizimin e këtij disertacioni janë publikuar punime të ndryshme në konferenca
dhe revista shkencore.
Punime në konferenca janë si në vijim:
1. CICO Orges, TORO Luada, MONKA Kristjano “Development of a
Virtual Device Driver for a Multicore Embedded Systems Hosting
Multiple Operating Systems”, International Conference: “Information
systems and technology innovations towards a digital economy” ISTI
2013)
2. CICO Orges, DIKA Zamir, “Performance and load testing of cloud vs.
classic server- platforms (Case study: Social network application)”,
IEEE Embedded Computing (MECO), 2014 3rd Mediterranean
Conference on, 15 – 19 June 2014, pp 301 -306
3. CICO Orges, DIKA Zamir, “Models and Techniques to evaluate system
and software reliability based on software reliability engineering
methodology. Case study: Attitude Control System", In Proceedings of
the 10th Annual South-East European Doctoral Student Conference,
DSC 2014, Thessaloniki, Greece.
4. CICO Orges, SILVIA Sadushi, SUELA Kodra “Business Planner
Mobile Application Development Through Kivy Platform”, International
Conference: “Information systems and technology innovations towards
a digital economy” ISTI 2014
5. CICO Orges, DIKA Zamir,“Information Systems based on cloud vs. dedicated
servers
– A survey for Albania, Kosovo, Macedonia, MonteNegro”, 8th
INTERNATIONAL CONFERENCE “Information Systems and
Technology Innovations: Fostering as a Service Economy”,
International Conference: Fostering the As-A-Service, ISTI 2017
6. CICO Orges, Dika Zamir, Cico Betim, SEVRANI Kozeta, "Migrating
Google Cloud SDK to the cloud. Case Study: GAE Launcher". Published
in: 11th IADIS International Conference on Information Systems (IS
2018), pp. 211 - 216, Date of Conference: 14-16 April 2018, Lisbon,
Portugal, ISBN: 978-989-8533-74-6, 2018, Conference Location:
Lisbon, Portugal.
8
Punime në revista shkencore:
1. CICO Orges, DIKA Zamir,“Temporal and data diversity fault tolerant
techniques used to increase reliability for Google cloud applications
Case Study: Windfarmdesigns”, International Journal of Science,
Innovation and New Technology, vol. 1, no. 2 – June, 2015, pp. 1-10
2. CICO Orges, DIKA Zamir, “High Reliability Approaches in Cloud
Applications for Business - Reliability as a Service (RaaS) Model”,
International Journal on Information Technologies and Security, ISSN
1313-8251, vol. 9, No 3, 2017, pp. 3-18.
3. CICO Orges, DIKA Zamir, CICO Betim, "Integrated Development
Environment as a Service (IDEaaS) - Models and Architecture part of
the Google Cloud Core Services". International Journal of Computer
Applications, Foundation of Computer Science (FCS), NY, USA. ISSN
for IJCA Digital Library (0975 – 8887), Volume 182, Number 6: 44-50,
July 2018.
4. CICO Orges, “Reliable IoT Systems for Improving Quality Of Life
Through The Exploitation of Cloud, Mobile and BLE Based
Technologies Case Study: SunProtect UV”, WiPiEC Journal, Vol. 4,
No 1, June 2018, pp. 15-17.
9
1.8. Organizimi i punimit
Më tej punimi është organizuar si më poshtë:
Kapitulli 2 parashtron bazat teorike të nevojshme për këtë punim shkencor. Ky
kapitull përfshin koncepte të lidhura ngushtë me përllogaritjet në cloud (“cloud
computing” - CC) matjen dhe modelet e besueshmërisë së softuerit, teknikat e
tolerancës ndaj të metave/dështimeve si dhe proceset inxhinierike të besueshmërisë së
softuerit të adaptuara në sistemet cloud për bizneset. Ky kapitull mbyllet me një
pasqyrë të lidhur ngushtë me fushën e besueshmërisë së softuerit në cloud-computing.
Kapitulli 3 paraqet përshtatjen e procesit të inxhinierisë së besueshmërisë së softuerit
SRE në sistemet kritike dhe thekson rëndësinë e strategjisë së testimit të
besueshmërisë për aplikimet në cloud. Në këtë kapitull paraqitet konceptimi,
projektimi, zbatimi dhe vlerësimi eksperimental i procesit të SRE bazuar në raste
studimi të ndryshme.
Kapitulli 4 paraqet adaptimin e teknikave të tolerimit të të metës (diversiteti në kohë
dhe projektim), pjesë e procesit të inxhinierisë së besueshmërisë së softuerit, që
aplikohet në aplikacionet cloud për bizneset. Në këtë kapitull janë paraqitur
projektimi, implementimi dhe vlerësimi eksperimental përkatës. Ky kapitull thekson
më tej qasjet e besueshmërisë së lartë në aplikimet cloud për bizneset gjatë aplikimit
të teknikave të reja të tolerimit ndaj të metave/dështimeve siç janë redundanca,
replikimi i të dhënave, zbulimi dhe rikuperimi i dështimeve. Më tej paraqitet
besueshmëria si një model shërbimi cloud dhe strukture (“framework”), mbështetur
në teknikat e tolerimit ndaj të metave, të paraqitura në kapitullin 2. Në mbyllje
prezantohen projektimi, implementimi dhe vlerësimi eksperimental nëpërmjet një
rasti konkret studimi.
Kapitulli 5 paraqet potencialet e mëtejshme të migrimit të mjeteve të zhvillimit në
cloud. Konceptohet dhe implementohet një model i ri shërbimi cloud IDEaaS bazuar
në aplikacionin GAE SDK. Më tej paraqiten dy modele të reja biznesi PaygoC dhe
ODC si dhe implementimit i tyre për ofruesit e shërbimeve cloud si Amazon, Google
dhe Azure.
Kapitulli 6 diskuton konkluzionet dhe propozimet për të ardhmen.
10
KAPITULLI 2: NJOHURITË THEMELORE
2.1. Hyrje
Ky kapitull është i ndarë në tre pjesë dhe paraqet sfondin dhe përkufizimet në të cilat
bazohet projektimi i besueshmërisë së softuerit. Në pjesën e parë janë shpjeguar
konceptet e CC, besueshmërisë, dhe njësitë matëse të besueshmërisë, modeli i
besueshmërisë së softuerit, teknikat e tolerimit të gabimit dhe optimizimi i
funksioneve të përdorimit. Për çdo koncept janë përshkruar karakteristikat e tij
kryesore, të metat, përparësitë dhe përdorimi i tyre teknologjik në cloud.
Në pjesën e dytë të këtij kapitulli, paraqitet puna në lidhje me qasjet e SRE. Kapitulli
është i grupuar në seksione të ndryshme, bazuar në qasjet kryesore të SRE të
përdorura, të tilla si modelet e besueshmërisë së softuerit, teknikat e tolerancës së
gabimit duke përfshirë blloqet e rikuperimit, programimin e trefishtë dhe me n-
versione, rishikimin e blloqeve, blloqet e rikuperimit RcB dhe blloqet e shpërndara të
rikuperimit nën kontekstin e riprodhimit të të dhënave dhe diversitetit kohor.
Në pjesën e tretë të këtij kapitulli, janë përdorur procesi SRE dhe metodologjia për të
vlerësuar dhe përmirësuar besueshmërinë e sistemit softuerik.
2.2. Përkufizime
Ky seksion jep përkufizimet themelore dhe zgjidhjet teknologjike në të cilat bazohet
ky disertacion.
Fillimisht parashtrojmë konceptin e CC, në seksionin 2.2.1. Më tej vazhdohet me
konceptin e besueshmërisë për sistemet cloud, seksioni 2.2.2. Në seksionin 2.2.3,
paraqiten vlerësimet matematikore të besueshmërisë të softuerit, të tilla si koha
mesatare e dështimit të sistemit, funksionet e paparashikuara të dështimit, mirëmbajtja
dhe disponueshmëria. Në seksionin 2.2.4, janë paraqitur modelet e besueshmërisë të
softuerit. Në seksionin 2.2.5, paraqiten teknikat e tolerancës ndaj të metave për të
rritur besueshmërinë e softuerit së bashku me vetitë kryesore të projektimit të tyre. Në
seksionin 2.3 parashtrohet rishikimi i literaturës dhe metodat më bashkohore për
zhvillimin e aplikacioneve tolerante ndaj të metave. Ndërkohë seksioni 2.4 përshkruan
procesin e SRE për vlerësimin dhe arritjen e objektivit të besueshmërisë bazuar në
matjet dhe qasjet e përshkruara në seksionet e mëparshme.
2.2.1. Përllogaritjet në cloud
2.2.1.1 Pamje historike e CC
CC ka një përdorim të gjerë vitet e fundit. Përpara CC një përdorim të gjere në fushën
e informatikës kanë patur modelet Klient/Server (“Client/Server” - C/S) dhe
përllogaritjet e bazuara në to. Kjo arkitekturë e fundit synon që të gjitha të dhënat dhe
përllogaritjet të kryhen në anën e serverit në mënyrë të centralizuar. Zakonisht nëse
një përdoruesi i nevojitej të kishte qasje në të dhëna apo të ekzekutonte një program i
duhej të ndërlidhej me serverin. Këto arkitektura u përdorën fillimisht në rrjete të
lokalizuara dhe të izoluara nga njëri tjetri. Më pas koncepti i përllogaritjeve të
shpërndara hyri në skenë ku të gjithë serverat janë të ndërlidhur me njëri tjetrin dhe
ndajnë ndërmjet tyre të gjithë burimet sipas nevojës. Mbi këto koncepte më pas u
11
bazua dhe vetë CC. Një ndër konceptuesit e filozofisë se si CC duhet të funksionojë
ka qene John McCarthy. Në vitin 1961 ai propozoi që shërbimet e CC duhet të
vendosen në dispozicion për përdoruesit sikurse uji dhe elektriciteti. Edhe pse kjo ide
në ato kohë ishte shumë e përparuar arriti të gjente zbatim shumë dekada më pas kur
dhe vetë teknologjia përparoi me hapa të mëdha. Gjatë viteve 1970, filloi përdorimi i
“mainframe” të cilët lejonin ofrimin e burimeve kompjuterike të përbashkëta në
mënyrë të centralizuar. Përdoruesit fundor kishin lehtësisht qasje tek këto kompjuter
të fuqishëm nëpërmjet terminaleve ndërlidhës. Më vonë përdoruesit fundor u bazuan
gjithnjë e më shumë në kompjuterat personal dhe rrjetat e pavarura lokale. Këto të
fundit sot lidhen duke krijuar për herë të parë një rrjet komunikimi botëror i njohur sot
si “Internet”. Megjithatë, në vitin 1999 Salesforce.com arriti t’ju ofronte përdoruesve
fundor në korporata aplikacione nëpërmjet një uebsite. Edhe pse në hapat e parë
koncepti i CC filloi më në fund të vihej në zbatim. Po kështu në vitin 2002 Amazon
(Amazon, 2014) filloi të ofronte shërbimet e saj duke ju vënë në dispozicion
përdoruesve, përkundrejt një tarife, burime si hapësirë disku, përllogaritje etj.
Megjithatë, vetëm kur cloud elastik (“Elastic Cloud” – EC) u ofrua nga Amazon në
vitin 2006 (EC2, 2014) CC arriti të kishte një përdorim komercial. Më tej Google në
vitin 2009 filloi të ofronte aplikacione e saj nëpërmjet arkitekturës të CC bazuar në
platformën “Google Apps”, e ndjekur në vijim nga Microsoft me “Windows Azure”
dhe Oracle të cilat po në këtë vit filluan të ofrojnë shërbimet e tyre cloud.
Sot koncepte të reja ku përdoruesi bëhet dhe ofrues i vetë përmbajtjes në ueb, kanë
filluar të gjejnë përdorim të gjerë nëpërmjet “web2.0”. Zbatues në cloud të kësaj
paradigme kanë qenë kompani të mëdha si Facebook, Instagram, Twitter etj.
Gjithsesi, të gjithë këto aktorë të mëdhenj në treg kanë vendosur që sot CC përben
linjën kryesore të për të ndjekur në të ardhmen e shërbimeve të internetit. Të tjerë
gjithnjë e më shumë po i janë bashkuar CC gjatë dekadës të fundit.
Me kalimin e kohës këto sisteme kanë rritur dhe kërkesat e tyre për zhvillimin e
aplikacioneve në cloud me besueshmëri të lartë. Sistemet e informacionit në të
ardhmen do të mbështeten tërësisht në sistemet cloud dhe kjo do të derivojë në
nevojën e krijimit të shërbimeve të reja për zhvillimin e kodit dhe testimin e tij sipas
modeleve më të përshtatshme.
2.2.1.2 Përkufizimet dhe përparësitë e CC
Disa përkufizime janë dhënë lidhur me CC nga autorë të ndryshëm. Në vijim jepet një
përkufizim gjithëpërfshirës i karakteristikave të CC:
"Cloud është një grupim i madh i burimeve të virtualizuara, lehtësisht të përdorshme
dhe të qasëshme (si p.sh harduerë, platforma zhvillimi dhe/ose shërbime). Këto
burime mund të ri-konfigurohen dinamikisht për t’u përshtatur me një ngarkesë të
ndryshueshme, duke lejuar gjithashtu një shfrytëzim optimal të burimeve. Ky grup
burimesh shfrytëzohet në mënyrë tipike nga modeli paguaj sipas përdorimit (pay-per-
use) në të cilin ofrohen garancitë nga ofruesi i infrastrukturës nëpërmjet marrëveshjes
të ofrimit të shërbimit (“Service Level Agreement” - SLA) të personalizuara”
(Vaquero et al. 2008).
Ky përkufizim rrjedh nga mënyra se si CC është menduar të funksionoje. Ndryshe nga
më parë kur korporatat për çdo përdorues të ri që do të punësonte i duhej të siguronte
12
licenca të reja softuerike, nëpërmjet CC ky problem ka gjetur një zgjidhje mjaft
efikase. Të gjithë aplikacionet janë të instaluara në cloud dhe mjafton që përdoruesi
fundor ta aksesoj atë për të patur në dispozicion aplikacione duke filluar nga posta
elektronike, përpunuesit e tekstit, përllogaritjet komplekse etj. E vetmja gjë që i
nevojitet përdoruesit fundor është një ndërfaqe e thjeshtë si shfletuesi ueb. Gjithashtu
arkitektura e CC lejon një përshkallëzim të lehtë të burimeve harduerike sipas nevojës
të korporatës duke rritur kështu efikasitetin e kostove që ajo duhet të përballoj.
Disa nga avantazhet kryesore të CC janë si në vijim:
1. Zvogëlimi i kostove të investimeve në infrastrukturë për kompanitë e reja,
sidomos në përdorimin e cloud publik.
2. Disponueshmëria dhe besueshmëria e sistemeve bazuar në CC është më e lartë
për shkak të burimeve alternative të cilat ato mund të vendosin në dispozicion
të përdoruesve.
3. Thjeshtësia në integrimin e cloud privatë me atë publik.
4. Pavarësia në vendodhje për shkak se cloud publik ofrohet nëpërmjet internetit.
5. Përshkallëzim i lartë i burimeve sipas nevojës i cili shoqërohet me efikasitet në
modelin e faturimit si "Pay-as-you-go", ku konsumatorët cloud paguajnë
vetëm për burimet cloud të përdorura në kohë.
6. Siguri më të lartë në cloud privat dhe fleksibilitet në modifikimin e tij.
7. Efikasitet i përdorimit të burimeve për shkak të virtualizimit të tyre. Kjo sjell
zvogëlim të kostove operacionale si dhe të kompleksitetit për menaxhimin e
infrastrukturës nga përdoruesi fundor i cloud-it, duke ja lënë këtë detyrë
ofruesit të tij. Kjo lejon që kompanitë të përqendrohen gjithnjë e më shumë në
shërbimet inovative dhe modelet e biznesit, në vend të konfigurimit të
infrastrukturës, që i mbështesin ato.
8. Fleksibilitet për stafin e IT në zhvendosjen e aplikacioneve të tyre në cloud,
duke lejuar që t’i ofrojnë biznesit aplikacionet e nevojshme me efikasitet të
lartë.
9. Përmirësim në kohën e disponueshmërisë të sistemit dhe zvogëlim në kohën e
mirëmbajtjes të tij.
10. Zhvendosja e aplikacioneve të klientit në cloud zvogëlohet ndjeshëm për
shkak të virtualizimit që CC ofron.
2.2.1.3 Arkitektura e CC
Shumica e sistemeve cloud janë të bazuara në shtresat e mëposhtme të shërbimit:
• Softuer si një shërbim ("Software as a Service" - SaaS).
• Platforma si një shërbim ("Platform as a Service" - PasS).
• Infrastruktura si një shërbim ("Infrastructure as a Service" - IaaS).
• Backend mobile si një shërbim (“Mobile backend as a service” - MBaaS).
Tre shtresat e para krijojnë njësitë bazë për shumicën e arkitekturave cloud. Klientët
zakonisht shfrytëzojnë shërbimet në nivele të ndryshme abstragimi bazuar në nevojat
që kanë. Figura 2.1 përshkruan një përfaqësim të mundshëm të shërbimeve të
grumbulluara dhe ndërveprimin e tyre me përdoruesit cloud. Në këtë figurë paraqitet
një përmbledhje e shërbimeve cloud. Shtresat e ndryshme të cloud mund të
shfrytëzojnë shtresat e mëposhtme duke filluar nga bërthama harduerike.
13
Figura 2-1 Paraqitje eliptike e shërbimeve cloud dhe ndërlidhja e tyre me
përdoruesit fundor
Kjo paraqitje ndihmon në kuptimin e koncepteve të tjera të parashtruara në këtë
punim. Shtresat e shërbimeve mund të përfshijnë disa ose të gjitha shtresat ekzistuese.
IaaS
Funksionaliteti bazë i ofruar nga sistemi cloud është vendosja në përdorimin e
burimeve harduerike. Klientët cloud nuk nevojitet që të jenë të vetëdijshëm për
harduerin fizik të cilin po shfrytëzojnë. Pra, cloud krijon një abstragim të njësive të
tilla si burimet e llogaritjes, ruajtja e të dhënave, balancimi i ngarkesës, shkallëzimi,
siguria, etj. duke i ofruar këto si shërbime. Realizimi i këtij abstraksioni arrihet
nëpërmjet makinave virtuale ("Virtual Machine" - VM) të organizuara në servera
fizikë dhe zakonisht të kontrolluar nga një "hypervisor" si VMWare, VirtualBox,
Oracle VM, Hyper-V etj. Përparësitë kryesore të shfrytëzimit të VM kanë të bëjnë me
aftësitë e shkallëzimit të burimeve në bazë të nevojave të klientit (Kavis 2014).
PaaS
Shumica e klientëve sot duhet të vendosin shpejt aplikacionet e tyre në server me
mini- mumin e përpjekjeve për mirëmbajtje, fleksibilitet maksimal dhe efikasitet
kostoje (pagesa sipas përdorimit). PaaS ofron ambient të përshtatshëm për zhvillimin
dhe vendosjen e aplikacioneve. Këto janë zakonisht të identifikuara si shërbime që
lidhen me serverët e uebit dhe mjedisin e ekzekutimit të tyre për gjuhë të ndryshme të
programimit dhe skriptimit, sistemet operative, bazat e të dhënave etj. Ofrues të
njohur janë GAE, Microsoft Azure, Amazon. Në të gjitha rastet përparësia kryesore e
14
cloud ka të bëjë me shkallëzimin e burimeve virtuale duke adoptuar kapacitetet me
nevojat e klientit (Kavis 2014).
SaaS
Shpërndarja e softuerit dhe mjedisi i tyre i ekzekutimit në ditët e sotme mbështetet në
ofruesit e shërbimeve të shpërndara, të njohura zakonisht si ofruesit cloud. Në këtë
rast ofruesi përmbush të gjithë menaxhimin e shërbimeve të përmendura më parë IaaS
dhe PaaS dhe përdoruesi fundor shfrytëzon vetëm funksionalitetet e ndryshme të
softuerit. Kjo në shumicën e rasteve është e përshtatshme pasi shmang shpërndarjet e
licencave dhe kostot bazohen në modelin “paguaj sipas përdorimit”.
Për më tepër, softuer ekzekutohet vetëm në infrastrukturën cloud duke mos u
mbështetur në aftësitë kompjuterike të klientit. Të dhënat e përpunuara nga klientët
gjatë ekzekutimit ruhen gjithashtu për shfrytëzim të mëvonshëm. Burimet gjithashtu
mbështeten në krijimin, klonimin e kopjeve të VM-ve. Shërbimet e softuerit cloud
janë gjithashtu në gjendje të përmirësojnë efikasitetin e tyre të ekzekutimit përmes
balancimit dhe shpërndarjes së ngarkesës së punës. SaaS përgjithësisht zbatohet
shumë mirë për nevojat dhe kërkesat e kompanive të mesme dhe të mëdha (Kavis
2014).
MBaaS
Në ditët e sotme aplikacionet mobile mbulojnë një pjesë të madhe të tregut të
softuerit. Por shumica e aplikacioneve mobile duhet të mbështeten në backends për
llogaritjen dhe ruajtjen e të dhënave. Kështu madhësia e tyre e instalimit zvogëlohet
dhe performanca e përgjithshme bëhet më pak e ndërvarur nga aftësitë e pajisjes.
Komunikimi krijohet kryesisht nëpërmjet shërbimeve për përfaqësimin e gjëndjeve të
transferimit ("Representational state transfer" - REST). Kjo ka sjellë gradualisht
nevojën për krijimin e një modeli të ri të njohur si MBaaS (Kavis 2014).
2.2.1.4 Mjetet për zhvillimin në Cloud
“Cloud Software Delopment Kit" (SDK) zakonisht përfaqësojnë një bashkësi mjetesh
për platformat cloud, të cilat lejojnë përdoruesin fundor të shfrytëzojë plotësisht
infrastruk- turën cloud në nivel shërbimesh të ndryshme si PaaS, IaaS. Mjete të tilla
zakonisht janë pjesë e ndërfaqeve bazuar në komanda (“Command Line Interface” -
CLI) ose atyre grafike (“Graphical User Interface” - GUI) të vendosura në
dispozicion nga ofruesit e shërbimeve cloud. SDK-të gjithashtu mbështesin gjuhë
programimi të ndryshme dhe objektivi kryesor është të lejojnë jo vetëm zhvillimin,
por edhe menaxhimin e VM-ve. Secila prej tyre ka veti të ngjashme me kompjuterët
personalë dhe siguron kryesisht virtualizimin e komponentëve bazë të
kompjuterizimit siç janë pajisjet hyrëse/dalëse (“Input/Output” - I/O), kështu që
sistemet mund të ofrojnë shërbime duke filluar nga serverat e uebit dhe duke vazhduar
me bazat e të dhënave, përllogaritje, etj.
Shumica e shërbimeve për çdo ofrues cloud, si Amazon, Azure dhe Google, veprojnë
duke u mbështetur në strategjitë sipas kërkesës (on-demand) ose paguaj sipas
përdorimit (pay per use). Kështu platformat janë shumë fleksibël për t’u përdorur nga
individë, biznese apo dhe institucionet qeveritare.
15
2.2.1.5 Gjuhët dhe teknologjitë e programimit cloud
Bashkësia e gjuhëve dhe mjediseve të programimit të mbështetura nga cloud dëshmon
fleksibilitetin e platformave aktuale për të shfrytëzuar një shkallë të gjere të
teknologjive, tabela 2-1.
Tabela 2-1: Gjuhët e programimit në PaaS për ofrues të ndryshëm të shërbimeve
cloud
Ofrues shërbimi cloud Emërtimi Gjuhët e programimit në PaaS
Google GAE Go, PHP, Java, Python, Node,
.NET, Ruby
Amazon AWS Elastic
Beanstalk
Java, .NET, PHP, Node.js, Python,
Ruby, Go, Dockers
Microsoft Azure Azure Cloud
Services
Java, .NET, PHP, Node.js, Python,
Ruby
Ka patur disa iniciativa të rëndësishme në lidhje me zhvendosjen e mjediseve të
zhvillimit në shfletuesit ueb. Disa prej tyre janë të lidhura në mënyrë specifike me
sisteme e integruara të dedikuara (Hausladen et al. 2014), ndërkohë që të tjerat kanë
qasje më të përgjithshme (Wu, 2011). Një nga iniciativat e para i përket vitit 2010, e
cila ka ofruar funksionalitetet bazë për menaxhimin e kodit për ofruesit kryesor të
shërbimeve cloud si AWS (“Amazon Web Services” - AWS), Microsoft Azure, GAE.
Vetëm mjediset e kohëve të fundit kanë arritur të integrojnë plotësisht ambientin e
zhvillimit të kodit (IDE) me SDK-n e cloud-it duke lehtësuar jo vetëm zhvillimin,
testimin dhe heqjen e gabimeve (“debugging”) por edhe procesin e vendosjes të
aplikacioneve në mjedisin cloud. Kryesisht si IDE të përdorura për qëllime didaktike
mund të përmendim (Cloud9 2018; CloudForge: 2018; Codeanywhere: 2018;
CodePlex 2018; Compilr 2018; Condevy 2018; GitLab: 2018; jsFiddle 2018).
Në vijim po përshkruajmë disa nga ambientet kryesore të adaptuara nga ofrues cloud
si Amazon:
• Cloud 9 është themeluar në vitin 2010, dhe ka lehtësuar konceptin e lëvizjes së
shërbimeve të orientuara nga IDE në ueb. Kështu që zhvillimi i kodit bëhet
mjaft i thjeshtë duke u mbështetur në zhvillimin nëpërmjet shfletuesve ueb.
Për më tepër, bashkëpunimi në ekip lehtësohet nëpërmjet integrimit të plotë të
depozitarëve si Github, Bitbucket me hapësirat e përbashkëta të punës.
Përparësia kryesore është mundësia për të integruar disa mjedise dhe shërbime
ku zhvilluesit mund të shkruajnë, testojnë dhe vendosin aplikacione cloud.
Shumë nga zgjidhjet ekzistuese për IDE-të e zhvillimit të cloud-it dhe SDK-të
nuk përfshijnë këtë lloj fleksibiliteti (Cloud9 2018).
• Condevy është themeluar në 2012 dhe që nga ky vit është kthyer në një mjedis
popullor cloud. Zhvilluesit mund të punojnë me hapësira të përbashkëta të
shpërndara, të shkallëzuara, të cilat rezultojnë në menaxhim më të mirë të
zhvillimit të kodit në cloud. Mjediset janë krijuar zakonisht si "sandboxes" ku
i gjithë konfigurimi i nevojshëm është i paracaktuar në mënyrë që procesi i
zhvendosjes të mund të përqendrohet drejt aplikimit përfundimtar (Condevy
2018).
16
2.2.2. Konceptet e varësisë dhe besueshmërisë për aplikimet cloud
Varësia nga një sistem sipas (Lyu and others 1996), përcaktohet si besueshmëria ndaj
një sistemi kompjuterik bazuar ndaj shërbimit që ai ofron. Shërbimi i ofruar nga një
sistem është sjellja që ai ka siç perceptohet nga përdoruesit. Një përdorues
konsiderohet të jetë një sistem tjetër fizik ose njerëzor, i cili ndërvepron përmes
ndërfaqeve të shërbimit të ofruar nga vetë sistemi. Shërbimi i dorëzuar konsiderohet i
saktë kur ai implementon funksionin e kërkuar të sistemit. Funksioni i një sistemi
është ai që sistemi ka për qëllim të realizojë, dhe përshkruhet nga specifikimi
funksional. Kur shërbimi i dorëzuar nga sistemi është i pasaktë, vetë sistemi
konsiderohet i pa dobishëm ose i vjetruar. Megjithatë, mund të ndërmerren masa për
të korrigjuar sistemin, në mënyrë që të mund të ofrojë një shërbim korrekt. Figura 2-2
tregon të gjitha elementët që ndikojnë dhe krijojnë besueshmërinë e një sistemi. Secili
prej tyre do të përshkruhet në seksionet në vazhdim.
2.2.2.1 Pengesat: Të metat, gabimet dhe dështimet
Sipas (IEEE Std. 610.12.19999) nëse një gabim konsiderohet të jetë një gabim
njerëzor i bërë nga një projektues ose programues, atëherë e meta është manifestimi i
atij gabimi. E shprehur më thjeshtë, e meta mund të jetë shkak i një gabimi të
brendshëm. Në përgjithësi për një sistem softuer, gabimet mund të rrjedhin nga
faktorët e brendshëm ose të jashtëm. Gabimet e jashtme janë kryesisht për shkak të
ndërveprimit njerëzor me sistemin dhe mjedisin në të cilin vepron. Ndërsa gabimet e
brendshme zakonisht lidhen me komponentët e brendshëm të sistemit dhe kalojnë nga
gjendja e fjetur në gjendjen aktive ose anasjelltas.
Figura 2-2 Varësia: Pengesat, atributet, mënyrat, modelet
17
Në varësi të kohëzgjatjes së tyre brenda sistemit, gabimet mund të klasifikohen në:
• Tranzitore: Gabimet që ndodhin për shkak të gjendjes së mjedisit, në një
periudhë të përkohshme kohore.
• Të ndërprerë: Gabimet që janë të pranishme vetëm herë pas here për shkak të
paqëndrueshmërisë së gjendjes së softuerit.
• Të përhershëm: Gabimet që janë të vazhdueshme dhe të qëndrueshme.
Gabimi mund të jetë një gabim konceptual ose një veprim njerëzor, i cili është i prirur
për të shkaktuar një të metë të sistemit. Gabimet klasifikohen në:
• Të fshehtë: Gabim i panjohur.
• Të zbuluar: Është zbuluar plotësisht nga një mekanizëm zbulimi ose algoritëm.
Gabimet zakonisht përhapen duke gjeneruar gabime të tjera brenda sistemit. Prania e
gabimeve përcakton praninë e të metave aktive. Pra, të metat aktive janë shkaku i
dështimeve të sistemit. Ndërmjet këtyre tre faktorëve, vetëm dështimet e sistemit
mund të vërehen nga jashtë. Dështimet përcaktohen nga një rezultat i pasaktë në dalje
i sistemit referuar një vlere në hyrje të përcaktuar nga specifikimet e sistemit.
Dështimet e sistemit identifikohen kur shërbimi i ofruar devijon nga shërbimi aktual i
pritshëm. Dështimet shkaktohen dhe si rezultat i gabimeve njerëzore. Sistemi
zakonisht dështon në mënyra të ndryshme, në varësi të tipologjive të gabimeve.
Mënyra të tilla njihen edhe si modalitete të gabimeve të sistemit. Këto mënyra të
dështimeve kanë ndikim jo vetëm në statusin dhe funksionimin e sistemit, por edhe në
mjedisin në të cilin sistemi funksionon. Rezultati i padëshiruar i gabimeve të një
komponenti të sistemit mund të shkaktoj rreziqe të niveleve të ndryshme. Dështimet
maten duke konsideruar intensitetin e tyre (zakonisht njihet si shkalla e dështimit) në
aspektin e kohës ose njësive të ndryshme të matjes, p.sh.. 10 dështime në orë; ose si
dendësi e tyre: p.sh.. 100 dështime për 10000 rreshta kod (“Kilo Lines of Code” -
KLOC). Në shumicën e rasteve, norma e dështimeve përdoret për të përcaktuar
besueshmërinë e sistemit. Në praktikë është shumë e rëndësishme kur, ku dhe mënyrat
që përcaktojmë ekzistencën e dështime të sistemit. Zakonisht të dhënat për dështimet
grumbullohen kur kryhet integrimi ose testimi i sistemit. Pra, ndryshimet në
projektimin e sistemit janë shumë të vështira nëse testimi kryhet në këtë fazë të
vonshme. Të dhënat e dështimeve zakonisht grumbullohen nga testuesit e sistemit, të
cilët e kanë të pamundur të marrin në konsideratë të gjithë mjedisin operativ ku
sistemi do të punojë; pra duke siguruar vetëm një grup të kufizuar të të dhënave të
dështimeve. Pa dyshim, sa më e gjerë është fusha e testimit aq më e gjerë do të jetë
saktësia e tij si dhe cilësia e softuerit. Figura 2-3 përshkruan lidhjen midis gabimeve,
të metave dhe dështimeve. Ndërsa figura 2-4 ilustron mënyrën se si ato duken brenda
një komponenti softuerik.
Figura 2-3 Marrëdhënia ndërmjet të metës, gabimit, dështimit1
1 E përshtatur nga punimi i (Lyu and others 1996)
18
Figura 2-4 Marrëdhënia ndërmjet të metave, gabimeve dhe dështimeve brenda
një komponenti softuerik2
Qëllimi kryesor i teknikave të tolerancës ndaj të metave të soft uerit është parandalimi
i dështimeve si rrjedhojë i gabimeve të komponentëve të cilët shkaktojnë të meta në
sistem. Përkufizimi klasik i teknikës së tolerancës ndaj të metave të softuerit referuar
(Lyu and others 1996) është: duke përdorur një shumëllojshmëri të metodave të
softuerit, zbulohen të metat, origjinat e të cilave janë të lidhura me softuerin si dhe
kryhet korrigjimi i tyre.
2.2.2.2 Atributet: Disponueshmëria, besueshmëria, siguria, konfidencialiteti,
integriteti, mirëmbajtja
Atributet e besueshmërisë specifikojnë vetitë e një sistemi softuerik. Ato mund të
përcaktohen si:
• Disponueshmëria: gatishmëria për shërbimin e saktë.
• Besueshmëria: vazhdimësia e shërbimit të saktë.
• Siguria: mungesa e pasojave katastrofike tek përdoruesit dhe mjedisi.
• Konfidencialiteti: mungesa e zbulimit të paautorizuar të informacionit.
• Integriteti: mungesa e ndryshimeve të padëshiruara të gjendjes së sistemit.
• Mirëmbajtja: aftësia për t’ju nënshtruar riparimeve dhe modifikimeve.
Secili prej atributeve të besueshmërisë ka peshë të ndryshme, në varësi të sistemit të
softuerit të marrë në konsideratë. Megjithatë, për shumicën e aplikacioneve është
gjithmonë e nevojshme disponueshmëria, ndërsa konfidencialiteti, siguria dhe
besueshmëria mund të jenë ose jo të domosdoshme.
Disa nga atributet vijnë si rrjedhim i kombinimit të atributeve të tjera. Për shembull,
siguria konsiderohet si kombinim i njëkohshëm i konfidencialitetit, integritetit dhe
2 E përshtatur nga punimi i (Lyu and others 1996)
19
disponueshmërinë. Siguria zakonisht konsiderohet si një zgjerim i atributit të
besueshmërisë. Siguria pranohet gjithashtu si besueshmëria e sistemit në lidhje me
dështimet katastrofike.
2.2.2.3 Mjetet: parandalimi i të metave, largimi i të metave, toleranca ndaj të
metave, parashikimi i të metave/dështimeve
Sipas (Lyu and others 1996) zhvillimi i softuerit cilësor dhe të besueshëm është
objektivi kryesor i SRE-s. Pra inxhinierët e projektimit të softuerëve duhet të
fokusohen në shpërndarjen e softuerit me besueshmëri të lartë tek përdoruesit fundorë.
Në punimin (CodePlex 2018) ofrohet një përmbledhje e katër fushave teknike që
përdoren për të përftuar sisteme të besueshme softuerike:
1. Parandalimi i të metave: shmang ose parandalon ndodhjen e të metave në
sistem.
2. Largimi i të metave: zbulon nëpërmjet verifikimit dhe validimit ekzistencën e
të metave dhe eliminimin e tyre.
3. Toleranca ndaj të metave: siguron që shërbimi të përputhet me specifikimet e
kërkuara pavarësisht nga të metat që kanë ndodhur ose ndodhin.
4. Parashikimi i të metave / dështimeve: vlerëson praninë e të metave, shkaqet
dhe pasojat e dështimeve.
Kur një nga fushat teknike të mësipërme nuk arrin të zbulojë një të metë në sistemin
softuerik, fusha tjetër siguron mjetet e nevojshme për t’u marrë me të metën e zbuluar.
Parandalimi i të metave është metoda e parë e cila siguron mbrojtje kundrejt një
sistemi softuerik jo të besueshëm. Nëse të metat shmangen gjatë ndërtimit të softuerit,
nuk ka nevojë ti rregullojmë ato në të ardhmen. Parandalimi i të metave bazohet
kryesisht në qasjet si në vijim:
• Përfundimi i kërkesave në një fazë të hershme të zhvillimit të softuerit.
• Metoda formale në specifikimet e kërkesave dhe validimin e programit.
• Metodat e projektimit të softuerit të strukturuar dhe mjetet ndihmëse (mjeti
“Computer Aided Software Engineering” - CASE).
• Teknikat e organizuara për ripërdorimin e softuerit.
Specifikimi i kërkesave është një proces jo perfekt, i cili mund të përfshijë gabime
logjike në zbatimin e softuerit, duke çuar rrjedhimisht në dështime të sistemit në të
ardhmen. Një ndërveprim i hershëm me përdoruesin mund të sigurojë përmirësimin e
kërkesave të mbledhura të softuerit. Për më tepër, komunikimi i përmirësuar ndërmjet
softuerit dhe inxhinierisë së sistemit sjell në thelb zhvillim softueri më të sigurt dhe
më të besueshëm, pasi kuptohet qartë se gabimet e kërkesave të softuerit mbizotërojnë
ndaj gabimeve të kodimit. Metodat formale bazohen në specifikimet e kërkesave
rigoroze në të gjitha gjuhët dhe mjetet matematikore të specifikuara. Nëse ato
aplikohen në mënyrë korrekte mund të parandalojnë plotësisht të metat. Megjithatë,
kjo qasje është e vështirë për projekte të mëdha, sepse prova matematikore e
korrektësisë së softuerit mund të jetë e vështirë për t’u përcaktuar dhe ndoshta është e
të njëjtës madhësi sa dhe vetë softueri për tu implementuar. Sidoqoftë, këto metoda
rigoroze mund të jenë të përshtatshme për komponentë softuerikë të veçantë dhe
shumë kritikë.
20
Metodat e projektimit të softuerit mbështeten në përcaktimin e një strukture e cila ka
për qëllim të minimizojë ndërvarësinë e komponentëve të tij, duke reduktuar
kompleksitetin e përgjithshëm të softuerit. Parimet kryesore në të cilat mbështetet ky
projektim janë ndarja dhe modularizimi. Rezultati i projektimit të strukturuar të
softuerit duhet të jetë zvogëlimi i numrit të të metave.
Ripërdorimi i softuerit aplikohet sipas metodave formale të ripërdorimit, me kosto më
të ulët në zhvillim dhe përmirësim në siguri.
Megjithatë, nëse softueri i ripërdorur nuk është i certifikuar siç duhet, mund të çojë në
fatkeqësi gjatë veprimtarive të tij në jetën reale.
Shembujt e dhënë tregojnë se atributet e ndryshme të besueshmërisë trajtohen në
mënyra të ndryshme. Kështu, softueri i besueshëm ndonjëherë mund të mos jetë i
sigurt në operacione të zbatuara në jetën reale. Organizata ndërkombëtare për
standartizim (“International Organization for Standardization” - ISO) si ISO 9000-3
janë krijuar për të parandaluar të metat në një sistem.
Megjithatë të metat nuk mund të parandalohen plotësisht, prandaj kur ato gjenden në
softuer, largimi i tyre përbën një zgjidhje alternative mbrojtëse. Qëllimi i largimit të
gabimeve është zbulimi i të metave të mbetura në sistemin e softuerit, nëpërmjet
metodave të verifikimit dhe validimit (“Verification and Validation” - V&V), dhe më
pas eliminimi. Largimi i të metave mbështetet kryesisht në dy qasje praktike të
përdorura gjerësisht në industri për sigurimin e cilësisë së softuerit.
• Testimi i softuerit.
• Inspektimi i softuerit.
Hapi kryesor për largimin e të metave përfshin testimin. Hapat për kryerjen e tij janë
diskutuar dhe në (Bertolino and Society 2007). Vështirësitë kryesore në testimin e
softuerit janë të lidhura me koston dhe kompleksitetin e testeve (Myers 1976). Është
vërtetuar se minimizimi i ndërvarësisë ndërmjet komponentëve të softuerit dhe
madhësisë së tyre do të përmirësonte cilësinë e përgjithshme të testimit. Për më tepër,
testimi i plotë mund të kryhet në komponentët e identifikuar më kritik për sistemin
softuerik.
Gjithashtu, përdoret edhe një teknikë tjetër e largimit të gabimeve, e cila ka gjetur një
fushë të gjerë zbatimi në industri dhe është aplikuar me sukses nga kompani të
ndryshme (Grady 1992). Teknika bazohet kryesisht në shqyrtimin e kodit burim për të
gjetur të metat. Sa herë që zbulohet një e metë fillon procesi i largimit të saj, i cili në
fund verifikon korrigjimin e të metave. Inspektimi formal përfshin një proces rigoroz,
i cili kryhet nga një grup i vogël inxhinierësh para fazës së testimit.
Pas zbatimit të dy teknikave të sipërpërmendura, për të minimizuar numrin e
përgjithshëm të të metave softueri vendoset në përdorim. Nëse ka mbetur ende ndonjë
e metë e pa zbuluar, nuk ekziston më mundësia për ta hequr atë nga sistemi.
Mekanizmi i fundit mbrojtës që parandalon të metat në prodhimin e një dështimi të
sistemit është toleranca ndaj të metave. Teknikat e tolerancës ndaj të metave
aplikohen në sistemin e softuerit gjatë zhvillimit të tij dhe sigurojnë aftësinë e sistemit
të softuerit për të ofruar shërbim të vazhdueshëm dhe të besueshëm për konsumatorin.
Kjo teknikë lejon sistemet softuerike të:
21
1. Parandalojnë gabimet e fjetura për tu bërë aktive nëpërmjet programimit
mbrojtës, gjë që ndalon operacionet e paligjshme duke monitoruar hyrjet
dhe daljet në sistem.
2. Izolojnë gabimet për të parandaluar përhapjen e mëtejshme të tyre në
sistem
3. Rikthejnë në gjendjen e duhur funksionale sistemin softuerik.
4. Tolerojnë metodikisht të metat në nivelin e sistemit, duke shfrytëzuar
teknikat e diversitetit të projektimit gjatë zhvillimit të softuerit.
Procesi i tolerancës ndaj të metave zakonisht përfshin hapat e paraqitur në figurën 2-5.
Teknikat e tolerimit të të metave zakonisht klasifikohen duke u bazuar në
kompleksitetin e tyre dhe mjedisin softuerik në të cilin veprojnë. Nëse ekziston vetëm
një mjedis i sistemit të softuerit, atëherë teknikat e mëposhtme përdoren për të
toleruar pjesërisht të metat gjatë projektimit të softuerit: monitorimi dhe verifikimi i
vendimeve, trajtimi i përjashtimeve ose atomizmi i veprimeve.
Megjithatë, nëse sistemi softuerik ndërtohet duke u bazuar në versione të shumta,
atëherë përdoren teknika të ndryshme tolerante ndaj të metave. Zakonisht këto teknika
mbështeten në versione të pavarura të softuerit të cilat ofrojnë funksionalitete të
njëjta. Koncepti është huazuar nga teknikat e tepricës të sistemeve harduerike. Disa
shembuj të kësaj teknike janë programimi me N-versione (“N-Version Programming”
- NVP), programimi me vetëkontroll (N self-checking programming) dhe blloqet e
rikuperimit (Recovery control blocks - RcB)
Figura 2-5 Hapat e tolerancës ndaj gabimeve
22
Së fundmi, përdoren teknika të ndryshme të të dhënave, nëse të dhënat e futura në
sistem të softuerit mund të përfaqësohen në mënyra të ndryshme, duke siguruar më
shumë tolerancë ndaj gabimeve gjatë projektimit të sistemit softuerik. Dy nga teknikat
e njohura janë blloqet e riprovës (retry blocks - RtB) dhe programimi me shumë kopje
(“N-copy programming” - NCP).
Të gjitha këto teknika dhe shembuj të aplikimeve të tyre do të prezantohen gjatë këtij
punimi. Megjithatë, meqenëse kompleksiteti i zbatimit dhe kërkesa për resurset
njerëzore janë të ndryshme, jo të gjitha mund të shfrytëzohen. Së fundmi, nëse
gabimet ende mbeten në sistemin softuerik dhe janë të destinuara të prodhojnë
dështime, është e rëndësishme të sigurohet një vlerësim i saktë dhe parashikim i
këtyre dështimeve. Parashikimi i të metave/dështimeve përfshin formulimin e
krahasimit ndërmjet të metës/dështimit, kuptimin e mjedisit operacional, krijimin e
modeleve të besueshmërisë së softuerit, zhvillimin e procedurave dhe mekanizmave
për matjen e besueshmërisë së softuerit, si dhe analizën dhe vlerësimin e rezultateve të
matjes. Besueshmëria e softuerit na jep mundësinë për të vlerësuar cilësinë e softuerit
dhe për të përcaktuar kur testimi nuk është më i nevojshëm. Për më tepër, si hardueri,
edhe softueri kërkojnë mirëmbajtje dhe përtëritje përmes teknikave të përshkruara në
(Lyu and IEEE 2007).
2.2.3. Vlerësimi matematikor i besueshmërisë
Sipas (Pham 2001) besueshmëria është probabiliteti që një produkt apo komponent do
të funksionojë siç duhet (pa dështime) për një periudhë të caktuar kohe nën kushtet e
projektimit të softuerit. Matematikisht, besueshmëria R(t) është probabiliteti që
sistemi të funksionoj me sukses nga momenti kohor 0 në momentin kohor t:
𝑅(𝑡) = 𝑃(𝑇 > 𝑡) 𝑡 ≥ 0 (2-1)
ku T nënkupton kohën e dështimit të sistemit.
Funksioni i besueshmërisë është monoton zbritës, me vlerë të barabartë me 1 në fillim
të ciklit jetësor të sistemit softuerik R(0) = 1 dhe me vlerën zero në fund të tij R(∞) =
0. Përfaqësimi grafik i ekuacionit të (2-1) jepet në Figurën 2-6.
Figura 2-6 Paraqitja grafike e besueshmërisë3
Dështimi i shprehur si:
3 E përshtatur nga punimi i (Pham 2001)
23
𝐹(𝑡) = 1 − 𝑅(𝑡) (2-2)
përcaktohet si probabiliteti që sistemi do të dështojë në kohën t:
𝐹(𝑡) = 𝑃(𝑇 ≤ 𝑡) 𝑡 ≥ 0 (2-3)
Paraqitja grafike e ekuacionit të dështimit jepet në Figurën 2-7.
Figura 2-7 Paraqitja grafike e mungesës të besueshmërisë4
Pra, F(t) përshkruan funksionin e shpërndarjes së dështimit. Kështu, duke përdorur
variablin e rastit T funksioni i densitetit të probabilitetit f (t), nga i cili mund të
nxjerrim matjen e besueshmërisë R(t) si:
𝑅(𝑡) = ∫ 𝑓(𝑠) 𝑑𝑠∞
𝑡
(2-4)
ose në mënyrë ekuivalente:
𝑓(𝑡) = −𝑑
𝑑𝑡𝑅(𝑡)
(2-5)
Kështu ne mund të përshkruajmë funksionin e densitetit të probabilitetit, në lidhje me
kohën T të dështimit, siç tregohet edhe në Figurën 2-8:
lim∆𝑡→∞
𝑃(𝑡 < 𝑇 < ∆𝑡) (2-6)
Natyrisht, nëse sistemi provohet se punon me sukses në kohën t, do të ishte më pak e
mundur që ai të vazhdojë të punojë siç duhet kur kjo kohë shkon drejt pafundësisë.
Është e qartë se besueshmëria bëhet e pakuptimtë pa një lidhje me kohën në të cilën
sistemi synon të funksionojë siç duhet.
Figura 2-8 Paraqitja grafike e mungesës të besueshmërisë5
4 E përshtatur nga punimi i (Pham 2001)
5 E përshtatur nga punimi i (Pham 2001)
24
2.2.3.1 Koha mesatare e dështimit të sistemit
Nëse sistemi ka një funksion besueshmërie R(t), atëherë koha e pritshme e dështimit
gjatë së cilës një komponent pritet të ekzekutohet me sukses ose koha mesatare e
sistemit për të dështuar (“Mean Time to Failure” - MTTF), jepet nga shprehja e
mëposhtme:
𝑀𝑇𝑇𝐹 = ∫ 𝑡 𝑓(𝑡)∞
0
(2-7)
dhe duke zëvendësuar shprehjen e mëparshme të f(t) në ekuacionin:
𝑓(𝑡) = −𝑑
𝑑𝑡𝑅(𝑡)
(2-8)
përftojmë:
𝑀𝑇𝑇𝐹 = − ∫ 𝑡𝑑[𝑅(𝑡)] = −[𝑡𝑅(𝑡)] + ∫ 𝑅(𝑡)𝑑𝑡∞
0
∞
0
(2-9)
Në mënyrë intuitive, sipas shpjegimeve të mëparshme, termi i parë i ekuacionit shkon
drejt 0 në të dyja kufijtë, pasi sistemi duhet gjithsesi të dështojë pas një kohe të
caktuar funksionimi. Nga kjo rrjedh që:
𝑀𝑇𝑇𝐹 = ∫ 𝑅(𝑡) 𝑓(𝑡)∞
0
(2-10)
Kështu që, MTTF përfaqëson vlerësimin integral të funksionit të besueshmërisë. Në
përgjithësi, nëse λ(t) përcaktohet si funksioni i shkallës së dështimit, atëherë, sipas
përkufizimit, MTTF është e barabartë me 1
λ(t) . MTTF varet direkt nga funksioni i
shpërndarjes së kohës së dështimit. Rezultate këto të përshtatura nga (Pham 2001).
2.2.3.2 Funksionet e dështimeve dhe normës se rrezikut
Nga funksioni i besueshmërisë R(t) i dhënë në fillim të kapitullit ne mund të
llogarisim probabilitetin që sistemi mund të dështojë në një interval kohor të caktuar
[t1,t2]:
∫ 𝑓(𝑡)𝑑𝑡 = 𝑡2
𝑡1
∫ 𝑓(𝑡)𝑑𝑡 − ∫ 𝑓(𝑡)𝑑𝑡 = 𝑅(𝑡1) − 𝑅(𝑡2)∞
𝑡2
∞
𝑡1
(2-11)
ose, nëse përdorim funksionin e dështimit F(t) = 1−R(t) përftojmë që:
25
∫ 𝑓(𝑡)𝑑𝑡 = 𝑡2
𝑡1
1 − 𝐹(𝑡1) − (1 − 𝐹(𝑡2)) = 𝐹(𝑡2) − 𝐹(𝑡1)
= ∫ 𝑓(𝑡)𝑑𝑡 − ∫ 𝑓(𝑡)𝑑𝑡𝑡1
−∞
𝑡2
−∞
(2-12)
Siç u përmend më parë shkalla në të cilën ndodhin dështimet në një interval kohor të
caktuar quhet gjithashtu shkalla e dështimit. Kështu, në qoftë se ne e ndajmë
intervalin e kohës në njësi të vogla dhe të barabarta kohore, atëherë shkalla e
dështimit mund të përcaktohet si probabiliteti që një dështim për njësi kohore ndodh
një interval kohor të caktuar. Pra, shkalla e dështimit për intervalin kohor [t1,t2] mund
të shprehet si:
𝑅(𝑡1) − 𝑅(𝑡2)
𝑅(𝑡1)(𝑡2 − 𝑡1)
(2-13)
ku t1 dhe t2 mund të shprehin vlera të ndryshme kohore.
Nga kjo lidhje ne mund të kuptojmë në mënyrë intuitive se shkalla e dështimit është e
lidhur ngushtë me intervalin kohor që po konsiderohet. Nëse intervali është shumë i
vogël atëherë shkalla e dështimit do të ulet. Nëse intervali kufizohet, shkon drejt
zeros, atëherë ne mund të llogarisim një ndryshore të re të quajtur shkalla e
rrezikshmërisë. Nga përkufizimi, shkalla e rrezikshmërisë nënkupton shkallën e
dështimit në një çast të caktuar kohe dhe funksioni i saj h(t) mund të paraqitet si kufi i
shprehjes së mësipërme kur intervali [t1,t2] tenton drejt zeros:
ℎ(𝑡) = lim𝑡2−𝑡1→0
𝑅(𝑡1) − 𝑅(𝑡2)
𝑅(𝑡1)(𝑡2 − 𝑡1)= lim
𝑡2→t1 𝑅(𝑡1) − 𝑅(𝑡2)
𝑅(𝑡1)(𝑡2 − 𝑡1)=
𝑓(𝑡1)
𝑅(𝑡1)
(2-14)
Nga kjo shprehje mund të konkludojmë se funksioni i rrezikut është raporti midis
funksionit të densitetit të probabilitetit (probability density function - pdf) dhe
funksionit të besueshmërisë. Në përgjithësi, nëse duam të përcaktojmë se kur një
komponent softuerik ose një pajisje do të dështojë, mund të përdorim produktin h(t)dt.
Nëpërmjet funksionit të rrezikut ne mund të llogarisim zhvillimin/rritjen e normave të
dështimit të komponentëve kritikë gjatë ciklit të tyre të jetës, duke krahasuar
funksionet e rrezikut të secilit komponent në lidhje me kohën. Rezultate këto të
përshtatura nga (Pham 2001).
2.2.3.3 Mirëmbajtja
Ndonjëherë dështimet janë të pashmangshme dhe ndodhja e tyre duhet të trajtohet në
mënyrë të duhur në mënyrë që sistemi të kthehet në funksionimin e tij normal.
Korrigjimi i dështimeve mund të përfshijë riparimin e një ose më shumë
komponentëve të sistemit ose edhe zëvendësimin e tyre. Mirëmbajtja, sipas (Pham
2001), përcaktohet si probabiliteti që kur një sistem dështon do të rivendoset në
kushtet e specifikuara të punës brenda një periudhe të caktuar kohe kur mirëmbajtja
kryhet sipas procedurave dhe burimeve të caktuara. Me fjalë të tjera, mirëmbajtja
është probabiliteti i izolimit dhe riparimit të një të mete në një sistem brenda një kohe
26
të caktuar.Nëse T përcaktohet si variabëli i rastit që përcakton kohën deri sa të
përfundojë riparimi i sistemit, atëherë mund të supozojmë se T shprehet nga një
funksion densiteti kohor riparimi g(t). Siç kemi bërë më parë për R(t), mund të japim
shprehjen matematikore për mirëmbajtjen M(t), për sa i përket probabilitetit që
sistemi do të riparohet deri në çastin e caktuar të kohës t.
𝑀(𝑡) = 𝑃(𝑇 ≤ 𝑡) = ∫ 𝑔(𝑡)𝑑𝑡∞
0
(2-15)
Një matje e rëndësishme për të konsideruar mirëmbajtjen, ashtu siç bëmë për
besueshmërinë, është koha e pritur e riparimit gjatë së cilës kryhet një riparim i
komponentëve ose koha mesatare e sistemit për riparim (Mean Time To Repair -
MTTR):
𝑀𝑇𝑇𝑅 = ∫ 𝑡𝑔(𝑡)𝑑𝑡∞
0
(2-16)
2.2.3.4 Disponueshmëria
Sipas (Lyu and others 1996) matja e disponueshmërinë lejon të kryhen riparime,
kurdoherë që ndodh një dështim. Matematikisht, disponueshmëria A(t) shprehet si:
𝐴(𝑡) = 𝐾𝑜ℎ𝑎 𝑓𝑢𝑛𝑘𝑠𝑖𝑜𝑛𝑎𝑙𝑒
𝐾𝑜ℎ𝑎 𝑓𝑢𝑛𝑘𝑠𝑖𝑜𝑛𝑎𝑙𝑒 + 𝐾𝑜ℎ𝑎 𝑗𝑜 𝑓𝑢𝑛𝑘𝑠𝑖𝑜𝑛𝑎𝑙𝑒
(2-17)
Disponueshmëria është një matje e përdorur kryesisht për sistemet e riparueshme.
Nëse sistemi nuk mund të riparohet atëherë disponueshmëria është e barabartë me
matjen e besueshmërisë. Emëruesi i shprehjes së mëparshme paraqet një matje të
rëndësishme të njohur edhe si koha mesatare ndërmjet dështimeve (Mean Time
Between Failures - MTBF). Në mënyrë ideale, preferohen sistemet me MTTR shumë
të vogël (kohë të shkurtër në riparim) dhe MTTF të gjatë (kohë të gjatë deri në
ndodhjen e një dështimi). Megjithatë, në realitet një sistem me MTTR të shkurtër
është gjithmonë i preferuar në lidhje me një sistem me MTTF më të gjatë. Paraqitja
grafike e MTTF, MTTR dhe MTBR është dhënë në Figurën 2-9.
Figura 2-9 Paraqitja grafike e MTTF, MTTR dhe MTBR6
6 E përshtatur nga punimi i (Lyu and others 1996)
27
Konceptet matematikore të besueshmërisë janë parashtruar përfshirë dhe ato të
shpalosura në këtë kapitull janë diskutuar në mënyrë të zgjeruar nga (Pham 2001).
2.2.4 Modelet e besueshmërisë së softuerit
Në praktikë është e përshtatshme që të përcaktohen gabimet e mbetura brenda një
sistemi softuerik. Për të modeluar dhe parashikuar sjelljet e tij të ardhshme, duhet të
mblidhen të dhënat të sakta nga dështimet e kaluara. Gjatë 35 viteve të fundit janë
zhvilluar modele dhe teknika të ndryshme për të matur besueshmërinë aktuale dhe të
ardhshme të sistemeve softuerike të trajtuar në mënyrë të plotë nga (Lyu and others
1996). Megjithëse është e pamundur të ndërtohet një softuer plotësisht pa dështime,
është e rëndësishme të identifikohet një model ekzistues ose të propozohet një model i
ri që përshkruan më së miri probabilitetin e dështimeve në të ardhmen duke i siguruar
kështu përdoruesit fundor cilësinë e sistemit softuerik. Disa modele të besueshmërisë
së softuerit janë propozuar dhe përdorur nga mjete të ndryshme për studime të rasteve
të ndryshme. Disa prej këtyre rasteve do të paraqiten në kapitujt në vijim. Në
përgjithësi mund të identifikohen dy lloje kryesore të modeleve të besueshmërisë së
softuerit (Pham 2001):
• Modele të përcaktuara të besueshmërisë
- Modeli i Halstead’s
- Modeli McCabe’s.
• Modelet probabilitare të besueshmërisë sipas
- Modeli Markov
- Modeli Poisson
- etj.
2.2.5 Adaptimi i teknikave tolerante ndaj të metave në cloud
Teknikat tolerante ndaj të metave janë trajtuar nga (Pullum 2001). Në këtë seksion
kemi
përmbledhur ato teknika të cilat janë adoptuar në qasjet eksperimentale të kryera në
kapitujt në vijim në rastet të studimeve të ndryshme.
2.2.5.1 Diversiteti në kohë
Teknika e diversitetit në kohë (Morris 1981) bazohet në ndodhjen e një ngjarjeje në
kohë të ndryshme (p.sh. ekzekutimi i komponentëve të softuerit ose kodit në kohë të
ndryshme duke përdorur të njëjtat hyrje). Zakonisht këto teknika janë efikase në
anashkalimin e gabimeve për shkak të natyrës së tyre të përkohshme që rrjedh nga
gjendja e sistemit/infrastrukturës, duke mos qenë pjesë kështu në ri-ekzekutimin e
softuerit.
Ekzekutimi i kodit mund të kryhet në kohë të ndryshme ti,ti+1,....,ti+n duke përdorur të
njëjtat hyrje. Rezultatet duhet të kontrollohen nga një votues p.sh. testi i pranimit
(“Acceptance Test” - AT). Në këtë teknikë marrim parasysh vetëm rezultatet që nuk
rrjedhin nga gabimet e komunikimit në rrjet. Për shembull, nëse ndodh një gabim i
komunikimit në rrjet në kohën t, atëherë programi ynë duhet të kryejë të njëjtin
veprim në kohën ti+n duke shpresuar që të marrë një rezultat të pranueshëm pa
gabime. Në raste të tilla mund të ndiqet një strategji lineare ose eksponenciale, duke
28
bërë të mundur ekzistencën e një diference të arsyeshme kohore midis ti dhe ti+n të ri
ekzekutimit të kodit. Në figurën 2-10 jepet një paraqitje e qasjes së përshkruar.
2.2.5.2 Diversiteti në projektim
Diversiteti në kohë mund të jetë një qasje e përshtatshme për tolerancën e gabimeve
që rrjedhin kryesisht për shkak të gjendjes së infrastrukturës cloud, në vend të
gabimeve në kod në përgjithësi. Infrastruktura cloud bazohet zakonisht në alokimin e
burimeve sipas kërkesës, kështu një alokim i tillë mund të mos jetë i menjëhershëm
dhe është i prirur për vonesa.
Diversiteti në projektim mund të derivojë nga kërkesat fillestare, ose gjatë projektimit
të arkitekturës të softuerit. Kërkesat marrin në konsideratë si mund të merret vendimi
nga një votues, ndërsa arkitektura ka të bëjë me teknikën që do të përdoret p.sh.:
Programimi me N-Versione, Programimi N-Kopje, etj. Është e rëndësishme që nga
kërkesat fillestare të përcaktohen ekipet e zhvilluesve si dhe gjuhët e programimit.
Implementimet e ndryshme që ekzekutohen në një nëngrup të barabartë të hyrjeve
duhet të dështojnë ose të jenë të suksesshme në mënyrë koherente me njëra tjetrën.
Figura 2-11 ofron një paraqitje grafike të konceptit të diversitetit gjatë projektimit të
softuerit (Avizienis and Kelly 1984).
Figura 2-10 Diversiteti në kohë me hyrje të njëjta7
7 E përshtatur nga punimi i (Pullum 2001)
29
Figura 2-11 Diversiteti në kohë me hyrje të njëjta8
2.2.5.3 Redundanca
Redundanca mund të ofrojë nivele të ndryshme të disponueshmërisë në varësi të
modelit, strategjisë dhe hapësirës së përdorimit të saj. Modeli i redundancës i
referohet mënyrave të ndryshme, që sistemet me disponueshmëri të lartë (“High
Availability” - HA) mund të kombinojnë kopjet aktive si dhe qëndrimit në pritje të
aplikacioneve në cloud. Ekzistojnë katër modele: 2N, N + M, N mënyra dhe N
mënyra aktive (Merideth et al. 2005). Modeli 2N siguron një kopje, e cila qëndron në
pritje për çdo modul aktiv të softuerit. Fushëveprimi i zbatimit të redundancës mund
të ekzistojë në çdo shtresë cloud si ajo e aplikimit, makinës virtuale dhe fizike
(Mosetti, Poloni, and Diviacco 1994).
2.2.5.4 Riprodhimi i të dhënave
Riprodhimi i të dhënave, përdoret për të ruajtur qëndrueshmërinë e gjendjes ndërmjet
kopjeve. Problemi kryesor, që lidhet me këtë shërbim është mundësia si të ruajmë
balancën midis konsistencës dhe përdorimit të burimeve (T. Chen, Bahsoon, and
Tawil 2014). Në cloud, riprodhimi mund të arrihet duke kopjuar gjendjen e një
sistemi (pikat e kontrollit) ose duke riprodhuar të dhëna për të gjitha kopjet (An et al.
2014).
8 E përshtatur nga punimi i (Pullum 2001)
30
2.2.5.5 Monitorimi
Monitorimi është një shërbim i rëndësishëm në një sistem cloud me disponueshmëri të
lartë. Përmes këtij shërbimi, monitorohet vazhdimisht gjendja e aplikacioneve për të
mbështetur shërbimet e tjera. Qëllimi kryesor i këtij shërbimi është të zbulohet kur një
riprodhim nuk funksionon, por zbatimet robuste u kushtojnë rëndësi edhe treguesve të
tjerë të një aplikacioni (shfrytëzimi i CPU-së (“Central Processing Unit” - CPU) dhe
kujtesës, disku dhe I/O e rrjetit, koha për tu përgjigjur kërkesave), që ndihmojnë të
zbulohet kur një kopje nuk funksionon mirë. E njëjta procedurë mund të realizohet
edhe në nivelin e makinës virtuale dhe fizike (Endo et al. 2016).
2.2.5.6 Identifikimi i dështimeve
Zbulimi i dështimeve është një shërbim i rëndësishëm që gjendet në shumicën e
zgjidhjeve HR, që synon të identifikojë defektet e sistemeve cloud (në nivel aplikativ,
virtual ose fizik) dhe të sigurojë informacionin e nevojshëm për të realizuar
vazhdimësinë e shërbimit. Shumë autorë prezantojnë disa mekanizma, që përdoren
për të zbuluar gabimet si ping, heartbeat etj. (Imran et al. 2014). Nga ky
këndvështrim, zbulimi i dështimeve mund të klasifikohet në dy kategori sipas
mekanizmave të zbulimit: reaktive dhe proaktivë (Compilr 2018). Qasja e parë pret
për mesazhet KEEP ALIVE, por ajo identifikon një dështim pas një periudhe kohe.
Qasja e dytë është e aftë të identifikojë sjelljet jonormale në sistem, duke kontrolluar
shërbimin e monitorimit dhe duke interpretuar të dhënat e mbledhura, për të verifikuar
nëse ka dështime.
2.2.5.7 Rikuperimi
Sistemi i softuerit dhe rikuperimi i shërbimit të tij cloud është pjesë e një procesi më
të gjerë të tolerimit të të metave. Ai përfshin zbulimin e gabimeve/defekteve,
debugging, izolimin dhe rikuperimin e tyre. Në literaturë janë propozuar lloje të
ndryshme të rikuperimit bazuar në rikuperimin përpara dhe mbrapa në kohë (Koo and
Toueg 1987).
Në shërbimet cloud, këto teknika bazohen në shumë raste në redundancën e sistemit
në nivele të ndryshme të operimit (virtual ose fizike) (Alexandrov, Dimov, and ACM
2013). Zakonisht, rikuperimi mbrapa në kohë përfshin kthimin e sistemit në një
gjendje të mëparshme e ruajtur si një pikë kontrolli e sistemit pa dështime. Qasja më e
adoptuar ka të bëjë me blloqet e kontrollit të rikuperimit (RcB) .
Rikuperimi përpara përpiqet të vazhdojë ekzekutimin e sistemit duke identifikuar një
gjendje të re, që ekzekutohet në një njësi paralele. NVP është metoda më e
përshtatshme për këtë rast.
Duke shfrytëzuar konceptet e rikuperimit mbrapa dhe përpara, ku të dy përpiqen të
kthejnë sistemin në një gjendje të saktë, teknikat e rikuperimit, që veprojnë mbi cloud
klasifikohen në të thjeshta dhe inteligjente. Qasja e thjeshtë përfshin rinisjen plotësisht
të aplikacionit në nyje të njëjta ose të ndryshme, por në përfundim të gjitha të dhënat
dhe informacionet e gjendjeve humbasin. Ndërsa rikuperimi inteligjent shfrytëzon
qasjet tolerante ndaj të metave të miratuara kryesisht nga teknikat e rikuperimit
mbrapa në kohë (Monitorim/Kontroll). Ato zakonisht përfshijnë krijimin e kopjeve
31
rezervë paralele dhe gjendjeve të kontrollit në mënyrë që të mund të ndryshojnë
ekzekutimin e tyre pas shfaqjes së dështimit (Pullum 2001).
2.2.5.8 Blloqet e rikuperimit - RcB
Skema e rikuperimit (RcB) (Avizienis and Kelly 1984) përbëhet nga disa variante në
ekzekutim, rezultatet e të cilave miratohen nga një test pranimi. Në disa raste,
implementimet në kohë reale i shtohen skemës mbikëqyrëse (“Watch Dog Timer” -
WDT). Nga kodi i paraqitur në vijim, ne mund të vëzhgojmë se si në fillim RcB
përpiqet të sigurojë rezultatin bazuar në testin e pranimit nga blloku provë (“try”).
Nëse i pari dështon, provohen mundësi të tjera derisa të arrihet një rezultat
përfundimtar i suksesshëm ose dështimi. Nëse shtohet një mbikëqyrës (WDT), atëherë
provohen alternativat deri sa nuk është arritur afati i fundit kohor.
2.2.5.9 Blloqet e shpërndarë të rikuperimit DRcB
Blloqet e shpërndara së rikuperimit (“Distributed Recovery Blocks” - DRcB)
kombinojnë përpunimin e shpërndarë dhe paralel si dhe blloqet e rikuperimit. Teknika
është e aplikueshme si në nivelin e softuerit ashtu edhe në atë harduer. Teknika
shfrytëzon një çift të nyjeve të përpunimit të vetëkontrollit, ose komponentëve të
llogaritjes të strukturuar si çift kryesor (nyje rrjeti të përhershme apo të përkohshme).
AT siguron një konfirmim të rezultatit në nyjet e shpërndara sipas hapave (K. H. Kim
and Welch 1989).
2.2.5.10 Blloqet e riprovës - RtB
Blloqet e Riprovës (“Retry Blocks” - RtB) janë një teknikë e bazuar në të dhëna të
ndryshme në hyrje. Kjo teknikë është plotësuese e teknikës të mëparshme RcB. Në
mënyrë të ngjashme, kjo teknikë përdor AT, rikuperimin mbrapa dhe WDT për t’u
siguruar nëse një algoritëm dështon dhe atëherë mund të provohet përsëri me hyrje të
ri-shprehura. Nga ofruesit e ndryshëm cloud si Google etj. përdoren implementime
dhe koncepte të ngjashme si “Exponential Backoff”. Megjithatë, miratimi i qasjeve të
tilla në nivelin e shërbimit cloud, jo vetëm në nivelin e përdoruesit përfundimtar, do të
zbuste problemet e përkohshme në cloud. Kështu sistemet cloud, që operojnë në SaaS
duke përshtatur teknikat e RtB, siç do të dëshmohet më vonë në këtë punim, do të
siguronin besueshmëri më të lartë të shërbimeve të tyre (K. H. Kim 1995).
2.2.5.11 Teknika të tjera
Në këtë seksion kemi paraqitur disa nga teknikat më të përshtatshme të tolerimit ndaj
gabimeve të cilat janë të adoptueshme në sistemet cloud. Megjithatë, janë zhvilluar
dhe studiuar edhe teknika të tjera të cilat janë thjesht derivate ose kombinime të RCB
dhe NVP . Bazuar në (Pullum 2001) mund të përmendim :
• “Hybrid Fault-tolerant”.
• “Scheme Triple-version”.
• “Programming Consensus recovery block” .
• “Acceptance voting”.
• “N-self-checking programming”.
32
2.3 Rishikimi Literaturës - Metodat më bashkëkohore të aplikuara në cloud për
zhvillimin e aplikacioneve tolerantë ndaj gabimeve
Gjatë shqyrtimit të literaturës janë identifikuar punime të rëndësishme që trajtojnë
besueshmërinë e lartë (“High Reliability” - HR) të sistemeve cloud. Klasifikimet
bazohen kryesisht në Forumin e disponueshmërisë të softuerit (“Service Availability
Forum” - SAF). Dy klasifikime kryesore janë:
1. Metodika të bazuara në middleware dhe në nivel virtualizimi si:
a. Aplikacionin
b. Makinat virtuale
c. Hostuesi
2. Metodika bazuar në shtresa të ndryshme cloud:
a. Teknologjitë e adaptuara në nivel VM
b. Në nivel shërbimesh të cilat adresojnë mekanizmat e tolerancës ndaj të
metave të konfigurueshme nga ofruesit e cloud
c. “Middleware” të cilët menaxhojnë operacionet, konfigurimet dhe
vendimmarrjet në cloud sipas situatës të dështimit
Toleranca ndaj të metave të softuerit shfrytëzohet gjerësisht tashmë në ndërtimin e
sistemeve të shpërndara me besueshmëri të lartë. Teknikat kryesore të tolerancës të së
metës të softuerit të adoptuara për cloud përfshijnë bllokun e rikuperimit (Avizienis
and Kelly 1984), programimin me N-Versione (L. Chen and Avizienis 1977),
programimin e vetë-kontrollimit të kodit , bllokun e shpërndarë të rikuperimit etj.
Strategjitë kryesore të tolerancës ndaj të metave mund të ndahen në strategji pasive
dhe strategji aktive. Strategjitë pasive janë diskutuar në FT-SOAP (Fang et al. 2007)
dhe FT-CORBA (Sheu et al. 1997), ndërsa strategjitë aktive janë trajtuar në FTWeb
(Santos et al. 2005), (Merideth et al. 2005). Gjithashtu në (Zheng et al. 2010) autorët
propozojnë një ambient pune të quajtur FTCloud për ndërtimin e aplikacioneve
tolerante ndaj të metave. FTCloud përfshin dy algoritme rankimi. Algoritmi i parë
përfshin thirrjen e komponentëve, strukturave dhe shpeshtinë e thirrjeve për të
përcaktuar rankimin e komponentëve. Algoritmi i dytë mbështetet në strukturën e
sistemit softuerik të ndërtuar si dhe në aftësinë e ndërtuesve të sistemit për të
identifikuar komponentët më kritik. Pas fazës të përcaktimit të komponentëve një
algoritëm përdoret për të propozuar teknikën më të përshtatshme të tolerancës ndaj të
metave për secilin nga komponentët më kritik. Rezultatet e përftuara tregojnë se gjatë
tolerimit të të metave për komponentët më kritikrritet në mënyrë të ndjeshme
besueshmëria e sistemit cloud.
2.4 Procesi SRE adaptuar për aplikime me besueshmëri të lartë në cloud
Më poshtë do të paraqesim në detaje metodologjinë e përdorur për të përcaktuar dhe
vlerësuar besueshmërinë e sistemit softuerik. Çdo hap, që duhet të merret në
konsideratë në procesin e SRE, është shpjeguar në nën-seksionet e mëposhtme. Qasja
e përdorur është ajo klasike e propozuar nga (Lyu and others 1996), (Lyu and IEEE
2007). Ka autorë të tjerë si Musa, qasjet e të cilëve afrohen në pika të ngjashme kyçe
në sigurimin e besueshmërisë së nevojshme të një sistemi softuerik. Duke qenë se
qasja e paraqitur nga (Lyu and IEEE 2007) është më e plotë, ajo do të përdoret në këtë
tezë.
33
Figura 2-12 Procesi SRE9
Pasi metodologjia është përcaktuar dhe organizuar në mënyrë të plotë, e gjithë rrjedha
e procesit në përcaktimin e besueshmërisë së softuerit do të dalë e qartë në mënyrë të
dukshme. Pasi çdo hap i procesit shpjegohet me detaje, në vazhdim paraqiten mjetet
mbështetëse të përdorura për një analizë të plotë. Këto mjete përfshijnë kryesisht dy
hapa të veçantë të procesit të SRE:
• Testimin.
• Zgjedhjen e nivelit të përshtatshëm të besueshmërisë.
9 E përshtatur nga punimi i (Lyu and others 1996)
34
Punimi do të marrë në konsideratë procesin e SRE-së në praktikën aktuale. Ne figurën
2-12 janë paraqitur hapat kryesorë për arritjen e qëllimit të besueshmërisë. Teknikat e
tolerancës ndaj gabimeve duhet të analizohen lidhur me kontributin e tyre në
besueshmërinë përfundimtare të softuerit.
Hapat e mëposhtëm paraqesin metodologjinë e përdorur në punim:
• Përcaktohet objektivi i besueshmërisë.
• Zhvillohet profili operacional.
• Realizohet testimi i softuerit.
• Mblidhen të dhënat e dështimit.
• Aplikohen mjetet për besueshmërinë e softuerit.
• Zgjidhen modelet e duhura të besueshmërisë së softuerit.
• Përdoren modelet për të llogaritur besueshmërinë aktuale.
Së fundmi, duhet të analizohet kontributi dhe efektiviteti i teknikave të tolerimit të të
metave në arritjen e objektivit të besueshmërisë.
2.4.1 Përcaktimi i objektivit të besueshmërisë
Përcaktimi i objektivit të besueshmërisë varet nga faktorë të ndryshëm. Por duhet të
kuptohet që niveli i besueshmërisë i kërkuar për sistemin varet nga faktori i riskut
lidhur me sistemin. Pra përpara se të përcaktojmë nivelin e besueshmërisë për një
sistem duhet fillimisht të kuptojmë nivelin e riskut për atë sistem. Nënkuptohet që një
softuer me risk të lartë ka nevojë për një nivel besueshmërie më të lartë. Faktorë të
tjerë të cilët mund të ndikojnë në nivelin e besueshmërisë të sistemit lidhen me
buxhetin dhe me burimet në dispozicion, si ato materiale dhe njerëzore, por, që në
rastet tona të studimit ne nuk i marrim në shqyrtim. Nivelet e rrezikshmërisë mund të
përcaktohen duke vendosur vlera nga 1 në n, ku “n” nënkupton nivelin e riskut më të
lartë. Përllogaritja e riskut varet nga dy faktorë kryesorë:
1. Gjendjet e pa pritura të sistemit dhe rrezikshmëria e tyre.
2. Probabiliteti i ngjarjes.
Pra risku përllogaritet si Risk = Gjendjet e papritura x Probabiliteti i ngjarjes.
Pasi kemi përcaktuar lidhjen ndërmjet besueshmërisë të softuerit dhe riskut mund të
përcaktojmë objektivin e besueshmërisë të tij duke u mbështetur në dy faza:
1. Identifikimin e klasave kritike të dështimeve (“Failure Severity Classes” -
FSC).
2. Përcaktimi i objektivit për intensitetin e dështimeve FIO (“Failure Intensity
Objective” - FIO).
2.4.1.1 Identifikimi i FSC
Nevoja për të klasifikuar dështimet rrjedh nga fakti që komponentët e ndryshëm të
softuerit kanë ndikime të ndryshme në dështimin e përgjithshëm të sistemit.
Megjithatë, ndonjëherë mund të ndodhi që komponentët e ndryshëm të kenë të njëjtin
ndikim në dështim; pra bëjnë pjesë në të njëjtën klasë dështimi. Një klasifikim i
mundshëm i klasave të nivelit kritik të dështimit mund të jenë të bazuara në kriteret e
mëposhtme:
35
• Aftësia e sistemit.
• Kosto.
• Mjedisi.
• Jeta njerëzore.
Tabela 2-2 paraqet një shembull të klasifikimit të kritereve të riskut së sistemit.
Tabela 2-2: Klasifikimi i klasave të riskut së sistemit10
Niveli i Riskut Klasa e nivelit
kritik Ngjarjet e paparashikuara
4 1 Ndërprerje e shërbimit
3 2 Degradimi i shërbimit
2 3 Shqetësim nga shërbimi
1 4 Efekte minimale
Për të identifikuar të gjitha shkaqet e dështimit si dhe mënyrat e klasifikimit të tyre
kërkohet një analizë e plotë e të gjitha funksioneve të sistemit softuerik:
• Diagrami i bllokut të besueshmërisë - (“Reliability Block Diagram” - RBD).
• Modaliteti i dështimit dhe analiza e modalitetit të dështimeve dhe efekti i tyre
(“Failure Mode Effect Analysis” - FMEA).
• Analiza e pemës të të metave (“Fault Tree Analysis” - FTA).
2.4.1.2 Përcaktimi i FIO
Intensiteti i dështimit përfaqësohet nga parametri A (disponueshmëria) i shpjeguar në
seksionin 2.2.3.4 dhe vlerëson numrin e dështimeve në kohë ose ndonjë njësi tjetër si
transaksionet etj. Zakonisht secili komponent karakterizohet nga intensiteti i tij i
dështimit dhe vetë intensiteti i dështimit të sistemit përcaktohet nga shuma e
intensiteteve të dështimit të të gjithë komponentëve të tij. Në aspektin e atributit të
besueshmërisë, intensiteti i dështimit rrjedh nga formula e mëposhtme (Lyu and
others 1996):
𝜆 ≈ 1 − 𝑅
𝑡 𝑝er 𝑣𝑙𝑒𝑟en e R > 0.99999
(2-16)
për sistemet cloud me besueshmëri të lartë.
Pra si përfundim, duke identifikuar klasat e niveleve më kritike të dështimit për një
sistem të caktuar softuerik ne jemi në gjendje të përcaktojmë objektivin e dështimit
për komponentët e ndryshëm të tij. Shkalla e dështimit përfundimtar të sistemit të
softuerit përcaktohet nga shuma e dështimeve të të gjithë komponentëve të tij.
2.4.1.3 Zhvillimi i profilit operacional
Koncepti i profilit operacional
Profili operacional përbëhet nga grupi i operacioneve të kryera nga sistemi softuerik si
10 E përshtatur nga punimi i (Lyu and others 1996)
36
dhe probabilitetet e tyre të ndodhjes. Një operacion përfaqëson një detyrë e cila
përmbushet nga sistemi softuerik në një mjedis të caktuar dhe të perceptuar nga
përdoruesi, i cili mund të jetë një individ ose një sistem tjetër. Operacionet e kryera
nga sistemi përfundojnë brenda një afati të caktuar kohor dhe janë të lidhura ngushtë
me kërkesat funksionale të tij. Gabimet e përfshira nga një operacion i caktuar
zakonisht nuk ndërlidhen me gabimet nga operacione të tjera. Arsyet për të zhvilluar
një profil operacional janë dy:
1. Përdorimi në praktikë i sistemit softuerik.
2. Drejtimi në testimin e sistemit.
Zakonisht profili operacional varet nga funksionaliteti i sistemit softuerik, llojet e
përdoruesve, kohëzgjatja në kohë etj. Operacionet, ndryshe nga funksionet,
përcaktohen gjatë projektimit të sistemit të softuerit. Operacionet lidhen ngushtë me
vendosjen në zbatim të sistemit dhe tipologjinë e ekzekutimit të tij të përcaktuar gjatë
projektimit. Ne mund të identifikojmë operacione nga elementë të ndryshëm të
projektimit të sistemit si:
• Klasat.
• Ndërfaqet.
• Nënsistemet.
• Sinjalet.
• Ngjarjet.
Profili operacional paraqet veprimet e tij në dy mënyra të ndryshme:
1. Në mënyrë tabelore.
2. Grafike.
Në paraqitjen tabelore, tabela 2-3, ne japim një listë të operacioneve të kombinuara
me probabilitetet e tyre të ndodhjes.
Tabela 2-3: Klasifikimi i klasave të riskut së sistemit11
Operacionet Transaksione /
njësi Probabiliteti i ngjarjes
1) 1000 0.2
2) - -
3) - -
4) - -
Për të ndërtuar një profil të mirë operacional, ne kemi nevojë për të përcaktuar të
gjitha mënyrat operacionale të sistemit. Një operacion i veçantë mund të shfaqet në
mënyra të ndryshme operacionale me probabilitet të ndryshëm të ndodhjes.
Ndërtimi i profilit operacional
Metodologjia në zhvillimin e profilit operacional ndjek hapat e paraqitur në Figurën
2-13.
11 E përshtatur nga punimi i (Lyu and others 1996)
37
Së pari, duhet të përcaktohen mënyrat e ndryshme operacionale për testim. Shembujt
e funksionimit janë:
• Gjendje kritike (si p.sh. mbyllja e sistemit).
• Kushtet operacionale (si mbingarkesa e sistemit softuerik, burimeve etj.).
• Llojet e përdoruesit ose përvoja.
• Koha.
Së dyti, iniciuesit e mundshëm të përcaktuar nga diagramet e rasteve të përdorimit, si
aktorë mund të jenë:
• Përdoruesit.
• Administratorët.
• Një sistem tjetër.
Së treti, në varësi të atributeve të mundshme për çdo operacion ne duhet të
përcaktojmë nëse duhet të përdorim një paraqitje tabelore ose grafike të profilit
operacional. Për një numër të moderuar të atributeve, një përfaqësim tabelor është më
i përshtatshëm si dhe anasjelltas. Më pas një listë operacionesh për çdo tipologji
operimi duhet të përcaktohet bazuar në disa faktorë të tillë si:
• Operacion eksplicit ose implicit.
• Variablat e mjedisit.
Më pas, shkalla e shfaqjes dhe probabiliteti i shfaqjes së çdo operacioni përcaktohet
në bazë të të dhënave të mbledhura në terren. Probabiliteti i ngjarjes është marrë nga:
𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑒𝑡𝑖 𝑖 𝑛𝑔𝑗𝑎𝑟𝑗𝑒𝑠 = 𝑛𝑢𝑚𝑟𝑖 𝑖 𝑟𝑎𝑠𝑡𝑖𝑠𝑗𝑒𝑣𝑒 𝑝er nje 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛
𝑛𝑢𝑚𝑟𝑖 𝑡𝑜𝑡𝑎𝑙 𝑖 𝑟𝑎𝑠𝑡𝑖𝑠𝑗𝑒𝑣𝑒
Së fundi përftohet dhe është gati për fazën e testimit dokumentacioni i profilit
operacional tabela 2-4
Tabela 2-4: Tabela operacionale12
Modaliteti
operacional
Filluesi / Variablat
hyrëse / ambientit Lista e op.
Numri i
rastisjeve
Probabiliteti
i rastisjeve
1)
2)
1)
2)
1)
2)
1)
2)
12 E përshtatur nga punimi i (Lyu and others 1996)
38
Figura 2-13 Hapat e ndërtimit të profilit operacional13
2.4.2 Realizimi i testimit operacional
Testimi operacional konsiston në kontrollimin e punës së softuerit në mjedisin
përkatës operacional. Bazuar në profilin operacional, çdo operacion ndahet në një
numër të caktuar ekzekutimesh të njohura edhe si një grupim i llojeve të
ekzekutimeve të konceptuar në fazën e zhvillimit. Një ekzekutim konsiderohet
zakonisht si ndarja më e vogël e punës që mund të iniciohet nga një aktor i jashtëm.
Ekzekutimet e bazuara në të njëjtat hyrje dhe gjendje ekzekutimi konsiderohen të jenë
pjesë të njëjtit grupim ekzekutimesh. Një rast testimi konsiderohet si një copëz
ekzekutimi në të cilin përcaktohen hyrjet primare së bashku me vlerat e tyre. Rastet e
testimit janë të pavarura nga modalitetet operacionale dhe mund të ekzekutohen në
modalitete të ndryshme operacionale në të njëjtën kohë, duke zbuluar sjellje të
ndryshme të dështimit.
Ekzistojnë kryesisht tri lloje testimi të besueshmërisë:
13 E përshtatur nga punimi i (Lyu and others 1996)
39
1. Testimi funksional - përdoret për të kontrolluar funksionet e ofruara nga softueri,
gjatë ekzekutimit të çdo operacioni në ndërveprim minimal me operacione të tjera.
2. Testimi në ngarkesë - për të kontrolluar performancën me ngarkesë maksimale
(p.sh. bazat e të dhënave, aplikimit etj.)
3. Testimi i regresionit - testimi i funksionit i kryer pas korrigjimit të çdo gabimi në
sistemin softuerik
Në këtë tezë do të fokusohemi në testimin e funksioneve dhe sidomos në vlerësimin e
besueshmërisë bazuar në testimin operacional.
Zakonisht testet ekzekutohen në mënyrë të rastësishme duke u dhënë më shumë
rëndësi operacioneve, që kanë probabilitet më të lartë të ndodhjes. Më pas do të
fokusohemi në identifikimin e operacioneve kritike dhe do të përcaktojmë numrin e
testimeve të nevojshme (zakonisht dy ose katër raste testimi janë të mjaftueshme).
Tipi tjetër i operacioneve të marra në konsideratë janë ato që kanë probabilitet të
vogël të ngjarjes. Numri i rasteve të testeve të caktuara për to është zakonisht një. Për
operacionet e reja në varësi të probabilitetit të tyre të ngjarjes përcaktojmë numrin e
rasteve të testimit. Figura 2-14 tregon llojin e operacioneve të ndryshëm dhe alokimin
e testimeve për secilin rast.
Figura 2-14 Shpërndarja e rasteve të testimit14
Në vazhdim përshkruajmë metodologjinë e procesit SRE. Operacionet kritike janë ato
në të cilat dështimi shkakton një ndikim të madh në lidhje me jetën njerëzore,
mjedisin, koston ose kur ekzekutimi i tyre i suksesshëm jep një vlerë të madhe shtesë.
Ato zakonisht identifikohen nga FSC-të. Operacionet e rralla janë ato operacione që
kanë probabilitet shumë të ulët të ndodhjes. Për të përcaktuar një probabilitet të ulët të
ndodhjes për operacione të rralla, së pari duhet të përcaktojmë një probabilitet pragu
= 0.5 / numri i përgjithshëm i rasteve të testimit. Ndërkohë, numri i rasteve të testimit
14 E përshtatur nga punimi i (Lyu and others 1996)
40
për operacionet e reja është i barabartë me probabilitetin e shfaqjes së profilit
operacional të sistemit shumëzuar me numrin total të rasteve të testimit. Gjatë testimit
operacional është e nevojshme të zhvillohet Profili operacional i testimit për çdo
modalitet operacional. Një profil operacional i testimit është i ndryshëm nga profili i
operacional për secilin modalitet operacional për shkak të:
1. Probabilitetit të operacioneve kritike që ndodhin rrallë.
2. Shtimit të operacioneve të reja.
2.4.2.1 Krijimi i rasteve të testimit
Ekzistojnë disa kritere nga të cilat mund të ndërtohen rastet e testimit :
1. Projektimi.
2. Kodi.
3. Prototipi.
Ne do të përqendrohemi në krijimin e rasteve të testimit të projektimit i cili bazohet
në diagramin e rasteve të përdorimit. Në përgjithësi krijojmë dy raste testimi për
secilin rast përdorimi, një për rastin e suksesshëm dhe një për rastin e dështimit.
Rastet e tjera të testimit mund të identifikohen për raste të jashtëzakonshme ose
tranzicionit të dukshëm të gjendjes të sistemit. Dokumentacioni në lidhje me këtë lloj
rastesh testimi karakterizohet nga atributet e mëposhtme dhe dokumentimi i tij është
paraqitur në tabelën 2-5.
• Identifikimi i rastit të testimit (Test ID).
• Identifikimi i rastit prind të përdorimit.
• Objektivi i testit.
• Kushtet e testimit.
• Veprimi i operatorit.
• Specifikimi i hyrjeve të drejtpërdrejta.
• Specifikimi i pritshëm i daljeve.
• Rezultatet e pritshme (testi ka kaluar ose ka dështuar).
Tabela 2-5: Dokumentimi i rasteve të testimit
Dokumentimi i rasteve të testimit
Test ID: Autori: Përditësuar nga:
Identifikimi i rastit përdorimit prind:
Data: Përditësuar më:
Objektivi i testimit: Nr.
njësisë
Kushtet
e testimit
Veprimet
e testimit
Specifikimi
i hyrjeve
Specifikimi
i daljeve
Kalon/
Dështon Komente
2.4.3 Mbledhja e të dhënave dhe vlerësimi i parametrave
2.4.3.1 Të dhënat e dështimeve
Të dhënat e dështimeve të mbledhura nga testimi do të përdoren nga mjeti për
vlerësimin e besueshmërisë së softuerit të mbështetur në kompjuter (“Computer-
Aided Software Reliability Engineering” – CASRE) (Lyu, Nikora, and IEEE 1992)
për modelimin dhe parashikimin e dështimeve të ardhshme të sistemit softuerik.
41
Shumë prej mjeteve në tregun e sotëm, duke përfshirë këtu mjetin CASRE, përdorin
dy lloje të të dhënave të dështimit:
1. Të dhënat në intervalin e fushës të veprimit (p.sh. dështimet dhe numri i
dështimeve brenda një intervali kohor të caktuar)
2. Të dhënat në kohë të caktuara (p.sh. koha e dështimit dhe koha ndërmjet
dështimeve të njëpasnjëshme)
Përkufizimi i këtyre llojeve të ndryshme të të dhënave është paraqitur në seksionet e
mëparshme.
2.4.4 Aplikimi i mjeteve të besueshmërisë së softuerit për të zgjedhur modelet e
duhura për vlerësimin e besueshmërisë
Mjeti i përdorur për të siguruar një vlerësim të besueshmërisë është CASRE. Përmes
tij ne të jemi në gjendje të matim besueshmërinë e një sistemi ose të komponentëve
sipas karakteristikave në vijim:
1. Plotësimi i të dhënave të dështimit të përdorura si hyrje për modelet.
2. Shfaqja grafike e rezultateve të dhëna nga modelet e besueshmërisë së
softuerit të përfshira në CASRE, përsa i përket numrit të dështimeve për
intervalin e testimit, kohëve midis dështimeve të njëpasnjëshme dhe numrit
kumulativ të gabimeve të zbuluara.
3. Përdoruesit mund të përcaktojnë të ashtuquajturat modele kombinimi, të cilat
janë kombinime lineare të rezultateve të modelimeve.
Përdorimi i mjetit CASRE për të vlerësuar besueshmërinë mund të kryhet pas testit të
komponentëve dhe duke vazhduar përmes testit të sistemit, testit të pranimit dhe
operacioneve. Zakonisht, një numër minimal i dështimeve, 40 ose 50, është i
nevojshëm për të siguruar një vlerësim të mirë besueshmërie. Arkitektura e nivelit të
lartë të CASRE paraqitet në figurën 2-16.
Siç mund të vëzhgojmë nga arkitektura e saj CASRE u siguron përdoruesve
mundësinë për të redaktuar dhe krijuar skedarë të dhënave të historisë së dështimeve
të reja. Ajo gjithashtu lejon rregullimin e të dhënave në hyrje për modele të ndryshme.
Përdoruesi është në gjendje të zgjedhë teknikën e rregullimit të përshtatshme për të
dhënat, që analizohen. Transformimi i të dhënave në hyrje është i mundur kur
përfaqësimi jepet në formë logaritmike ose eksponenciale. Gjithashtu përdoruesi
mund të zgjedhë midis teknikave të tranzicionit të ndryshëm sipas nevojave të tij.
Komponenti statistikor përmbledhës i arkitekturës lejon përdoruesin të analizojë
statistikat e të dhënave të dështimit dhe të sigurojë vlerat mesatare. Përparësia e këtij
mjeti vjen me mundësinë e zgjedhjes midis ekzekutimit të një modeli të vetëm ose një
kombinim ndërmjet modeleve duke dhënë kështu një parashikim më të mirë të
besueshmërisë të softuerit.
Vlerësimi i modelit të komponentit përdor metoda të ndryshme statistikore për të
përcaktuar aplikueshmërinë e modelit në një grup të dhënash specifike të dështimit.
42
Figura 2-14 Arkitektura e CASRE15
Së fundi rezultatet mund të shfaqen në njërën nga format e mëposhtme:
• Frekuencat e ndërprerjes së kohës, aktuale dhe të vlerësuara.
• Dështimet kumulative, aktuale dhe të vlerësuara.
• Rritja e besueshmërisë, aktuale dhe e vlerësuar.
Duhet të përmendet se ky mjet ende në ditët e sotme mbetet në listën e mjeteve të
përdorura për të ndihmuar në vlerësimin e besueshmërisë, për shkak të mbështetjes së
tij në një shumëllojshmërie modelesh, dhe ndërfaqes intuitive të përdorimit.
2.4.5 Përcaktimi nëse objektivi i besueshmërisë është arritur
Nga rezultatet e marra nga mjeti CASRE ne mund të përcaktojmë nëse objektivi i
besueshmërisë është plotësuar. Kështu, nëse
Rllogaritur >= Rkërkuar
për tërë sistemin e softuerit, atëherë kërkesa jonë e besueshmërisë për softuerin është
plotësuar. Megjithatë, përmirësimet në besueshmëri mund të zbatohen duke u
mbështetur në teknikat e tolerancës ndaj gabimeve.
2.5 Përmbledhje
Ky kapitull është ndarë në tri pjesë kryesore. Fokusi i pjesës së parë paraqitja e sfondit
teorik mbi të cilën bazohet puna e këtij disertacioni. Në këtë pjesë janë dhënë
15 E përshtatur nga punimi i (Lyu and others 1996)
43
përkufizime dhe përshkrime teknike për koncepte të tilla si CC, besueshmëria,
modelet e besueshmërisë së softuerit si dhe toleranca ndaj të metave.
Konceptet, algoritmat bazë dhe teknikat janë trajtuar në detaje për të mbështetur
pjesën tjetër të tezës.
Pjesa e dytë paraqet punë të mëparshme të cilat lidhen me besueshmërinë e softuerit
në aplikimet cloud për biznes. Punimet e shqyrtuara janë ndarë në grupe të ndryshme
në varësi të natyrës së aplikimit dhe teknikave tolerante ndaj të metave si mbështetje e
besueshmërisë të softuerëve.
Pjesa e fundit e kapitullit diskuton procesin SRE, dhe metodologjinë e testimit të
besueshmërisë, të cilat do të jenë bazë për aplikimet cloud për bizneset të marra si rast
studimi në punimin tonë.
44
KAPITULLI 3: TESTIMI I BESUESHMËRISË TË SOFTUERIT -
RASTE STUDIMI
3.1. Hyrje
Në këtë kapitull paraqiten disa raste studimi që lidhen me besueshmërinë në nivel
sistemi softuerik, për softuerë të konceptuar, projektuar dhe realizuar nga ana jonë. Në
rastet e studimeve të marra në konsideratë kemi aplikuar me sukses procesin e
besueshmërisë të softuerit, duke krijuar mundësinë për t’iu dhënë përgjigje pyetjes
kërkimore shkencore 0 si dhe për të mbështetur hipotezën 0, të ngritura nga ana jonë.
3.2. Zhvillimi i sistemeve të besueshme IoT. Rast studimi: ’SunProtect UV’
Koncepti dhe paradigma e IoT bashkojnë infrastrukturën ekzistuese të internetit me
pajisjet e integruara si telefonat inteligjent apo pajisjet të tjera të bazuara tek
mikrokontrollerat në një ambient të përbashkët, i cili shërben për të përmirësuar jetën
tonë të përditshme. Teknologjia e informacionit e mbështetur nga interneti është
zhvilluar në mënyrë shumë dimensionale gjatë dekadave të fundit. Shumica e
shërbimeve dhe informacioneve ofrohen nëpërmjet rrjetit botëror (World Wide Web -
WWW) (Want, Schilit, and Jenson 2015).
Në këtë zhvillim kanë lindur koncepte të reja, përveç atyre ekzistuese, që mundësojnë
komunikimin midis shfletuesve ueb dhe serverëve në cloud, dhe ndërmjet pajisjeve të
integruara inteligjente. Këto të fundit mund të mbështeten nga protokolle të pavarura,
të ndryshme nga ato që përdoren për komunikimin e aplikacioneve ueb. Qëllimi
kryesor i IoT është të bashkojë dy paradigmat e shekullit të 21-të për të krijuar një
rrjet të gjere shërbimesh bazuar në pajisjet inteligjente. Në punimin tonë paraqitet
komunikimi i pajisjeve mobile, të integruara dhe cloud-it duke shfrytëzuar
teknologjitë ekzistuese. Gjithashtu kemi parashtruar, metodologjinë e zhvillimit të
sistemit duke trajtuar çështjet e lidhura me mbrojtjen e shëndetit. Në vazhdim do të
paraqitet një sistem monitorimi i rrezatimeve ultraviolet (“Ultra Violet” - UV)
përmes një aplikacioni mobile dhe pajisjeve të integruara (wearable devices). Qëllimi
kryesor i aplikacionit ‘SunProtect’ është kontrolli, parashikimi dhe sugjerimi i dozës
më të përshtatshme të rrezatimit UV për përdoruesit, duke ofruar jo vetëm këshilla të
dobishme, por edhe përfitime shëndetësore.
3.2.1 Konceptimi i sistemit
Shërbimet e internetit në mbarë botën janë burimi kryesor dhe modeli kryesor i
komunikimit dhe i shkëmbimit të informacionit. Pajisjet ekzistuese të integruara në
IoT mund të bashkëveprojnë ose kontrollohen nga teknologjitë e uebit. Kjo na çon në
kombinim e dy paradigmave duke nxjerrë kështu në pah konceptin e Web-it fizik =
Teknologjia e Web-it + IoT (Yau, Buduru, and IEEE 2014). Figura 3-1 paraqet
arkitekturën e adoptuar nga (Want, Schilit, and Jenson 2015) për këtë rast studimi. Në
këtë rast janë shfrytëzuar gjerësisht konceptet ekzistuese në protokollet ueb dhe cloud
duke përfituar një infrastrukturë të qëndrueshme në ruajtjen e të dhënave, shkëmbimin
e informacionit, si dhe duke garantuar disponueshmëri dhe shkallëzim të lartë. Kështu
URI (“Uniform Resource Identifier” - URI) dhe përfaqësimi i gjëndjeve të
transferimit (RESTFul API) përbëjnë entitetet thelbësore të arkitekturave të sistemit.
Për më tepër, bazuar në (Want, Schilit, and Jenson 2015) janë të domosdoshme
45
protokolle për të mbushur hendekun e komunikimit midis telefonave inteligjent dhe
pajisjeve të integruara.
Figura 3-1 Arkitektura e adoptuar për të ndërlidhur infrastrukturën ekzistuese
cloud me pajisjet embedded duke u mbështetur në protokollin e komunikimit
BLE16
Një nga teknologjitë më të përdorura është "Nordic Semiconductors", e cila disponon
një BLE (“Bluetooth Low Energy” - BLE) të integruar brenda sistemit të saj, e
ndërtuar nëpërmjet mikrokontrollerave në nivel qarku të integruar (“System on Chip”
- SoC). Gjithashtu protokolli i komunikimit BLE mbështetet në profilin përgjithësues
të aksesimeve (“Generic Access Profile” - GAP) dhe profilin e përgjithshëm të
atributeve (“Generic Attribute Profile” - GATT). GAP mbulon modelin e përdorimit
të protokolleve radio në nivel të ulët për të përcaktuar rolet, procedurat dhe mënyrat
që lejojnë pajisjet të transmetojnë të dhëna, të zbulojnë njëra tjetrën, të krijojnë lidhje
ndërmjet tyre, të menaxhojnë lidhjet si dhe të negociojnë nivelet e sigurisë të
komunikimit. GAP është, në thelb, kontrolli më i lartë i shtresës BLE. Ky profil është
i detyrueshëm për të gjitha pajisjet BLE, dhe të gjitha duhet të jenë në përputhje me
të. Ndërkohë, GATT trajton shkëmbimin e të dhënave në BLE si dhe përcakton një
model bazë të të dhënave dhe procedurave për t’i lejuar pajisjet të zbulojnë, lexojnë,
shkruajnë dhe shkëmbejnë të dhëna ndërmjet tyre. Pra në thelb, GATT është shtresa
më e lartë e përfaqësimit të të dhënave të BLE. Të dy protokollet sigurojnë një
komunikim të qëndrueshëm të të dhënave dhe shërbimeve me telefonat inteligjent që
disponojnë teknologjinë BLE e integruar në to, në versionin Bluetooth 4.0.
Në botime, revista dhe artikuj, të ndryshëm parashtrohen sfida lidhur me marrjen e
dozës UV (ultraviolet), sidomos kjo e lidhur me çështjet e shëndetit të lëkurës. Një
nga rreziqet kryesore është kanceri i lëkurës. Gjatë dy viteve të fundit janë botuar disa
16 E përshtatur nga punimi i (Want, Schilit, and Jenson 2015)
46
artikuj lidhur me zhvillimin e pajisjeve të integruara bazuar në teknologji të ndryshme
(Sillanpää et al. 2014; Thangaraj et al. 2015; Yang et al. 2014). Një nga sistemet më të
përdorura është Nordic Semiconductors ku integrimi me BLE si një protokoll
komunikimi arrihet mjaft lehtë (nordicsemi 2018). Disa autorë kanë paraqitur
mundësinë e integrimit në qasjen e Web-it Fizik entitete si Cloud/Mobile dhe Pajisjet
e Integruara, me aftësi përpunuese të larta, siguri, disponueshmëri dhe lehtësi
përdorimi (T. Chen, Bahsoon, and Tawil 2014).
Zhvillimi i një mjedisi të integruar cloud/mobile dhe pajisjeve të integruara për IoT
konsiston në hapat e mëposhtëm:
1. Zhvillimi i pajisjeve të integruara që mund të vishen (“Wearable Dongle” -
WD).
2. Zhvillimi i “firmware” që siguron protokollin e komunikimit me telefonin
inteligjent.
3. Zhvillimi i aplikacionit mobile në sistemin Android 4. Komunikimi me
Google cloud.
Mikrokontrolleri i pajisjes të integruar bazohet në teknologjinë Nordic Semiconductor
me "nRF51 Development Kit", nga i cili është mundësuar zhvillimi i një "firmware"
në gjuhën e programimit C. Arkitektura Klient/Server (“Client/Server” - C/S)
përshtatet për shërbimet e transmetimit dhe shkëmbimin e të dhënave ndërmjet
aplikacionit mobile dhe pajisjes të integruar. “Firmware” vepron kryesisht si server
ndërsa aplikacioni i zhvilluar në Android do të veprojë si një klient që komunikon me
shërbimet e ofruara nga serveri bazuar në protokollin GAP dhe atë GATT.
Aplikacioni mobile bazohet gjithashtu në komunikimin me aplikimin në Google cloud
për të marrë vendime në gjenerimin e rezultateve. Arkitektura e përgjithshme është
paraqitur në Figurën 3-2.
Figura 3-2 Arkitektura e sistemit IoT17
3.2.2 Rasti studimit: SunProtect UV
Në këtë seksion parashtrojmë implementimin dhe zhvillimin e arkitekturës IoT të
konsideruar si rast studimi në punimin tonë. Një pajisje e integruar, është projektuar
17 E përshtatur nga punimi i (Want, Schilit, and Jenson 2015)
47
dhe implementuar si në Figurën 3-3. Tabela 3-1 paraqet shërbimet e implementuar për
GATT.
Figura 3-3 Programimi i pajisjes nëpërmjet Nordic Semiconductor Development
Kit
Tabela 3-1: Tabela e shërbimit GATT
Shërbimi Menaxhues UUID Të
drejta Vlera Gjatësia Përshkrimi
Sun
Service 0x0090 0x2800 Read 0xC6C6 2 bytes
Service
Description
Request 0x0091
0x2803-
Request Sun
UV
declaration
Read 0x0092 2 bytes
Request for
Sun UV
Factor
Sun value 0x0092
0x0lll - Set
UV User
Values
Read/
Write
0x00 |
0x01 2 bytes
0x00 =OFF;
0x0l = ON
Request
Attr 0x0093
0x2803 –
Voltage
Characteristic
Read 0x0094 2 bytes Request for
Data
Volt.
Target
val.
0x009 Ox0112-Set
Skin Type Read
0x00 |
0x01 2 bytes Skin Health
48
Pajisja është përgjegjëse për matjen e UV-së së rrezatimit të diellit. Gjithashtu kemi
realizuar implementimin e një aplikacion mobile, i cili komunikon drejtpërdrejt me
pajisjen e integruar dhe ka aftësinë të ofrojë sugjerime për ekspozimin e duhur në diell
gjatë ditës. Llojet e ndryshme të lëkurës reagojnë në mënyra të ndryshe ndaj rrezatimit
diellor (ekspozimi UVR) për shkak të arsyeve metabolike, gjenetike ose anomalive të
lëkurës. Nga ekspozimi afatgjatë shfaqen probleme shëndetësore jo vetëm për shkak
të djegieve nga dielli, por edhe shqetësime të tjera më serioze shëndetësore si kanceri
i lëkurës (melanoma). Meqenëse njohuritë lidhur me shqetësime të tilla, nuk janë të
njohura gjithmonë për të gjithë individët, atëherë bëhet e dobishme mundësia e një
mënyre të lehtë për të trajtuar këtë çështje duke marrë masat përkatëse. Nga
pikëpamja shëndetësore ekspozimi në diell në masë normale sjell përfitime: si marrja
e vitaminës D ose forcimi i sistemit imunitar sidomos gjatë fëmijërisë. Ekspozimi i
tepërt nuk jep ndonjë përfitim të mëtejshëm shëndetësor, por përkundrazi derivon në
rrezikshmëri për shëndetin. Pra lind nevoja në zhvillimin e një sistemi softuer i cili
kontrollon dhe menaxhon ekspozimin e tejkaluar ndaj UV, në mënyrë që çështjet e
përmendura shëndetësore të mos bëhen shqetësuese. Sistemi duhet të monitorojë
normën e ekspozimit ndaj UV, dhe bazuar në algoritme komplekse duhet të ofrojë
vlerësime rreth ekspozimit në diell, i ndikuar nga faktorë si:
1. Kushtet e motit.
2. Lloji i lëkurës.
3. Nuanca aktuale e lëkurës.
4. Ngjyra e syve.
Edhe kur aspekti shëndetësor nuk përbën shqetësim në vetvete, aplikacioni mund të
përdoret lehtësisht për këshilla të përditshme, në mënyrë që të garantohet ekspozimi
më i përshtatshëm ndaj diellit për motive si nxirje optimale e lëkurës, marrja e
vitaminës D, etj.
Për këtë arsye kemi implementuar një aplikacion mobile, i lidhur me pajisje të
integruara, që ofron matjen e UV-s. Gjithashtu, ruajtje e të dhënave të besueshme si
dhe përpunimi i rezultateve për rekomandimet e mundshme, janë bazuar në
infrastrukturën cloud të Google.
Infrastruktura cloud ofron besueshmërinë e duhur për ruajtjen dhe shkëmbimin e
informacionit për përdorues të ndryshëm, optimizimin e kostove të përdorimit, dhe
përfitime të tjera të tilla si siguria, privatësia si dhe performancë maksimale. Pra ajo
siguron mundësinë e një plani të personalizuar të mbrojtjes ndaj rrezatimit UV për
çdo përdorues.
Përdoruesi fundor gjithashtu ka pak ose aspak njohuri në lidhje me sistemin dhe
funksionimi tij, por ky i fundin ofron një shërbim efikas, të lehtë për t’u përdorur si
dhe gjithëpërfshirës për mbrojtjen e lëkurës dhe shëndetit. Çdo rezultat përllogaritës
përpunohet nga platforma cloud duke ulur nevojën për përllogaritje komplekse si dhe
kapacitete harduerike për pajisjet e integruara apo dhe vetë telefonat inteligjentë.
Figura 3-4 dhe 3-5 paraqesin arkitekturën e aplikacionit mobile të zhvilluar si dhe
ndërfaqet e ndryshme të implementuara.
49
Figura 3-4 Arkitektura e aplikacionit mobile SunProtectUV18
Figura 3-5 Arkitektura e aplikacionit mobile SunProtectUV
Në figurën 3-6 paraqitet arkitektura e aplikacionit në Google Cloud për ruajtjen e të
dhënave të përftuara dhe kryerjen e llogaritjeve përkatëse.
18 E përshtatur nga diagrami e komponentëve të sistemit
50
Figura 3-6 Arkitektura e aplikacionit në Google cloud
Në këtë punim kemi prezantuar mundësinë e kombinimit të pajisjeve të integruara,
telefonave inteligjentë dhe sistemeve cloud në një rrjet të mundshëm IoT, i cili në
rastin konkret ofron përfitime shëndetësore për përdoruesit fundor. Sistemi mund të
punojë në dy modalitete të mundshme si offline dhe online, por disponon dhe një
logjikë mjaft të përshtatshme sinkronizimi. Përfitimet kryesore lidhen me lehtësinë e
përdorimit, sigurinë e përdorimit dhe përshkallëzimin e kapaciteteve përpunuese në
cloud. Kjo e bën sistemin akoma më të besueshëm në përdorim nga ana e përdoruesve
fundor. Propozimi ynë në vazhdim lidhet me matjen e besueshmërisë të këtij sistemi
nëpërmjet procesit të besueshmërisë të parashtruar në kapitullin 2.
3.3 Testimi i besueshmërisë të një sistemi satelitor
Qëllimi kryesor i këtij kapitulli është vlerësimi i metodave të besueshmërisë të
softuerit nëpërmjet një rasti studimi konkret si ai i kontrollit të sistemit satelitor.
Metodologjia e adoptuar gjatë këtij punimi është ajo e paraqitur më parë në kapitullin
2.
3.3.1 Përgatitja eksperimentale dhe vlerësimi
Në këtë seksion parashtrojmë rastin e studimit të marrë në shqyrtim. Fillimisht
paraqesim diagramin për rastet e përdorimit të sistemit softuerik për kontrollin e
51
pozicionit të satelitit në hapësirë ACS. Diagrami i rasteve të përdorimit (“Use Case
Diagram”), figura 3-7, identifikon funksionalitetet e sistemit të përdorur për të kryer
analiza të ndryshme të besueshmërisë të tij.
Figura 3-7 Diagrami i rasteve të përdorimit për ACS
Në këtë diagramë mund të vëzhgojmë se aktori i vetëm bashkëveprues me sistemin
është interpretuesi i komandave. Ky i fundit përfaqësohet nga një kompjuter bordi
(On Board Computer - OBC), i cili përdoret për dekodimin e komandave që vijnë nga
stacioni tokësor dhe transferohen më pas në të gjithë nivelet e telekomunikimit të
satelitit. Në figurën 3-8 jepet një pasqyrë e klasave të përdorura në ndërtimin e
sistemit.
Figura 3-8 Diagrami i klasave për ACS
RBD e sistemit rrjedh nga diagrami i klasës dhe arkitektura e komponentëve të
softuerit paraqitet në Figurën 3-9. Në këtë rast studimi RBD është mjaft i dobishëm në
52
përcaktimin e besueshmërisë së përgjithshme të pritshme bazuar në vlerësimin e
besueshmërisë së secilit komponent.
Figura 3-9 Diagrami i bllokut të besueshmërisë të komponentëve të sistemit të
softuerit ACS
Nga RBD mund të përcaktojmë klasa të ndryshme të nivelit të dështimeve FSC për
ACS. Në tabelën 3-2 raportohen klasat e mundshme të dështimeve FSC.
Tabela 3-2: Raportimi i FSC-ve të mundshme
Klasat e dështimeve
Kriteret e
klasifikimit Klasa 1 Klasa 2 Klasa 3 Klasa 4
Kapacitetet e
sistemit F1, F4 F2, F3, F5, F6, F7 F8, F9, F10
Kostot e
sistemit F1 … F10
Ambienti
F1 … F10
Jetë njerëzore
F1 … F10
Identifikimi i FSC është thelbësor për të përcaktuar kërkesat e besueshmërisë së
mundshme të sistemit softuerik si dhe objektivi i intensitetit të dështimit FIO të tij.
Besueshmëria e përgjithshme e sistemit përcaktohet nga: RACS = 0.96 duke marrë
parasysh se besueshmëria për secilin bllok të lidhur në RCB është 0.99.
53
Ndërkohë që FIO përcaktohet nga:
𝜆 =1 − 𝑅𝐴𝐶𝑆
𝑡= 0.04
Nëse përmbushet një FIO e tillë, ne mund të sigurohemi që softueri është i besueshëm
mjaftueshëm për tu vendosur në përdorim.
3.3.2.1 Zhvillimi i profilit operacional për ACS
Profili operacional i ACS paraqitet në tabelën 3-3. Profili operacional është ndërtuar
sipas hapave të përshkruar në kapitullin 2. Numri i operacioneve është përcaktuar
gjatë inspektimit të kodit. Ky profil operacional është zhvilluar për një modalitet
normal operacional të ACS i cili është përdorur më tej për të drejtuar testimin e tij.
Tabela 3-3: Profili i Operacional të ACS
Modaliteti
Operacional Filluesi
Lista e
Operacioneve
Numri i
ngjarjeve
Probabiliteti i
ngjarjeve
Modaliteti i
përllogaritjes
të pozicionit
Kompjuteri
bordit
1) Përllogarit
pozicionin e
satelitit 1.30 0.1
2) Përllogarit
pozicionin e tokës 96 0.11
3) Modelimi i
fushës magnetike 96 0.11
4) Përllogarit
rrotullimin 35 0.04
5) Përllogarit ditën 70 0.08
6) Përllogarit
pozicionin e diellit 70 0.08
7) Përllogarit
pozicionin 96 0.11
8) Lexo të dhënat
nga sensoret 44 0.05
9) Koordino
reagimin e rrotave 140
0.16
Totali 873 1
3.3.2.2 Rezultatet e testimit të ACS
Testimi i ACS për profilin operacional është ndërtuar bazuar në Tabelën 3-6. Numri i
54
përgjithshëm i rasteve të testimit është 272 ku të gjitha rastet e testimit janë të reja.
Mundësia më e ulët e ndodhjes të një operacioni është:
0.5/200 = 0.0025
Nuk ekzistojnë operacione kritike si dhe numri i operacioneve të rralla me
probabilitetet e ndodhjes poshtë vlerës minimale është 0. Numri i përgjithshëm i
rasteve të testimit është shpërndarë sipas probabilitetit të ndodhjes të operacioneve.
Dështimet e ACS për çdo operacion të testuar bazuar në profilin operacinal janë
paraqitur në tabelën 3-4.
Tabela 3-4: Shëmbull dokumenti testimi
Test Case Document
ID e rastit të përdorimit:
Pozicioni i satelitit Autori: Orges Çiço P: Orges Çiço
Parent Use Case ID: Computer
Satellite Position Date: 1/07/2012 Updated on: 12/08/2012
Objektivi i testimit: Përcaktimi i pozicionit të satelitit
Nr.
Njësisë
Kushtet
e testit
Veprimi
i testit
Specifikimi i
hyrjeve
Specifikimi i
daljeve
(Rezultatet e
ekzekutuara)
Kriteri
Kalon/
Dështon
Komente
1 Asnjë Testimi
i vitit i s.t. 0 <=i <=9
Mesazh gabimi
Përllogaritja
ndalon.
Dështon
Përllogaritja
është kryer
gabim
2 Asnjë Testimi
i vitit
ij s.t. i>2
0 <=i,j <=9
Mesazh gabimi
Përllogaritja
ndalon.
Dështon
Përllogaritja
është kryer
gabim
3 Asnjë Testimi
i vitit
ijk s.t. i>2
0 <=j,k <=9
Mesazh gabimi
Përllogaritja
ndalon.
Dështon
Përllogaritja
është kryer
gabim
4 Asnjë Testimi
i vitit
ijkl s.t. i>2
0 <=j,k,l <=9
Mesazh gabimi
Përllogaritja
ndalon.
Dështon
Përllogaritja
është kryer
gabim
5 Asnjë Testimi
i vitit
ijkl s.t. i=1
dhe j=9
0 <=k,l <=9
Po
Përllogaritja
brënda intervalit
të këndit.
Kalon Sukses
55
Për operacionin e llogaritjes së pozicionit satelitor, është paraqitur dokumentacioni i
testimit në Tabelën 3-5.
Tabela 3-5: Dokumenti përmbledhës i testimeve
Java 1 Java 2 Java 3 Java 4 Java 5 Java 6
Përfunduar % 17% 33% 50% 67% 83% 91%
Teste të kaluara 50 50 50 50 50 22
Test të dështuara 0 0 0 0 0 0
Numri total i testeve të
planifikuara 300 300 300 300 300 300
Numri total i testeve të
përfunduara 50 100 150 200 250 272
Duke qenë se është e pamundur paraqitja e të gjitha rezultateve të testimeve të
përdorura, kemi paraqitur rezultate në grafikun përmbledhës, Figura 3-10, për testime
të kryera në gjashtë javë.
Figura 3-10 Rastet e përfunduara të testimit
A është plotësuar objektivi i besueshmërisë?
Nga raportet e testimit të paraqitura në seksionin e mëparshëm dhe të dhënat e
mbledhura gjatë testimit, rezultati i eksperimentit tregon se sistemi softuerik ka një
besueshmëri më të lartë, prej përafërsisht 0.99, në krahasim me objektivin e vendosur
fillimisht të besueshmërisë prej 0.96. Duhet theksuar se eksperimenti është kryer gjatë
56
një situate normale operacionale; nevojiten që testimet të zhvillohen në situata kritike
operacionale, duke matur më tej besueshmërinë e përgjithshme e sistemit.
3.4 Performanca dhe testimi i ngarkesës së platformave cloud përkundrejt
serverëve klasikë. Rast studimi: Aplikimi i një rrjeti social
Në disa punime (Kamra, Manna, and IEEE 2012; Yan et al. 2012; Yu et al. 2010)
jepen vlerësime të plota të ofruesve të infrastrukturës cloud dhe mundësive të
pafundme të shkallëzimit sipas nevojës, për një numër të madh përdoruesish. Por, nuk
është realizuar një krahasim i plotë ndërmjet infrastrukturës klasike të serverit dhe
infrastrukturës cloud, e cila mbështetet kryesisht në serverat virtualë për të vënë në
dispozicion në mënyre efikase dhe pa ndërprerje shërbimet.
Në këtë rast studimi kemi ndjekur qasjen klasike të besueshmërisë dhe testimit të
ngarkesës, duke identifikuar fillimisht operacionet kryesore, të cilat ofrohen nga një
aplikacion i rrjetit social. Bazuar tek SRE, kemi identifikuar operacionet e duhura dhe
i kemi përdorur ato për të marrë vendimet rreth testimit. Meqenëse shumica e
aplikacioneve të shpërndara përbëjnë një sfidë të madhe për të ndërtuar një profil
operacional të saktë dhe të plotë, ne i kemi kushtuar vëmendje kryesisht operacioneve
që do të përfshijnë një numër të madh të përdoruesve fundorë dhe ndërveprimin e tyre
me aplikacionin web.
Ky profil operacional do të ndihmonte në vlerësimin sasior, duke krahasuar nëse
infrastruktura cloud ofron përshkallëzim më të mirë se një Server me fuqi të lartë të
CPU-së dhe një memorie me kapacitet të madh. Për një krahasim të përshtatshëm, ne
jemi përpjekur të zgjedhim të njëjtën teknologji të ofruar nga Windows Server dhe
Azure cloud. Është e arsyeshme të bëhet një krahasim i tillë në mënyrë që bizneset
ose përdoruesit, të cilët në fakt po konsiderojnë një migrim nga një platformë në
tjetrën, të jenë të sigurtë se çfarë presin. Testimi u krye në mjedisin softuerik të
Microsoft-it. Në këtë rast, arritëm përputhje me performancën e rrjetit dhe
shkallëzimin e saj në kushtet e ngarkesës për të dyja platformat si dhe për metrikat
kryesore te zgjedhura, duke iu përgjigjur pyetjes nëse një Microsoft Windows Server
me performancë optimale në kuptimin e CPU, RAM, Bandwidth, do të jetë në gjendje
për të ofruar një përgjigje më të përshtatshme përdoruesve fundorë në krahasim me
Azure cloud me karakteristika të ngjashme të instancave të makinës virtuale në
dispozicion. Kjo pyetje ka marrë përgjigje me metodologjinë e propozuar nga procesi
SRE, bazuar në rezultate eksperimentale.
3.4.1 Aplikacioni dhe përshkrimi funksional i platformës
Aplikacioni synon të kontribuojë në implementimin e një rrjeti social duke u
mbështetur në funksionalitete, të cilat e bëjnë të dobishëm për studentët dhe stafin
akademik te nje universiteti. Aplikacioni ka karakteristikat e mëposhtme:
1. Regjistrim dhe hyrje për përdoruesit e universitetit.
2. Kërkesa miqësie.
3. Postimi i mesazheve dhe komente me miqtë.
4. Shfaqja e statusit ne online/offline për përdoruesit e tjerë.
5. Biseda/Chat në kohë reale mes përdoruesve te komunitetit.
57
Aplikacioni është zhvilluar në C, .NET 4. Gjithashtu është lidhur me një bazë të
dhënash që punon në serverin MSSQL 2008, me qëllim që të ruajë të gjitha të dhënat
rreth përdoruesve, që hyjnë në rrjetin social. Aplikacioni është vendosur në dy
platforma:
1. Windows server 2008 me IIS 7.5 R2 (Windows Server 2014).
2. Azure cloud me 3 instanca që ekzekutohen në Windows server 2008 me IIS
7.5.
Të dy platformat janë të krahasueshme në aspektin e performancës dhe kapacitetit
harduer siç tregohet në Tabelën 3-6.
Tabela 3-6: Krahasimi i platformave cloud vs server klasik
Server Cloud Azure Publik - 3 instanca te vogla
Azure Cloud
CPU: AMD Operon 2x2.2 GHz CPU: 1.6 GHz / Instancë
Memoria: 40 GB Memoria: 1.7 GB/ Instancë
Gjerësia e bandës: 100Mbs Gjerësia e bandës: 100Mbs
3.4.1.1 Zhvillimi i profilit operacional
Për të kryer testimin e aplikacionit duhet të zhvillohet së pari profili operacional, që
udhëheq vendimin e testimit. Për shkak të mbledhjes të të dhënave eksperimentale,
gjatë testimit të performancës/ngarkesës kemi ndarë profilet operacionale bazuar në
numrin e përdoruesve. Megjithatë, mënyrat operacionale janë të njëjta në të dyja
rastet. Kjo ka kërkuar identifikimin dhe përdorimin e dy profileve operacionale:
1. 30 përdorues (për të kryer testimin e performancës), të paraqitur në Tabelën 3-7.
2. 200 përdorues (për të kryer testimin e ngarkesës), të paraqitur në Tabelën 3-8.
Tabela 3-7: Profili operacional për 30 përdorues
Operacione Ngjarjet x30 Probabiliteti i ngjarjeve
(min–max) %
Regjistrim 1-2 30-60 3.1-3.8
Hyrje / Dalje 2-4 60-120 6.3-7.5
Kërkim 20-30 600-900 62.5-56.6
Përftim copëze postimi 5-10 150-300 15.6-18.9
Profili im 3-5 90-150 9.4-9.4
Online / offline 1-2 30-60 3.1-3.8
Total 960-1590 100-100
58
Tabela 3-8: Profili operacional për 200 përdorues
Operacione Ngjarjet x200 Probabiliteti i ngjarjeve
(min–max) %
Regjistrim 1-2 200-400 3.1-3.8
Hyrje / Dalje 2-4 400-800 6.3-7.5
Kërkim 20-30 4000-6000 62.5-56.6
Përftim copëza postimi 5-10 1000-2000 15.6-18.9
Profili im 3-5 600-1000 9.4-9.4
Online / offline 1-2 200-400 3.1-3.8
Total 6400-10600 100-100
Paraprakisht është zhvilluar profili operacional duke siguruar vlera të mundshme për
shkallën e shfaqjes së operacioneve fillimisht për një përdorues të vetëm dhe në vijim,
sipas llojit të profilit operacional për një numër përdoruesish 30 ose 200. Shkallët e
ngjarjes, në rastin tonë, janë vendosur për çdo mënyrë operacionale bazuar në përvojë
dhe hamendësim. Probabiliteti është përcaktuar nga formula e mëposhtme:
𝑷𝒓𝒐𝒃𝒂𝒃𝒊𝒍𝒊𝒕𝒆𝒕𝒊 𝒊 𝒏𝒈𝒋𝒂𝒓𝒋𝒆𝒔 =𝐧𝐮𝐦𝐫𝐢𝐧 𝐞 𝐧𝐠𝐣𝐚𝐫𝐣𝐞𝐯𝐞
𝐧𝐮𝐦𝐫𝐢𝐧 𝐭𝐨𝐭𝐚𝐥
Përcaktimi i probabilitetit të ngjarjeve do të ishte mjaft i dobishëm në përcaktimin e
operacioneve kritike ose jo kritike. Kështu do të ofrohej një shpërndarje më e mirë e
testeve të zhvilluar (p.sh. probabiliteti i ulët i ngjarjeve mund të identifikojë
operacionet të ndodhura rrallë me një kontribut më të ulët në besueshmërinë e
përgjithshme të sistemit).
Rezultatet e këtij punimi kanë treguar disa dallime të mëdha ndërmjet platformave
cloud dhe serverit në aspektin e shkallëzueshmërisë dhe performancës, respektivisht
të paraqitur në kolona blu për cloud dhe kolona të kuqe për serverin, figura 3-11. Në
shumicën e grafikëve në figurën 3-11 të marra nga të dhënat e mbledhura gjatë
eksperimentit sipas profilit operacional të zhvilluar, mund të vërehet se për një numër
të barabartë përdoruesish, cloud ka shfaqur performancë më të lartë sidomos në
kushtet e përgjigjes dhe kohës së paraqitjes të faqes web. Këto rezultate kanë provuar
efektivitetin e përdorimit të cloud-it në krahasim me serverat klasik, veçanërisht për
një numër në rritje të përdoruesve, duke siguruar kështu përshkallëzim më të mirë.
Në grafikët e parë, ne mund të vëzhgojmë një kohë më të shpejtë të reagimit të cloud
krahasuar me serverin, edhe për një numër më të madh përdoruesish. Ky trend është
ruajtur edhe për operacionet e tjera të paraqitura në kohën mesatare të përgjigjes dhe
metrikat e kohës mesatare të faqes ueb.
59
Nga testet e kryera, vërehet se të dy platformat ruajtën performancë të njëjtë për një
numër të vogël lidhjesh për sekondë (rreth 20 lidhje/sek). Sidoqoftë, për një numër më
të madh lidhjesh, cloud ruajti përshkallëzimin e tij dhe veproi shumë më mirë në
kushtet e ngarkesës. Serveri nuk ishte në gjendje të ruante performancën e tij, referuar
kohës së përgjigjes në kushtet e ngarkesës, duke provuar kështu pohimin se platformat
cloud janë më të mira dhe ruajnë performancën e tyre, kur i ofrohet shërbimi një
numri më të madh përdoruesish. Ky rast studimi ka shërbyer në dhënie përgjigje të
pyetjes kërkimore 2 dhe vërtetimin e hipotezës 2.
Figura 3-11 Testi i performancës cloud përkundrejt serverit për 30 dhe 200
përdorues.
60
3.5 Përmbledhje
Në këtë kapitull kemi parashtruar disa raste studimi ku testimi i bazuar në SRE është
aplikuar me sukses si për aplikimet cloud ashtu dhe për aplikime të tjera. Rezultatet e
marra gjatë implementimeve kanë nxjerrë në pah efikasitetin e testimit të
besueshmërisë dhe qasjeve tolerante ndaj të metave në sistemet e ndryshme
softuerike.
Qëllimi i kërkimit shkencor të paraqitur në këtë kapitull lidhet me mundësinë e
përdorimit në mënyrë të plotë dhe inovative të metodologjisë SRE së bashku me
teknikat tolerante ndaj të metave duke ju dhënë përgjigje si pyetjes shkencore 0 ashtu
dhe hipotezës 0.
Gjithashtu këto raste studimi na kanë dhënë mundësinë që të kontribuojmë dhe në
parashtrimin e hipotezave dhe pyetjeve të tjera shkencore të cilat do të diskutohen në
kapitujt në vijim. Punimet shkencore që mbështesin plotësisht diskutimet e trajtuara
në këtë kapitull janë prezantuar në konferencat ndërkombëtare (Cico and Dika, and
DSC 2014; Cico, Dika, and IEEE 2014) dhe revistën (Cico 2018).
61
KAPITULLI 4: BESUESHMËRIA SI MODEL SHËRBIMI - RAAS
4.1. Hyrje
Në këtë kapitull, paraqitet përdorimi i diversitetit në projektim, në të dhëna dhe në
kohë, për një aplikacion të implementuar në Google cloud. Vlerësimi bazohet në
Inxhinierinë e besueshmërisë së softuerit (SRE), e trajtuar në kapitullin 2.
Aplikacionet e shpërndara zakonisht paraqesin një sfidë të madhe për të ndërtuar një
profil operacional korrekt dhe të plotë, por në rastin e studimit tonë kemi marrë në
shqyrtim operacionet më kritike dhe kemi zbatuar teknikat e përmendura më parë
vetëm për komponentët më kritikë të sistemit softuerik. Windfarmdesigns është
zhvilluar në strukturën Django’. Softueri përfshin një algoritëm unik që kryen
optimizimin e vendosjes të turbinave në një kamp ere (wind farm layouts) (Mosetti,
Poloni, and Diviacco 1994). Algoritmi është implementuar nga dy ekipe zhvillimi në
dy gjuhë programimi të ndryshme, Python dhe MATLAB, bazuar në teknikën e
diversitetit në projektim me N-Versione (Avizienis and Kelly 1984).
Algoritmet ekzekutohen paralelisht në të njëjtën instancë të GCE. Arkitektura e
shpërndarë e sistemit është një shembull i mirë për të provuar efikasitetin e teknikave
të diversitetit në kohë dhe të dhëna për të përmirësuar
disponueshmërinë/besueshmërinë e sistemit në përgjithësi. Këto teknika mund të
aplikohen në nivel krijimi të instancave të makinave virtuale në cloud. Pra, teknikat e
tjera të aplikuara lidhen me diversitetin në kohë dhe atë të të dhënave, të cilat bazohen
në blloqet e kontrollit për riprovim dhe rikuperim RtB dhe RcB) gjatë krijimit të
instancave cloud. Të gjitha teknikat e zbatuara dhe metodologjia e propozuar nga
procesi SRE dëshmojnë për efikasitetin e tyre gjatë eksperimenteve të kryera. Qëllimi
i këtij kapitulli është të mbështesim vërtetimin e hipotezës 2 dhe ti japim përgjigje
pyetjes shkencore 2 të parashtruara në kapitullin e parë. Përpara realizimit të
eksperimenteve kemi diskutuar teknikat e tolerancës ndaj gabimeve të cilat janë
adoptuar sipas nevojave përkatëse të rastit të studimit marrë në shqyrtim.
4.2. Modeli dhe ambient i punës të RaaS
Shumica e teknikave të përmendura më parë janë adoptuar me një qasje sipas rastit
ndaj arkitekturave të ndryshme cloud. Duke marrë në konsideratë faktin që shumë
prej tyre adresojnë çështje të ngjashme për ofruesit e ndryshëm të shërbimeve cloud,
lind nevoja e adaptimit të një platforme apo strukture në nivelin e shërbimit cloud.
Kjo qasje mund të konsiderohet e duhura për aplikimet, të cilat kanë kërkesa
disponueshmërie/ besueshmërie të larta. Në figurën 4-1 propozohet një alternativë
cloud e cila ofron besueshmërinë si shërbim RaaS. Nga figura vërejmë se mund të
përdoren dhe teknika të tolerimit ndaj të metave/dështimeve për shërbime të
ndryshme cloud, si dhe mund të ofrohet një strukturë në nivel aplikacioni për
përdoruesit fundor. Kjo do të lehtësonte procesin e integrimit të besueshmërisë së
lartë në zhvillimin e aplikacioneve cloud.
4.2.1. Besueshmëria si model shërbimi në cloud - RaaS
Teknikat e aplikuara mund të jenë në shtresa të ndryshme të shërbimit, duke u
mbështetur në qasjet e trajtuara në kapitullin 2. Një pjesë e teknikave, të tilla si blloqet
e riprovë, diversiteti i të dhënave, mund të aplikohen në shtresën PaaS ndërsa të tjerat
62
mund të aplikohen edhe në shtresa të ndryshme të shërbimeve paralelisht (p.sh.
diversiteti i projektimit dhe programimi me N-versione). Disa nga teknikat janë
tashmë të disponueshme në shtresën IaaS, sikurse dhe redundanca. Ofruesi i shërbimit
cloud dhe përdoruesi fundor duhet të kenë lirinë e miratimit dhe zgjedhjes së nivelit të
shërbimit ku do të zbatohen teknikat, me përpjekje minimale nga ana e tyre.
Figura 4-1 Besueshmëria si model shërbimi në cloud RaaS
4.2.2. Besueshmëria si model strukture në cloud
Zhvilluesit e cloud-it duhet të mbështeten nga një strukturë, të cilën ata mund ta
shfrytëzojnë për të ndërtuar lehtësisht aplikacione të besueshme cloud. Modeli i
propozuar paraqitet në figurën 4-2. Ne kemi propozuar një strukturë të tillë, që
përdoruesit fundorë (klientët cloud) të shfrytëzojnë lehtësisht teknikat e ndryshme të
tolerancës ndaj të metave, sidomos në shtresën SaaS. Në këtë mënyrë teknikat e
kodimit mund të aplikohen drejtpërdrejt në komponentët e programeve të përdorura
nga zhvilluesi. Ky i fundit mund të zhvillojë manualisht kodin ose në disa raste të
mbështetet në gjenerimin e kodit, si pjesë e një strukture softuerike. Të dyja shtresat e
tjera të shërbimit (PaaS, IaaS) mund të mbështeten nga struktura e propozuar, sidomos
përsa i përket adaptimit manualisht ose jo të teknikave të ndryshme të tolerimit ndaj të
metave/dështimeve. Në mënyrë që të automatizohet procesi, shumica e teknikave
duhet të integrohen plotësisht me ndërfaqet e duhura (“Application Programming
Interface” - API) brenda aplikimeve cloud. Nga figura 4-3 mund të vëzhgohet se pas
63
kalimit të aplikacionit në cloud, zhvilluesi ka opsionin e një ndërfaqe grafike për të
zgjedhur tipin e teknikës së tolerimit të të metës/dështimit, që mund të aplikohet në
shtresa të ndryshme shërbimi për funksionalitete të ndryshme.
Figura 4-2 Besueshmëria si model shërbimi në cloud RaaS
4.2.3. Rast studimi: “WINDFARMDESIGNS”
Në punimin tonë është marrë në konsideratë një aplikacion i bazuar në Google cloud
(Windfarmdesigns) për optimizimin e prodhimit të energjisë nga era. Ky aplikacion
cloud siguron mundësinë për të gjeneruar paraqitjen e pozicionimit të turbinës me erë
në një park ere, Figura 4-3. Përdoruesi mund të përcaktojë të dhënat hyrëse nëpërmjet
ndërfaqes, si dhe skedarin në të cilin do të kryhet optimizimi dhe do të ekzekutohet
algoritmi. Aplikacioni përbëhet nga tre nënsisteme kryesore:
1. Nënsistemi 1: Logjika e Aplikacionit Frontend (Aplikacioni Django që
ekzekutohet në GAE)
2. Nënsistemi 2: Logjika e Aplikacionit Backend (Aplikacioni Django që
ekzekutohet në GCE)
64
3. Nënsistemi 3: Implementimi i algoritmit inxhinierik (Aplikacioni Python /
MATLAB).
Figura 4-3 Ndërfaqja WINDFARMDESIGNS duke përpunuar të dhënat e
pozicionimit të turbinave të erës
Figura 4-4 përfaqëson diagramin e rasteve të përdorimit ku funksionalitetet primare
jepen si më poshtë:
• Ekzekutimi i një operacioni.
• Lexo listën e optimizimit.
• Fshirja e optimizimit.
• Shfaqja e konfigurimeve për vendosjen e turbinave.
• Shfaqja e hartave të ndryshme (harta e erës, harta e energjisë, zona e
planifikimit, kufizimet e pozicionimeve të turbinave).
Ndërsa aktori kryesor është përdoruesi fundor i regjistruar në shërbim.
Figura 4-4 Diagrami i rasteve të përdorimit
65
Ndërkohë figura 4-5 paraqet një nga diagramet e sekuencës në lidhje me ekzekutimin
e një optimizimi të suksesshëm.
Figura 4-5 Diagrami sekuencial
Operacionet primare për një përdorues të regjistruar dhe të loguar si dhe probabiliteti i
tyre paraqiten në Tabelën 4-1.
Tabela 4-1: Profili Operacional
Vendosja e
testeve
(1000/vit)
Komponentët e
përfshire
Probabiliteti i
rastit
Nr. mesatar i
rasteve
Përdor./muaj
Operacionet
330 GAE/GCS/GCSQL 33% 100 Vizualizo listën e
optimizimeve
170 GAE/GCE 17% 50 Krijo makinen
verituale ne GCE
170 GAE/GCS/GCSQL/G
CE 17% 50
Thirr optimizimin
330 GAE/GCS/GCSQL 33% 100 Vizualizo rezultatet
e optimizimit
66
Figura 4-6 paraqet arkitekturën e sistemit softuerik dhe komponentët e tij.
Komponentët kryesorë, ku mund të aplikohet toleranca ndaj të metave, janë
aplikacioni GAE, pjesë e PaaS, veçanërisht moduli i krijimit të instancës dhe thirrjet
URL të kryera për të komunikuar me nënsistemet e tjera. Në këtë rast, diversiteti i
përkohshëm është një qasje e arsyeshme, që kërkesat REST të kryhen përmes API të
Google për të inicializuar shërbime të tjera (psh. instancat GCE). Megjithatë, duke
punuar në një infrastrukturë cloud, jo të gjitha shërbimet gjatë krijimit të makinave
virtuale janë të disponueshme menjëherë dhe mund të ndodhin probleme të
rastësishme në varësi të gjendjes aktuale të infrastrukturës.
Figura 4-6 Diagrami i komponentëve të “Windfarmdesings”
Në studimin tonë merret parasysh inicializimi i kartës së rrjetit për rastin e makinës
virtuale GCE. Gjatë ekzekutimit të aplikacionit ka ndodhur një gabim i rastësishëm
pasi instruksioni i makinës virtuale nuk i është përgjigjur në mënyrën e duhur
kërkesës së URLs, e paraqitur edhe në Figurën 4-6. Gjendja e vetë infrastrukturës
cloud shoqërohet me gjenerimin e një gabimi të përkohshëm, që ndodhi në këtë rast.
Problemi pothuajse u eliminua plotësisht me teknikën e diversitetit në kohë, duke
përsëritur kërkesën e URL-së me të dhëna të njëjta në hyrje, deri në përftimin e një
rezultati të saktë. Kodi më poshtë tregon implementimin në Python të diversitetit në
kohë për rastin e shqyrtuar:
67
Tabela 4-2 paraqet një përmbledhje të rezultateve të testimit të orientuara nga profili
operacional i përshkruar në tabelën 4-1.
Tabela 4-2: Rezultatet e testimeve
Testet e
sukseshme
(Diversitet
Arkitekturor)
Testet e
sukseshme
(Diversitet ne
Kohe)
Testet e
sukseshme
(Pa FT)
Numri i testeve në
përdorim (1000
teste /vit )
Operacionet
320 320 320 330 Vizualizo listën e
optimizimeve
165 165 165 170 Krijo makinën
virtuale në GCE
167 167 92 170 Thirr optimizimin
320 317 317 330 Vizualizo rezultatet
Siç vihet re nga tabela (përmes vlerave të theksuara me ngjyrë të zezë) besueshmëria e
re e matshme gjatë testimit është 0.98 në krahasim me 0.54 nga zbatimi i mëparshëm,
duke përfituar një rritje të konsiderueshme të besueshmërisë. Vlen të përmendet se
besueshmëria e sistemit varet dhe nga komponentët e tjerë të softuerit, ku mund të
konsiderohet më e dobishme përdorimi i teknikës së diversitetit të projektimit. Një
nga këto komponentë është dhe algoritmi i optimizimit, i cili funksionon në GCE.
Edhe pse për këtë rast studimi ky nuk përbën operacionin më kritik, në përgjithësi
GCE ka për qëllim të realizojë përllogaritje intensive, kështu që besueshmëria e lartë e
llogaritjeve është tejet e rëndësishme. Nëse rezultatet do të ishin të gabuara atëherë do
të vihej re një ndikim i drejtpërdrejt në kosto dhe kohë. Nga diagrami i arkitekturës së
sistemit në figurën 4-6 dalin në pah komponentët për të cilat është i zbatueshëm
diversiteti i projektimit. Algoritmi është zhvilluar në MATLAB dhe gjuhën e
programimit Python nga dy skuadra të ndryshme, të cilat kanë filluar punën me
kërkesa të njëjta ndaj softuerit. Ekzekutimi i llogaritjeve fillon paralelisht dhe
rezultatet e fituara vlerësohen nga një votues. Ky i fundit kontrollon konsistencën e
rezultateve të përftuara nga të dy implementimet, duke vënë në dispozicion të
i = 0
w h i l e s t a t u s != OK and r e q u e s t :
# a d j u d i c a t o r
f e t c h _ u r l _ r e q u e s t ( h t t p : / / 1 3 0 . 2 1 1 . 8 4 . 1 3 5 / wind farm / gscon
/ ? e l i p _ p a r a m _ b=0& e l i p _ p a r a m _ a=0& u t m_zone=32+U+&t
imestamp = 2 0 1 5 0 6 0 4 1 0 4 9 3 1 . . . )
t i me . s l e e p ( 2 ** i )
# r e t r y w i t h b a c k o f f p h i l o s o p h y
i = i + 1
68
përdoruesit përfundimtar rezultatet, kur të paktën një nga ekzekutimet realizohet me
sukses. Nga ekzekutimet dhe testimet e zbatuara del në dukje një përmirësim i
besueshmërisë të sistemit me 0.9% (nga 99% në 99.9%). Megjithëse vlera e këtij
përfitimi është e rendit 1% dhe kërkon përpjekje të konsiderueshme në implementim,
ajo justifikohet me faktin që optimizimet kërkojnë një kohë relativisht të gjatë, deri në
disa ditë, kështu që një gabim për shkak të infrastrukturës ose përllogaritjeve mund të
rezultojë me kosto të lartë. Pra një përmirësim dhe me më pak se 1% në
besueshmërinë e sistemit përkon me kursimin e orëve të tëra përllogaritjeje duke
evituar dështimet e sistemit.
4.2.4. Krahasimi i rezultateve
Në figurën 4-7 paraqiten rezultatet e krahasuara të marra gjatë testimit të softuerit për
të vërtetuar efikasitetin e teknikave të aplikuara në nivelin PaaS. Rezultatet tregojnë
se adoptimi i teknikave të tolerimit ndaj të metave ul normën e dështimit gjatë testeve
të kryera për 2000 - 8000 orë pune. Ky rast studimi i jep përgjigje pyetjes kërkimore 2
dhe mbështet vërtetimin e hipotezës 2.
Figura 4-7 Rezultatet e testimeve
69
4.3. Diskutime
Shumica e shërbimeve cloud sot shfrytëzojnë disa gjuhë programimi në një mjedis ku
një numër i madh makinash virtuale bashkëpunojnë ndërmjet tyre. Kjo e bën më të
lehtë procesin e zbatimit të teknikave të ndryshme të tolerancës ndaj
gabimeve/dështimeve në një strukturë të unifikuar. Gjithashtu nivelet e shërbimit
cloud ku ato zbatohen mund të jenë të ndryshme siç dëshmohet dhe në rastin e
studimit apo dhe në tabelën 4-3. Implementimi i strukturës duhet të mbështetet në
gjuhët e zakonshme të programimit, të përdorura nga ofruesit e shërbimeve cloud në
nivelin PaaS, tabela 4-4.
Tabela 4-3: Teknikat e tolerancës ndaj gabimeve adaptuar nëpërmjet një
strukture cloud
Teknika e sygjeruar per tolerancën
ndaj gabimeve SaaS PaaS IaaS
Diversiteti arkitekturor (NVP, RcB) x
Diversiteti i të dhënave (RtB) x
Diversiteti në koheë i kombinuar me
diversitetin arkitekturor (RcB)
x
Tabela 4-4 tregon se ofruesit më të njohur përdorin pothuajse të njëjtat gjuhë
programimi. Struktura mund të zbatohet gjerësisht duke mbështetur si fillim gjuhët
kryesore dhe duke lejuar më tej përdorimin e gjuhëve të tjera të programimit.
Tabela 4-4: Gjuhët e programimit në PaaS për ofrues të ndryshëm të shërbimeve
Cloud
Ofrues shërbimi cloud Emërtimi Gjuhët e programimit në PaaS
Google GAE Go, PHP, Java, Python, Node,
.NET, Ruby
Amazon AWS Elastic
Beanstalk
Java, .NET, PHP, Node.js, Python,
Ruby, Go, Dockers
Microsoft Azure Azure Cloud
Services
Java, .NET, PHP, Node.js, Python,
Ruby
4.4. Përmbledhje
Në këtë kapitull, është paraqitur adaptimi i teknikave të tolerimit ndaj të
metave/dështimeve në infrastrukturën cloud të Google-it. Rasti i studimit është pjesë e
konceptit, që lidhet me krijimin e një strukture cloud që ka si qëllim përmirësimin e
besueshmërisë të softuerit. Kërkesat për softuerë kritike të besueshëm do të rriten në
të ardhmen si rezultat i sfidave të reja të shfrytëzimit cloud në qytetet inteligjente
(smart cities) dhe ndoshta më vonë në sistemet hapësinore, në ato satelitore, ku
70
përllogaritjet mund të kërkojnë shumë kohë për tu realizuar. Shumica e shërbimeve
cloud sot shfrytëzojnë disa gjuhë programimi në një mjedis ku një numër i madh
makinash virtuale bashkëpunojnë ndërmjet tyre. Kjo e bën më të lehtë procesin e
zbatimit të teknikave të ndryshme të tolerancës ndaj gabimeve/dështimeve në një
strukturë të unifikuar. Gjithashtu nivelet e shërbimit cloud ku ato zbatohen mund të
jenë të ndryshme siç dëshmohet dhe në rastin e studimit apo dhe në tabelën 4-3.
Implementimi i strukturës duhet të mbështetet në gjuhët e zakonshme të programimit,
të përdorura nga ofruesit e shërbimeve cloud në nivelin PaaS.
71
KAPITULLI 5: MJEDISI I ZHVILLIMIT TË INTEGRUAR SI NJË
SHËRBIM - IDEAAS
5.1. Hyrje
Në këtë kapitull, propozohet zbatimi i një shërbimi të ri IDEaaS si pjesë e shërbimeve
ekzistuese të cloud-it. Fillimisht kemi hulumtuar ofruesit kryesor të cloud (Amazon,
Google, Azure) si dhe qasjet e tyre ekzistuese për zhvillimin e softuerëve në cloud
(Voorsluys, Broberg, and Buyya 2011). Megjithëse ndonjëri prej tyre rezulton në këto
shërbime përpara të tjerëve, asnjëri nuk ka integruar plotësisht një mjedis
bashkëpunues për zhvillimin e kodit drejtpërdrejt në infrastrukturën cloud. Deri më
tani ato kanë adoptuar zgjidhje sipas rastit (JAVAWIDE 2018), (Aho et al. 2011) ose
zgjidhje të mbështetura në palë të treta (Aho et al. 2011). Megjithate, asnjeri nga dy
opsionet nuk ka arritur të ofroje një integrim të plotë me infrastrukturën e cloud ose
nuk ofrojnë një model të duhur biznesi, që u përshtatet më së miri si qiramarrësve
cloud ashtu dhe përdoruesve fundorë. Përparësitë e përdorimit të mjediseve të
zhvillimit online janë diskutuar gjerësisht në (Frost 2007), (van Deursen et al. 2010),
(Zeller and Society 2007).
Në këtë kapitull përshkruhet arkitektura IDEaaS e propozuar nga ana jonë, duke
krahasuar dy modele të mundshme për të integruar mjedisin e zhvillimit të kodit në
cloud duke u bërë kështu pjesë e infrastrukturës cloud si një SaaS ose duke qëndruar
si një shërbim i ri në vetvete. Integrimi i IDE ofrohet gjithashtu nëpërmjet një
shërbimi, që funksionon në GAE i quajtur “GAE Launcher”. SDK i Google Cloud
është transferuar nga versioni i tij desktop në platformën cloud duke ofruar funksione
të ngjashme me ato ekzistuese, si dhe duke ofruar funksionalitete të reja. Aktualisht
GAE Launcher funksionon me SDK të python-it, por gjithashtu mund të shtohen dhe
gjuhë të tjera programimi me të njëjtën qasje. Struktura e re lejon gjithashtu krijimin e
modeleve të reja të biznesit, të ngjashme me ato ekzistueset. Dy propozime tonat për
realizimin e projekteve softuerike dhe ofrimin e mundësive të reja të shërbimeve nga
palë të treta, janë:
• Paguaj sipas përdorimit të kohës të kodimit (“Pay as you go Coding” –
PaygoC).
• Kodim sipas kërkesës (“On Demand Coding” – ODC).
.Nëpërmjet IDEaaS do të përfitohej reduktimi i shpenzimeve të instalimit
(infrastruktura, SW, HW, licencimi etj.) për zhvillimin e kodit në cloud. Gjithashtu,
në menaxhimin e projekteve, do të mundësohej rritja e produktivitetit për projekte të
realizuara në shkallë të gjerë, ulja e kostove dhe mundësitë e delegimit të punës në
palët e treta. Shërbimi i ri do tu mundësonte ofruesve të shërbimeve cloud penetrimin
në tregje të reja, shërbime më të mira dhe do të rriste produktivitetin e përdoruesve
fundorë.
Rezultatet e përftuara në këtë kapitull kanë shërbyer për të mbështetur hipotezat 1 dhe
3 si dhe për t’ju dhënë përgjigje pyetjeve shkencore 1 dhe 3 respektivisht.
5.2 Implementimi
Në këtë seksionin do të shqyrtojmë mundësinë e adaptimit të koncepteve të ngjashme
për një mjedis IDE të përgjithshëm (inkapsulimin e SDK-ve të ndryshme cloud). Në
72
seksionin në vijim do të japim një shembull të zbatimit të modelit të zhvilluar në
platformën Google cloud.
5.2.1. IDEaaS - Modeli i propozuar
Modeli IDEaaS i propozuar duhet të përfshij këto entitete:
• SDK të bazuar në shfletues (browser) të integruar plotësisht me shtresat e
ndryshme të shërbimit (PaaS, IaaS) dhe REST API apo libraritë e klientëve të
cloud.
• IDE e bazuar në shfletues që përfshijnë funksionalitetet SDK brenda
platformës.
• Mjet i zhvillimit që shfrytëzon plotësisht modelin pagesë sipas përdorimit
(‘pay per use’) ose pagesë për shërbimet e shfrytëzuara (’pay as you go’).
• Sinkronizimi i kodimit përmes ruajtjes të versioneve me mjete online si
GitHub, Jira etj. Kështu që zhvilluesit mund të përdorin IDE-të e tyre offline
dhe të sinkronizojnë më tej kodin.
Integrimi i platformës së mjedisit të zhvillimit (IDE) në cloud dhe trajtimi i tij si një
shtresë e zakonshme shërbimi do të mundësojë një mjedis të integruar të zhvillimit të
kodit, që mund të shkallëzohet sipas kërkesës. Gjithashtu, do t’ju ofrojë ekipeve të
zhvillimit një vlerësim më të mirë të kostos si dhe do ti ndihmojë ata të përqendrohen
në përmbushjen e afateve kohore për përfundimin e kodimit, në mjedise
bashkëpunuese të bazuara tërësisht në cloud. Komuniteti i bazuar në kodin me burim
të hapur do të lehtësohet edhe më tej, duke bashkuar një platformë të përbashkët cloud
dhe duke adoptuar modele të reja të kodimit siç janë kodim sipas kërkesës dhe pagesë
sipas orëve të kodimit. Gjithashtu mund të ofrohen teknika për kodimin mbështetur në
algoritme inteligjente. IDEaaS mund të adaptohet sipas rregullave të biznesit dhe
kërkesave specifike të korporatave që lidhen me politikat, privatësinë dhe mbrojtjen e
të drejtave të autorit, duke adoptuar në mënyrë të ndryshme zgjidhjet publike, private
ose hibride cloud. Figura 5-1 përfaqëson platformën tonë.
5.3. Metodologjia e implementimit
Ne mund të vëzhgojmë qartë shtresat cloud duke adoptuar shërbimet e zhvillimit të
ofruara nga IDEaaS. Një fokus i veçantë i kushtohet PaaS dhe IaaS të cilat në mënyrë
të qartë janë entitetet primare të shfrytëzuara në infrastrukturën cloud për qëllime
zhvillimi. Optimizimi i shfrytëzimit të tyre ka qenë virtualizimi në nivel makine
virtuale ose sistemi operimi (“Operating System Dockers”– OS Dockers).
73
Figura 5-1 Platforma IDEaaS
Modeli mbështet gjithashtu mundësinë, kur është e aplikueshme, për t’u shfrytëzuar
nga shtresa SaaS, ku aplikacionet e ndryshme mund të përdorin API-në e ofruar nga
IDEaaS në mënyrë që të integrojnë zhvillimin e tyre ose mjedisin e testimit të kodit.
Për herë të parë modeli yne propozon që ofruesit e cloud të përfshijnë mjedisin e
zhvillimit brenda infrastrukturës së tyre. Në këtë mënyrë jo vetëm e bëjmë zhvillimin
dhe vendosjen më efikase të kodit në cloud, por edhe bashkojmë karakteristikat cloud
në një bazë të përbashkët për menaxhimin e shpejtë dhe efikas sipas modeleve
“Agile” të softuerit. Shumica e ofruesve të cloud-it mund të përshtatin shërbimin
IDEaaS si një aplikim cloud i palës së tretë në shtresën e softuerit ose të ofrohen si një
pjesë integrale e infrastrukturës/platformës së tyre, figurat 5-2 dhe 5-3. Modeli i dytë
do të sillte një kontribut dhe zhvillim më të përshtatshëm për burimet e hapura dhe do
të inkurajonte më shumë biznese të bazuara në cloud për të zhvilluar produktet e tyre
në mënyrë efikase.
Ofruesit e tjerë, që tashmë po adaptojnë disa qasje të ngjashme si Amazon ose ato që
ende nuk kanë ndërmarrë hapat e zhvillimit të bazuar në cloud si Azure, mund të
përfitojnë nga modeli i propozuar. Vlefshmëria e konceptit dhe adoptimit të modelit
është paraqitur në seksionin në vijim, ku zhvillimi aktual dhe integrimi i shërbimit
IDEaaS është kryer për një nga ofruesit kryesorë cloud Google Cloud Platform
(GCP).
74
Figura 5-2 IDE si SaaS
Figura 5-3 IDE si shtresë shërbimi në cloud
75
5.4. Përgatitja e eksperimentit dhe vlerësimi i strukturës të propozuar
Në vijim po paraqesim migrimin aktual të librarive Python SDK të Google cloud nga
mjedisi i tyre desktop në GAE. Procesi i kalimit të kodit në cloud nga programuesi,
ndryshe nga më parë, si aplikacion desktop, realizohet tashmë nëpërmjet GAE.
Gjithashtu gjatë punës tonë kemi zhvilluar një interpretues të kodit duke ofruar dhe
mundësinë për të zhvilluar dhe kaluar kodin drejtpërdrejt në cloud. “GAE Launcher”
ofron gjithashtu mundësinë për të sinkronizuar kodin me depozitar si GitHub.
Është e mundur që në të ardhmen të shtohen më shumë karakteristika si dhe zhvillimi
të bëhet pjesë e infrastrukturës cloud duke luajtur një rol vendimtar dhe jo vetëm duke
vepruar si një aplikacion që funksionon në nivel PaaS. Pra, më shumë funksionalitete
nga mjetet gcloud mund të jenë pjesë e një mjedisi zhvillimi më të sofistikuar
plotësisht të integruar në cloud.
5.4.1. Migrimi i GAE në cloud
Migrimi i GAE Launcher Python SDK nga desktop në mjedisin GAE përfshin
modifikimin e disa librarive SDK dhe adaptimin e tyre me libraritë e klientëve
(Django Support 2018) sipas koncepteve të parashtruara në (Mohagheghi 2011). Në
veçanti është adaptuar appcfg.py për tu ekzekutuar në mjedisin GAE. Modifikimet e
zakonshme lidhen me kufizimet në mjedisin e vetë makinave virtuale cloud të tilla si
mungesa e sistemit të skedarëve, krijimi i proceseve, etj. Për këtë arsye janë përdorur
shërbime të tjera cloud si ruajtja e të dhënave në ‘google storage’ dhe SQL në vend të
sistemit të skedarëve lokal. Aplikacioni duhet të ekzekutohet si një proces i vetëm
shërbimi ueb. Kështu ndryshimet kryesore në kod lidhen me shtimin e appcfg.main
(argv) (Google Cloud Python API 2018; Google Cloud Tools: 2018) si më poshtë:
Funksionit main i kalohen një listë me argumente, që përfaqësojnë veprimin që duhet
ekzekutuar. Ndër veprimet kryesore mund të përmenden:
1. Argumentet për autentikimin dhe kalimin në cloud të kodit:
l o g g i n g . b a s i c C o n f i g ( f o r m a t =( ’ %( a s c t i m e ) s %( l e v e l n a m
e ) s %( f i l e n a m e ) s %( l i n e n o ) s %( message ) s ’ ) )
t r y :
r e s u l t = AppCfgApp ( a r g v ) . Run ( )
i f r e s u l t :
s y s . e x i t ( r e s u l t )
e x c e p t:
K e y b o a r d I n t e r r u p t :
S t a t u s U p d a t e ( ’ I n t e r r u p t e d . ’ )
s y s . e x i t ( 1 )
a rg v = [ " . / g o o g l e / a p p e n g i n e / t o o l s / a p p c f g . py " , ’ update ’ , ’ /
g a e l a u n c h e r / ’ + ’ u s e r @gmail . com ’ , "−−e m a i l =" + ’ user@ gmail .
com ’ , "−− p a s s i n " ]
76
2. Argumentet për kthimin pas (“rollback”):
3. Krijimi/fshirja/modifikimi i të dhënave të kërkuara të projektit në GCS
(“Google cloud storage” - GCS) ose depozitarët Git. Kushti paraprak është që
projekti duhet të jetë tashmë një projekt i regjistruar në Google Cloud
Console.
4. Përftimi i historikut (“logs”) për çdo veprim të kryer përdoruesi mund të
shfaqi historikun aktual. Për këtë qëllim është shfrytëzuar moduli google-
cloud-sdk logservice.py . Një shembull kodi që shfaq log-et e gabimeve
paraqitet si më poshtë:
Hapi i parë në qasjen e aplikacionit si një zgjidhje SaaS (Modeli i paraqitur në figurën
5-2), është autentikimi i përdoruesit me backend-in. Ka dy metoda të adaptuara për
këtë qëllim:
1. Shfrytëzimi i emrit të përdoruesit (“username”) dhe fjalëkalimit (“password”)
të përdorur si një listë argumentesh gjatë kalimit të projektit në cloud. Në këtë
rast pengesë bëhet fakti që përdoruesi fundor duhet të përdori kredencialet e tij
në çdo rast të kërkesës të një shërbimi.
2. Një qasje më e sigurtë do të ishte përdorimi i OAuth 2 për autentifikimin në
cloud. Figura 5-4 tregon zgjidhjen e problemit për kërkesat e ardhshme në
(OAuth2 Python API 2018). Për më tepër ekziston mbështetje e plotë për
integrimin e saj me ambientin e punës Django. Ajo është gjithashtu alternativa
më e mirë për implementimin e ardhshëm të IDEaaS bazuar në modelin e
Figurës 5-3.
5.4.2. Funksionalitetet e ofruara
Në këtë seksion diskutohen mundësitë e mëtejshme të aspekteve të ofruara deri tani
për integrimin në cloud të SDK-s. Kodi është integruar nëpërmjet Django 1.11 bazuar
në Python 2.7. Mjedisi aktualisht lejon përdoruesit të kryejnë detyrat e zakonshme
tashmë të disponueshme nga aplikacioni desktop i SDK-së të GAE:
• Krijo/fshij projektin.
• Ndrysho skedarët ekzistues të projektit.
• Transferim në cloud në VM të GAE.
• Kthim prapa i proceseve të transferimit në cloud.
• Përfitimi i historikut (logeve) të veprimeve të kryera.
argv = [”./google/appengine/tools/appc f g.py”,′ rollback′,′ /gaelauncher′]
t o t _ l o g s = l o g s e r v i c e . f e t c h ( end _ t ime = end _ t ime ,
minimum _ l o g _ l e v e l = l o g s e r v i c e . LOG
_ LEVEL _ ERROR, i n c l u d e _ app _ l o g s
= True)
77
Figura 5-4 Përdorimi i OAuth2 për autentifikimin e serverit web19
Në figurën 5-5 paraqiten disa nga veçoritë e zhvilluara aktualisht. Informacione të
mëtejshme mund të gjenden në http://gae-launcher.appspot.com.
Në këto figura mund të vihet re integrimi i karakteristikave të tjera kryesore si:
• Shfletues i bazuar në mjedisin e zhvillimit Python me strukturën
Webapp2/Django.
• Sinkronizimi i projektit nëpërmjet Github.
Integrimi i mëtejshëm me mjetet online për menaxhimin e projekteve si Asana dhe
Jira nxjerrin në pah këto koncepte të lidhura me kodimin në cloud:
• Paguaj sipas orëve të kodimit PaygoC gjatë zhvillimit të projektit.
• Kodimi sipas kërkesës ODC, duke rritur mundësitë e shfrytëzimit të palëve të
treta në implementimin e funksionaliteteve të projektit.
• Përmirësim i vlerësimit të kostove të projektit.
• Përmirësimi i kodimit bashkëpunues në komunitetet, për projekte të mëdha,
duke u mbështetur në platformat cloud.
19 Bazuar në figurën në (OAuth2 Python API 2018)
78
Figura 5-5 Karakteristikat e zhvilluara aktualisht të SDK online
5.4.3. Arkitektura e përdorur
Arkitektura e përdorur përfshin entitete të ndryshme në bashkëpunim me shërbimet
aktuale cloud. Një pasqyrë e shërbimeve të integruara është paraqitur në Figurën 5-6.
Ne mund të vëzhgojmë në këtë figurë në mënyrë të qartë integrimin e
funksionaliteteve për zhvillimin efikas dhe vendosjen e kodit në cloud. Megjithëse
arkitektura aktuale i përshtatet më shumë modelit në figurën 5-2, ajo mund të
integrohet lehtësisht në konsolën aktuale cloud duke paraqitur më shumë shërbime
infrastrukturore si hapësirë disku (Storage), përllogaritje (Compute), StackDriver
(logging, debugging) etj. Ajo lejon disa përdorues të shfrytëzojnë një platformë të
integruar të zhvillimit ku shumë karakteristika janë pjesë e cloud-it të orientuar drejt
zhvillimit. Integrimi nënkupton adaptimin e modelit në figurën 5-3, e cila mund të jetë
pjesë e një shërbimi të ri cloud (IDEaaS).
Për të arritur këtë qëllim, ne kemi zhvilluar më tej IDE-në për tu përshtatur me
mjedisin cloud për korrigjimin e kodit duke u bërë pra pjesë e një platforme të plotë
79
në zhvillimin, testimin dhe vendosjen e kodit drejtpërdrejt në cloud. Figura 5-7 dhe 5-
8 paraqesin gjendjen aktuale të zhvillimit.
Figura 5-6 Arkitektura e adaptuar e GAE Launcher bazuar në modelet IDEaaS
Karakteristikat e ofruara janë të ngjashme me SDK-në e diskutuar më parë por duke
integruar më tej platformën me shërbimet bazë të Google cloud.
80
Figura 5-7 Integrimi i IDEaaS me shërbimet bazë të cloud për menaxhimin dhe
vendosjen e kodit
Konceptet e reja të lindura nga IDEaaS, të tilla si zhvillimi i kodit sipas kërkesës apo
pagesa sipas kohës së përdorimit për kodim, ndihmojnë në menaxhimin e projekteve
cloud dhe kontrollin e versioneve të kodit. Këto modele mund të kontribuojnë
gjithashtu në modelet e reja të biznesit për sistemet e informacionit të bazuar në
cloud. Seksioni në vijim diskuton këto mundësi dhe modelet ekonomike që lidhen me
to.
5.4.4. Modelet e biznesit për sistemet e informacionit të bazuar në cloud
IDEaaS mundëson dy modele të reja ekonomike:
1. PaygoC.
2. ODC.
Të dyja modelet do të ndihmojnë menaxherët e softuerëve cloud të optimizojnë
menaxhimin e projekteve, përdorimin e palëve të treta si dhe shpenzimet për kodim të
Figura 5-8 IDE online si pjesë e shërbimeve bazë të cloud
81
zhvilluar në komunitete të gjëra programuesish. Ndërsa ndërmarrjet e mëdha nuk do
të vuajnë më nga shpenzimet shtesë për konfigurimin paraprak të ambienteve të
zhvillimit për programuesit.
Modeli 1 (PaygoC) - Paguaj sipas kohës së përdorimit (Pay as you go) nuk është një
model i ri biznesi për cloud, por kur bëhet fjalë për IDEaaS, ky model mund të
adaptohet drejtpërsëdrejti për kodim duke shfrytëzuar orët e burimeve të vendosura në
përdorim. Kështu ai e bën të lehtë vlerësimin e kostove të zhvillimit pa ndonjë
infrastrukturë ose licencim që përbëjnë kosto paraprake. Për më tepër mund të mos
kërkohen sisteme operative portabël (dockers) pasi shumë prej strukturave të mjedisit
ofrohen si shërbime API ose librari. Natyrisht një konfigurim paraprak mund të jetë i
nevojshëm për çdo projekt, por çdo konfigurim i mëtejshëm në IDE online do të
ndahet midis të gjithë zhvilluesve të projektit. Kosto për klientin mund të mbështetet
në bazë të përdorimit, zakonisht i përcaktuar me tarifë ore pune, nga mjedisi i
zhvillimit dhe shfrytëzimi i shërbimeve të tjera ekzistuese nga cloud.
Modeli 2 (ODC) - Kodim sipas kërkesës (On Demand Coding) lejon që shërbimet e
jashtme të lehtësohen dhe optimizohen sa herë që kërkohet ekspertiza e kodimit.
Mundësitë kryesore, që mund të ofrohen nga modeli mund të integrojnë platformat e
punësimit me mjediset e zhvillimit cloud; duke bërë të mundur zhvillimin e
komuniteteve cloud të zhvillimit të kodit si dhe integrim të plotë me platformat
ekzistuese “freelancing”. Delegimi i punës i bazuar në cloud do të ofronte siguri më
të lartë, politika zhvillimi, vlerësim kostosh të projektit dhe shmangien e mbi
buxhetimit. Figura 5-9 përshkruan modelet e biznesit PaygoC dhe ODC. Ne mund të
vëzhgojmë qartë nga modeli i propozuar i biznesit potencialet e ndryshme që
derivojnë nga integrimi i disa aktorëve të rinj në zhvillimin e cloud në një vend të
përbashkët. Kështu krijohen mundësi, që ky model biznesi të jetë i suksesshëm në
treg.
Statistikat gjithashtu dëshmojnë se përdorimi i cloud dhe të ardhurat neto po rriten për
AWS (Amazon Web Services) duke u pasuar nga Azure, Google, IBM etj. Kështu
krijohen mundësi që ky model biznesi të jetë i suksesshëm në treg. Një përmbledhje e
plotë dhënë në figurën 5-10 paraqet të ardhurat nga Google dhe AWS cloud të marra
nga Statista (Statista 2018). Nga grafiku mund të vëzhgojmë qartë se AWS (Amazon
Web Services) është përpara në raport me GCP (Google Compute Platform) përsa i
përket të ardhurave. Megjithatë, të dyja vërtetojnë se kanë ruajtur një normë të
qëndrueshme rritjeje gjatë vitit të mëparshëm fiskal.
82
Figura 5-9 Modelet e biznesit PaygoC dhe ODC
Figura 5-11 paraqet vlerësime të kontributit IDEaaS ndaj tendencave aktuale në rritje
për zhvillimin e cloud. Vlerësimet janë bazuar në një komunitet prej rreth 2 milion
zhvilluesve të cloud (që përbëjnë 10% të zhvilluesve globalë), me një ngarkesë ditore
prej 4.2 orësh. Të ardhurat përfundimtare për tre modele pagesash të ndryshme prej
0.5, 1 dhe 1.5 $ / orë llogariten deri në 0.1, 0.2 dhe 0.3 miliardë $ të rritjes vjetore të
të ardhurave. Kjo provon potencialet e IDEaaS për të konsoliduar atë si një model
biznesi të qëndrueshëm për përdoruesit e cloud.
Nga sa më sipër është dëshmuar si qëndrueshmëria e modelit, ashtu edhe mundësia
për t’u bërë një aktor kyç në shërbimet e CC. Në vazhdim do diskutojmë për
mundësitë e mëtejshme që krijohen nga modelet e propozuara.
83
Figura 5-10 Të ardhurat nga Google dhe AWS të marra nga Statista20
Figura 5-11 Të ardhurat nga Google dhe AWS të marra nga Statista
20 Bazuar në figurën 1 në punimin e (Chen, 2008)
84
5.5. Përmbledhje
Ky kapitull propozon një shërbim të ri cloud, i cili do të ketë ndikim të rëndësishëm
në zhvillimin e kodit në cloud. Sot shumica e SDK-ve po bëhen të vështira për t’u
menaxhuar për gjuhë programimi të ndryshme së bashku me nevojat në rritje të
programuesve për mjedise fleksibël bashkëpunimi. Kështu që modelet e reja të
biznesit - të adaptuara dhe shërbimet e reja të zhvillimit - të shtuara në infrastrukturën
cloud, do të ofrojnë rritjen e interesit në shfrytëzimin e aplikacioneve cloud në nivel
biznesesh.
Modeli i ri i shërbimit IDEaaS sugjeron mundësinë e ofrimit të mjedisit të zhvillimit,
ndërkohë që shërbimet e tjera janë aktualisht në cloud, duke ofruar mundësinë e
krijimit të modeleve të reja të biznesit: kur kërkohet kodimi nga palë të treta sipas
nevojës; si dhe duke lehtësuar punën e menaxherëve të projektit për konvertimin e
orëve aktuale të kodimit në koston e zhvillimit të projektit. E gjithë kjo realizohet pa
nevojën e përdorimit të mjeteve të ofruara nga palë të treta.
Ofruesit kryesor të cloud po bëhen të vetëdijshëm për nevojat e zhvilluesve të kodit
dhe tashmë mbështesin mjetet e zhvillimit online, megjithëse shumica e tyre
mbështeten ende në SDK-të lokale. Përfitimet kryesore të IDEaaS, si çdo shërbim
tjetër, mund të ofrojnë funksione të reja të bazuara në kërkesat e përdoruesve fundorë
të cloud, si dhe të gjenerojnë të ardhura solide për secilin ofrues duke adaptuar
modelet e biznesit që mbështeten në të. Pra, zgjidhja aktuale e propozuar në këtë
punim, GAELauncher ofron të gjitha veçoritë e ofruara nga aplikacioni Desktop SDK,
por duke integruar shërbime të reja të cilat tashmë janë ofruar online për një kohë të
gjatë (depozitarët Git, mjetet e menaxhimi të projekteve (“Project Management” -
PM), etj.).
Rishikimi offline dhe sinkronizimi online i kodit, si dhe integrimi me mjete të tjera
ekzistuese, duhet të bëhen pjesë e funksioneve kryesore të shërbimit, në mënyrë që
zhvilluesit të vazhdojnë punën e tyre edhe kur humbet lidhja me rrjetin. Tendencat e
ardhshme do të provojnë efektivitetin dhe do të lejojnë ofruesit e rinj që të adaptojnë
platformën dhe modelet e propozuara, ku inteligjenca artificiale do të lehtësojë
procesin e zhvillimit të aplikimeve në cloud.
Puna shkencore e realizuar në këtë kapitull ka mbështetur plotësisht hipotezat 1 dhe 3
si dhe ka ndihmuar në dhënien e përgjigjes të pyetjes shkencore 1 dhe 3. Rezultatet
janë prezantuar në konferencën (Cico, Dika, Cico and Sevrani 2018) dhe janë botuar
në revistën (Cico, Dika, and Cico 2018).
85
KAPITULLI 6: PËRFUNDIME DHE OBJEKTIVA PËR TË ARDHMEN
Në këtë kapitull kemi përmbledhur sfidat e punëve kërkimore shkencore të
prezantuara për sistemet e informacionit të biznesit në cloud. Fokus është vendosur
kryesisht në konkluzionet e arritura lidhur me rritjen e besueshmërisë të sistemeve
cloud nëpërmjet metodave të kodimit. Si përfundim kemi parashtruar dhe punët e
mundshme të cilat mund të kryhen në të ardhmen.
6.1. Përfundime
Besueshmëria në cloud dhe besimi në përdorimin e zgjidhjeve cloud për sistemet e
informacionit të bizneseve përbëjnë akoma një fushë studimi. Megjithatë, studimet e
ndryshme të paraqitura vërtetojnë mundësinë e përdorimit të sistemeve cloud për të
mbështetur plotësisht dhe në mënyrë efikase zhvillimin e sistemeve të informacionit
direkt në infrastrukturën e tyre. Kështu, duke iu përgjigjur pyetjes 0 dhe duke
konfirmuar hipotezën 0 i jemi referuar mundësisë të integrimit të teknikave të
tolerancës ndaj gabimeve në një strukturë cloud.
Për më tepër, testimi i SRE është zbatuar me sukses në aplikimet tona cloud.
Rezultatet e implementimeve të ndryshme kanë dëshmuar gjithashtu efikasitetin e
teknikave të tolerancës ndaj gabimeve, pjesë e procesit SRE, i përdorur për aplikimet
në cloud. Kjo rrit besueshmërinë midis bizneseve për të zhvilluar sistemet e tyre të
informacionit duke u mbështetur në këto teknika. Pra pyetja shkencore 2 së bashku
me hipotezën 2 kanë marrë përgjigjen e duhur dhe janë vërtetuar nëpërmjet
eksperimentimeve të realizuara duke bërë të mundur edhe propozimin e një shërbimi
të ri RaaS nga ana jonë. Punimi gjithashtu propozon një shërbim të ri (IDEaaS), i
lidhur ngushtë me zhvillimin e aplikacioneve direkt në cloud. Ky shërbim do të ketë
ndikim të drejtpërdrejt në zhvillimin e aplikacioneve cloud dhe mjeteve të zhvillimit
të kodit, që do të përdoren në të ardhmen e afërt. Shumica e SDK-ve të sotëm për
gjuhë të ndryshme programimi, janë të vështira për t’u menaxhuar në krahasim me
nevojat në rritje të programuesve për mjedise akoma më fleksibël dhe bashkëpunues.
Duke disponuar modele biznesi dhe shërbime të reja për zhvillimin e kodit në cloud,
infrastrukturat do të ofrojnë një mundësi në rritje për adaptimin e aplikimeve direkt në
cloud nga ana e korporatave. Propozimi i një modeli te ri shërbimi IDEaaS sugjeron
që mjedisi i zhvillimit të kodit të ofrohet drejtpërdrejt në cloud me përftimet e
mëposhtme:
• Mundësi të reja të modelit të biznesit ku kodimi mund të kërkohet dhe
kontraktohet në orë pune.
• Lehtësim për menaxherët e projektit në përllogaritjen e orëve reale të kodimit
dhe kostove të zhvillimit.
• Nuk ka nevojë për mjete të ofruara nga palë të treta.
IDEaaS, si çdo shërbim tjetër mund të ofrojë funksione të reja të bazuara në kërkesat e
përdoruesve fundorë të cloud-it si dhe gjenerimin e të ardhurave solide për secilin
ofrues, duke adoptuar modelet e biznesit që mbështeten në të. Hipotezat 1 dhe 3 janë
vërtetuar mbështetur nga fakti se shumica e ofruesve të cloud-it mund të shikojnë të
dobishme të pasurit në dispozicion të mjeteve të zhvillimit të kodit për përdoruesit e
tyre. Kjo do të sjellë jo vetëm rritje të besueshmërisë, por do të lejojë teknika të reja të
zhvillimi të kodit të mbështetura në tolerancën e gabimeve dhe të ofruara si pjesë e
86
shërbimeve bazë cloud. Verifikimi i Hipotezave është gjithashtu i mbështetur nga një
pyetësor i plotësuar nga kompanitë në disa vende të Ballkanit, të cilat përdorin
zgjidhje cloud për të përmbushur nevojat e tyre në implementimin e sistemeve të
informacionit.
IDEaaS, si çdo shërbim tjetër mund të ofrojë funksione të reja të bazuara në kërkesat e
përdoruesve fundorë të cloud-it si dhe gjenerimin e të ardhurave solide për secilin
ofrues, duke adoptuar modelet e biznesit që mbështeten në të.
6.2. Objektiva për të ardhmen
Studimi ynë disa vjeçar është shoqëruar shpesh herë me sfida dhe pyetje të shumta.
Është e kuptueshme që pyetjeve dhe sfidave qenësore ju janë dhënë përgjigjet dhe
zgjidhjet e duhura, por si çdo punim ka dhe pyetje dhe elementë të cilave ju duhen
dhënë përgjigje në vazhdimësi. Më poshtë po përmendim disa prej tyre si sugjerime
për t’u zgjidhur në të ardhmen, duke bërë të mundur vazhdimësinë e punës tonë
shkencore ashtu dhe përfshirjen e studiueseve të rinj në këto fusha studimi
bashkëkohore të lidhura ngushtë me bizneset:
1. Elementë, që mbështeten në propozimet tona (RaaS dhe IDEaaS), mund të
ndikojnë në të ardhmen në zhvillimin e sistemeve të informacionit direkt në
infrastrukturën cloud, duke rritur kështu dhe më tej besueshmërinë e
korporatave?
2. A do të përshtaten strukturat dhe shërbimet e propozuara nga ofruesit kryesorë
të cloud-it në një të ardhme të afërt? Cili do të jetë impakti i tyre ekonomik për
këto ofrues shërbimesh cloud?
3. A do të bëhen teknikat e tolerancës ndaj gabimeve pjesë e tendencave dhe
standardeve të kodimit për aplikacionet e biznesit apo sistemeve të
informacionit në cloud? Çfarë impakti ekonomik do të kenë këto teknika për
bizneset?
4. Si do të ndihmojnë strukturat dhe shërbimet e propozuara në zhvillimin e
sistemeve të informacionit në cloud nëpërmjet përdorimin të inteligjencës
artificiale (rrjetave neurale) për nevojat e kodimit?
Ne mendojmë se puna hulumtuese e bërë mund të provojë më tej efektivitetin dhe të
lejojë ofruesit e cloud-it të zbatojnë platformën dhe modelet e propozuara, ku
inteligjenca artificiale mund të lehtësojë zbatimin e teknikave të tolerancës ndaj
gabimeve, duke analizuar modelin e kodimit për softuerin e implementuar
drejtpërdrejt në cloud. Këto sugjerime vlejnë të eksplorohen nga studiues të tjerë në të
ardhmen.
87
REFERENCAT
Aho, Timo et al. 2011. “Designing IDE as a Service.” Communications of Cloud
Software 1(1).
Alexandrov, Tsanko, Aleksandar Dimov, and ACM. 2013. “Software Availability in
the Cloud.” Proceedings of the 14th International Conference on Computer
Systems and Technologies: 193–200.
“Amazon.” 2014. http://www.amazon.com/.
“Amazon EC2.” 2014. http://aws.amazon.com/ec2/.
An, Kyoungho et al. 2014. “A Cloud Middleware for Assuring Performance and High
Availability of Soft Real-Time Applications.” Journal of Systems Architecture
60(9): 757–69.
Avizienis, Algirdas, and John P J Kelly. 1984. “Fault Tolerance by Design Diversity:
Concepts and Experiments.” Computer (8): 67–80.
Avram, Maricela-Georgiana. 2014. “Advantages and Challenges of Adopting Cloud
Computing from an Enterprise Perspective.” Procedia Technology 12: 529–34.
Bertolino, Antonia, and IEEE Computer Society. 2007. “Software Testing Research:
Achievements, Challenges, Dreams.” 2007 Future of Software Engineering: 85–
103.
Chen, Liming, and Algirdas Avizienis. 1977. “On the Implementation of N-Version
Programming for Software Fault Tolerance during Program Execution.”
International Computer Software and Applications Conference (COMPSAC).
Chen, Tao, Rami Bahsoon, and Abdel-Rahman H Tawil. 2014. “Scalable Service-
Oriented Replication with Flexible Consistency Guarantee in the Cloud.”
Information Sciences 264: 349–70.
Cico, Orges. 2018. “Reliable IoT Systems for Improving Quality Of Life Through
The Exploitation of Cloud, Mobile and BLE Based Technologies Case Study:
SunProtect UV.” MENOnet JOURNAL: WORKS in PROGRESS in EMBEDDED
COMPUTING (WiPiEC) 4(1).
Cico, Orges, Zamir Dika, and Betim Cico. 2018a. “Integrated Development
Environment as a Service (IDEaaS) - Models and Architecture Part of the
Google Cloud Core Services.” International Journal of Computer Applications
182(6): 44–50. http://www.ijcaonline.org/archives/volume182/number6/29770-
2018917534.
Cico, Orges, Zamir Dika, and Betim amd K. Sevrani Cico. 2018b. “Migrating Google
Cloud SDK to the Cloud. Case Study: GAE Launcher.” 11th IADIS International
Conference on Information Systems (IS 2018): 211–16.
Cico, Orges, Zamir Dika, and DSC. 2014. “Models and Techniques to Evaluate
System and Softwarereliability Based on Software Reliability Engineering
Methodology. Case Study: AttitudeControl System.” In Proceedings of the 10th
Annual South-East European Doctoral Student Conference.
88
Cico, Orges, Zamir Dika, and IEEE. 2014. “Performance and Load Testing of Cloud
vs. Classic Server Platforms (Case Study: Social Network Application).” 2014
3rd Mediterranean Conference on Embedded Computing (MECO): 301–6.
“Cloud9.” 2018. https://aws.amazon.com/cloud9/.
“CloudForge:” 2018. http://cloudforge.com.
“Codeanywhere:” 2018. https://codeanywhere.net/.
“CodePlex.” 2018. https://www.codeplex.com/.
“Compilr.” 2018. http://compilr.com/.
“Condevy.” 2018. https://codenvy.com/.
van Deursen, Arie et al. 2010. “Adinda: A Knowledgeable, Browser-Based IDE.” In
Proceedings of the 32Nd ACM/IEEE International Conference on Software
Engineering - Volume 2, ICSE ’10, New York, NY, USA: ACM, 203–6.
http://doi.acm.org/10.1145/1810295.1810330.
“Django Support.” 2018. https://developers.google.com/api- client-
library/python/guide/django.
Endo, Patricia T et al. 2016. “High Availability in Clouds: Systematic Review and
Research Challenges.” Journal of Cloud Computing 5(1): 16.
Fang, Chen-Liang, Deron Liang, Fengyi Lin, and Chien-Cheng Lin. 2007. “Fault
Tolerant Web Services.” Journal of Systems Architecture 53(1): 21–38.
Frost, Randall. 2007. “Jazz and the Eclipse Way of Collaboration.” IEEE software
24(6): 114–17.
“GitLab:” 2018. https://about.gitlab.com.
“Google Cloud Python API.” 2018. https://cloud.google.com/resource-
manager/reference/rest/v1/projects/create.
“Google Cloud Tools:” 2018. https://cloud.google.com/docs/overview/developer-and-
admin-tools.
Grady, Robert B. 1992. “Practical Software Metrics for Project Management and
Process Improvement.”
Hausladen, Jürgen, Birgit Pohn, Martin Horauer, and IEEE. 2014. “A Cloud-Based
Integrated Development Environment for Embedded Systems.” 2014
IEEE/ASME 10th International Conference on Mechatronic and Embedded
Systems and Applications (MESA): 1–5.
Imran, Asif et al. 2014. “Cloud-Niagara: A High Availability and Low Overhead
Fault Tolerance Middleware for the Cloud.” 16th Int’l Conf. Computer and
Information Technology: 271–76.
“Javawide.” 2018. http://www.javawide.org.
JoSEP, Anthony D et al. 2010. “A View of Cloud Computing.” Communications of
the ACM 53(4).
89
“JsFiddle.” 2018. https://jsfiddle.net.
Kamra, Madhvi, Ratnamala Manna, and IEEE. 2012. “Performance of Cloud-Based
Scalability and Load with an Automation Testing Tool in Virtual World.” 2012
IEEE Eighth World Congress on Services: 57–64.
Kavis, Michael J. 2014. Architecting the Cloud: Design Decisions for Cloud
Computing Service Models (SaaS, PaaS, and IaaS). John Wiley & Sons.
Kim, K H. 1995. “The Distributed Recovery Block Scheme.” Software Fault
Tolerance 3: 189–210.
Kim, K H, and Howard O Welch. 1989. “Distributed Execution of Recovery Blocks:
An Approach for Uniform Treatment of Hardware and Software Faults in Real-
Time Applications.” IEEE transactions on Computers 38(5): 626–36.
Kim, Won. 2009. “Cloud Computing: Today and Tomorrow.” Journal of object
technology 8(1): 65–72.
Koo, Richard, and Sam Toueg. 1987. “Checkpointing and Rollback-Recovery for
Distributed Systems.” Ieee transactions on software engineering (1): 23–31.
Lyu, Michael R, and IEEE. 2007. “Software Reliability Engineering: A Roadmap.”
Future of Software Engineering (FOSE’07): 153–70.
Lyu, Michael R, Allen Nikora, and IEEE. 1992. “CASRE: A Computer-Aided
Software Reliability Estimation Tool.” [1992] Proceedings of the Fifth
International Workshop on Computer-Aided Software Engineering: 264–75.
Lyu, Michael R, and others. 1996. “Handbook of Software Reliability Engineering.”
222.
Merideth, Michael G et al. 2005. “Thema: Byzantine-Fault-Tolerant Middleware for
Web-Service Applications.” 24th IEEE Symposium on Reliable Distributed
Systems (SRDS’05): 131–40.
Mohagheghi, Parastoo. 2011. “REMICS-REuse and Migration of Legacy
Applications to Interoperable Cloud Services.”
Morris, M A. 1981. “An Approach to the Design of Fault Tolerant Software.” Sc. the-
sis, Cranfield Institute of Technology.
Mosetti, GPCDB, Carlo Poloni, and B Diviacco. 1994. “Optimization of Wind
Turbine Positioning in Large Windfarms by Means of a Genetic Algorithm.”
Journal of Wind Engineering and Industrial Aerodynamics 51(1): 105–16.
Myers, Glenford J. 1976. “Softwear Reliability.”
“Nordicsemi.” 2018. https://www.nordicsemi.com/.
“OAuth2 Python API.” 2018. https://developers.google.com/api- client-
library/python/auth/web-app.
Pham, Hoang. 2001. “Software Reliability.” Wiley encyclopedia of electrical and
electronics engineering.
Pullum, Laura L. 2001. “Software Fault Tolerance Techniques and Implementation.”
90
Santos, Giuliana Teixeira, Lau Cheuk Lung, Carlos Montez, and IEEE. 2005. “Ftweb:
A Fault Tolerant Infrastructure for Web Services.” Ninth IEEE International
EDOC Enterprise Computing Conference (EDOC’05): 95–105.
Sheu, Guang-Way et al. 1997. “A Fault-Tolerant Object Service on Corba.”
Proceedings of 17th International Conference on Distributed Computing
Systems: 393–400.
Sillanpää, Hannu et al. 2014. “Integration of Inkjet and RF SoC Technologies to
Fabricate Wireless Physiological Monitoring System.” Proceedings of the 5th
Electronics System-integration Technology Conference (ESTC): 1–5.
Statista. 2018. “Statista.” https://www.statista.com/statistics/250520/forecast-of-
%0Aamazon-web-services- revenue/.
Thangaraj, Muthuraman, Pichaiah Punitha Ponmalar, Subramanian Anuradha, and
IEEE. 2015. “Internet of Things (Iot) Enabled Smart Autonomous Hospital
Management System-a Real World Health Care Use Case with the Technology
Drivers.” 2015 IEEE International Conference on Computational Intelligence
and Computing Research (ICCIC): 1–8.
Vaquero, Luis M, Luis Rodero-Merino, Juan Caceres, and Maik Lindner. 2008. “A
Break in the Clouds: Towards a Cloud Definition.” ACM SIGCOMM Computer
Communication Review 39(1): 50–55.
Voorsluys, William, James Broberg, and Rajkumar Buyya. 2011. “Cloud Computing:
Principles and Paradigms.” Ch. Introduction to Cloud Computing: 1–44.
Want, Roy, Bill N Schilit, and Scott Jenson. 2015. “Enabling the Internet of Things.”
Computer (1): 28–35.
“Windows Server:” 2014. http://technet.microsoft.com/en-us/library.
Yan, Minzhi et al. 2012. “Ws-Taas: A Testing as a Service Platform for Web Service
Load Testing.” 2012 IEEE 18th International Conference on Parallel and
Distributed Systems: 456–63.
Yang, Geng et al. 2014. “A Health-IoT Platform Based on the Integration of
Intelligent Packaging, Unobtrusive Bio-Sensor, and Intelligent Medicine Box.”
IEEE transactions on industrial informatics 10(4): 2180–91.
Yau, Stephen S, Arun Balaji Buduru, and IEEE. 2014. “Intelligent Planning for
Developing Mobile IoT Applications Using Cloud Systems.” 2014 IEEE
International Conference on Mobile Services: 55–62.
Yu, Lian et al. 2010. “Testing as a Service over Cloud.” 2010 Fifth IEEE
International Symposium on Service Oriented System Engineering: 181–88.
Zeller, Andreas, and IEEE Computer Society. 2007. “The Future of Programming
Environments: Integration, Synergy, and Assistance.” 2007 Future of Software
Engineering: 316–25.Zheng, Zibin et al. 2010. “FTCloud: A Component
Ranking Framework for Fault-Tolerant Cloud Applications.” 2010 IEEE 21st
International Symposium on Software Reliability Engineering: 398–407.
91
APENDIKS / SHTOJCA
Shtojca A
A.1 Të dhënat e mbledhura
Qëllimi i kësaj shtojce është të përfaqësojë të dhënat analitike të mbledhura nëpërmjet
një pyetësori të realizuar në disa nga kompanitë më të mëdha në Ballkan në fushën e
cloud.
Sistemi i bazuar në cloud dhe serverat e dedikuar kanë qenë në një rivalitet të
vazhdueshëm në lidhje me adoptimin e tyre për kompanitë që mbështeten në sistemet
e informacionit për të ofruar shërbimet. Këto kompani vazhdimisht kanë kërkesa në
rritje për ruajtjen e të dhënave, fuqi kompjuterike, kohë më të ulët të instalimit të
sistemeve dhe siguri më të madhe. Shumica e serverëve cloud kanë provuar të jenë
një zgjidhje e përshtatshme edhe pse shtrirja e tyre në nivel korporatash nuk është
ende e qartë. Megjithatë, po bëhet gjithnjë e më evidente se sistemet e informacionit
të bazuar në cloud mund të zvogëlojnë në mënyrë drastike buxhetin e IT. Shumica e
krahasimeve janë bazuar në të dhënat e mbledhura gjatë plotësimit të pyetësorëve nga
drejtuesit e kompanive nga shtetet përkatëse të Shqipërisë, Maqedonisë, Kosovës dhe
Malit të Zi. Pyetësori synon të kuptojë gjendjen aktuale të depërtimit të sistemeve
cloud në rajonin e Ballkanit.
Shifrat në vijim tregojnë rezultatet e marra nga pyetësori i përgatitur. Përgjigjet kanë
qenë një pjesë e rëndësishme e procesit në përcaktimin e pyetjeve të ndryshme
kërkimore dhe konstatimeve kyçe gjatë punimit tonë. Figura A-1 paraqet të dhëna të
përgjithshme lidhur me kompanitë e marra në shqyrtim.
Figura A-1 Të dhëna të përgjithshme
92
Figura A-2 paraqet të dhëna të përgjithshme lidhur me përdorimin e cloud-it nga
kompanitë e marra në shqyrtim.
Figura A-2 Te dhëna të përgjithshme të përdorimit të cloud
Figura A-3 paraqet të dhëna për specialistët e IT si pjesë e kompanive të marra në
pyetje.
Figura A-3 Rezultate nga specialistët e IT
Figura A-4 paraqet të dhëna për testimin e aplikacioneve në Cloud nga kompanitë e
IT
Figura A-4 Rezultate nga specialistët e IT
93
A.2 Pyetësori i përdorur për mbledhjen e të dhënave
Shtojca përmban pyetësorin e përdorur si pjesë e hulumtimit se si bizneset kanë
miratuar zgjidhje cloud për sistemet e tyre të informacionit. Analizat në lidhje me
rezultatet e pyetësorëve janë paraqitur më sipër.
Të përgjithshme:
1. Vendndodhja
Shqipëri
Kosovë
Mal i zi
Maqedonia e Veriut
2. Viti themelimit
2000-2005
2005-2010
2010-2015
Tjetër
3. Aktiviteti i ushtruar
IT
Shërbime
4. Numri i të punësuarve - Madhësia që nga viti 2017 dhe numri i punonjësve të
cilët punojnë në IT
4-10
11-20
21-50
94
5. Mosha mesatare e punonjësve
18-22
23-27
28-32
33-40
40-60
6. Raporti Meshkuj/Femra
50%
<50%
>50%
Pyetje Shkencore të përgjithshme
1. Çfarë sistemesh përdorni për implementimin e softuerëve të biznesit?
a. Desktop
b. Web
c. Mobile
d. Cloud
2. A është filluar të punohet në cloud dhe kur ?
a. Po
b. Jo
3. Nëse po, kur?
4. Nëse nuk keni filluar kush janë arsyet?
Mungesa e njohurive
Pa besueshmëria për të zhvilluar në cloud
Vlerësimi i kostove
Nëse keni filluar?
95
5. Sa vite keni që punoni në cloud?
0-2
2-5
5-10
6. A është rritur aktiviteti dhe veprimtaria nëpërmjet përdorimit të cloud?
Po
Jo
7. Rezultojnë kosto të reduktuara në raport me kostot nga sistemet e mëparshme.
Po
Jo
8. Nëse po, mund te jepni një vlerë të përafërt?
9. A keni hasur probleme me sigurinë dhe besueshmërinë? Nëse po cilat janë
problemet. Ju lutem paraqitni?
Siguri më e ulët për klientët
Problematika në mirëmbajtje
Vonesa në riparime
Mungesë e shërbimit
10. Sa ka qenë investimi i shtuar në network/bandwidth?
> 1000 $
>10.000 $
>100.000
11. Sa ka qenë latenca e përgjigjeve në cloud dhe a ka përbërë ndonjëherë
problem si dhe çfarë problemesh keni hasur lidhur me vonesat në përgjigje?
<1 min.
>1 min.
Performancë e ulët
Vështirësi në përdorimin e sistemit
12. Keni përdorur cloud privat ?
Po
Jo
96
13. Kanë humbur ndonjëherë informacionet?
Po
Jo
Pyetje për specialistët e IT
1. A kanë patur vështirësi punonjësit në zhvillimin e softuerëve?
Po
Jo
2. Ju është dashur të trajnoheni?
Po
Jo
3. Nëse po çfarë trajnimi?
Cloud
Programim
Përdorimin e mjeteve
Të gjitha
4. Keni ndonjë mënyre se si mund të rritet besueshmëria e sistemeve në cloud?
Po
Jo
5. A jeni të interesuar që besueshmëria dhe siguria të jepet në bashkëpunim me
IT?
Po
Jo
Pyetje për aplikacionet
1. Në çfarë gjuhësh programimi keni zhvilluar aplikacionet?
.Net
Python
Go
Php
97
2. Softuerët ndërtohen në cloud në mënyrë të drejtpërdrejte apo në sistemet tuaja
offline dhe më pas zhvendosen në cloud?
SDK offline
Shërbime online
3. Cili mendoni që është cloud më i përshtatshëm nga ato të përdorura (Public /
Privat / Hibrid) / Google / Azure / Amazon?
Azure
Amazon
4. Një IDE në cloud mendoni që do të përmirësonte në mënyre të drejtpërdrejtë
kostot e menaxhimit dhe të zhvillimit të aplikacioneve?
Po
Jo
Pyetje për testimin e aplikacioneve
1. Keni testuar ndonjëherë aplikacionet në cloud?
Po
Jo
2. Nëse po, cilat metoda keni përdorur për testimin e tyre?
Black Box
White Box
Testimi i besueshmërisë
3. Do preferonit që testimi apo kodimi të bëhej ne mënyrë të automatizuar në
cloud bazuar në Inteligjencën Artificiale (AIO)?
Po
Jo
4. Do preferonit që cloud të ofronte mundësinë e përdorimit të teknikave të
tolerancës ndaj gabimeve për të rritur besueshmërinë e zhvillimit të
aplikacioneve në cloud?
Po
Jo