ZHVILLIMI DHE TESTIMI I APLIKACIONEVE TË BIZNESIT NË...

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


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.


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


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


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



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


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


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


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.


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)


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ë:


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


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ë


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.


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


Ruby, Go, Dockers

Microsoft Azure Azure Cloud

Services


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?

Google

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

ZHVILLIMI DHE TESTIMI I APLIKACIONEVE TË BIZNESIT NË...

Documents

Transcript of ZHVILLIMI DHE TESTIMI I APLIKACIONEVE TË BIZNESIT NË...