Penilaian Kualitas Website Polda Jabar Dari Sisi Quality In Use Dan Sisi Internal Menggunakan Standar ISO

BIODATA PENULIS (RIWAYAT HIDUP)

DATA PRIBADI

Nama : Kevin Ervana

Jenis Kelamin : Laki – Laki

Golongan Darah : B

Tempat & Tanggal Lahir : Kebumen, 07 Agustus 1992

Alamat : Komplek Griya Jati Putra No 83 Ciseupan Ujung Berung Bandung

No. Telepon : 08562177571

Email : kevinervana@gmail.com

PENDIDIKAN FORMAL

1998 – 2004 : SD Negeri Merdeka 5/3 Bandung 2004 – 2007 : SMP Negeri 50 Bandung

2007 – 2010 : SMA Negeri 16 Bandung

2010 – 2016 : Universitas Komputer Indonesia (UNIKOM) Program Studi Teknik Informatika

PENILAIAN KUALITAS WEBSITE POLDA JABAR DARI SISI

QUALITY IN USE DAN SISI INTERNAL MENGGUNAKAN

STANDAR ISO

SKRIPSI

Diajukan untuk Menempuh Ujian Akhir Sarjana

KEVIN ERVANA

10110040

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS TEKNIK DAN ILMU KOMPUTER

UNIVERSITAS KOMPUTER INDONESIA

2016

iii

KATA PENGANTAR

Puji syukur penulis panjatkan kehadirat Allah SWT yang Maha pengasih dan juga Maha penyayang, karena atas rahmat dan hidayah-Nya penulis dapat menyelesaikan Skripsi yang berjudul “PENILAIAN KUALITAS WEBSITE POLDA JABAR DARI SISI QUALITY IN USE DAN DARI SISI INTERNAL MENGGUNAKAN STANDAR ISO”.

Skripsi ini dibuat sebagai salah satu syarat kelulusan program Strata 1 Fakultas Teknik dan Ilmu Komputer, Program Studi Teknik Informatika di Universitas Komputer Indonesia. Dengan penuh rasa syukur, ucapan terima kasih yang mendalam serta penghargaan yang setinggi-tingginya penulis sampaikan kepada :

1. Allah SWT yang senantiasa memberikan kekuatan, kesehatan, dan kesempatan kepada penulis dalam proses menyelesaikan skripsi ini serta atas semua rahmat dan hidayah-Nya yang dapat menjadikan semangat tiada henti.

2. Kedua orang tua yang sangat penulis cintai dan hormati, yang selalu memberikan semangat, kekuatan moril, dan selalu mendo’akan penulis. 3. Kedua Kakek (Alm) tercinta dan kedua nenek (Alm) yang penulis

banggakan.

4. Bapak Alif Finandhita, S.Kom., M.T. selaku pembimbing yang telah sabar dalam membimbing dalam pembuatan tugas akhir ini serta telah memberi saya saran dalam pengerjaan tugas akhir ini.

5. Bapak Adam Mukharil Bachtiar, S.Kom., M.T. selaku reviewer atas saran dan arahan yang sangat membantu dalam penyempurnaan tugas akhir ini. 6. Bapak Eko Budi Setiawan, S.Kom, M.T. Selaku Wali dosen IF-17K. 7. Seluruh staf dosen Teknik Informatika yang telah memberikan ilmu yang

sangat berarti untuk penulis.

8. Kepada Kukuh Setiawan, Reza Vahlefi, Doni Haryanto, Arie Prima Anggara, Suharyanto, Taufik Setiyadi dan masih banyak khususnya teman- teman IF-1 2010 dan IF-17K terimakasih atas kebersamaan susah

iv

senang yang telah dilalui sehingga sampai pada penulis untuk dapat menyelesaikan skripsi ini.

9. Sri Anggraeni Waraswati sebagai pasangan saya terima kasih telah mendukung secara motivasi dalam pembuatan tugas akhir ini.

Penulis sangat menyadari bahwa skripsi ini masih banyak kekurangan dan masih jauh dari kata sempurna. Oleh karena itu, kritik dan saran yang sifatnya membangun akan penulis terima dengan senang hati. Akhir kata penulis berharap skripsi ini dapat bermanfaat bagi yang membutuhkan.

Bandung, Februari 2016

v

DAFTAR ISI

ABSTRAK ... i

ABSTRACT ... ii

KATA PENGANTAR ... iii

DAFTAR ISI ... v

DAFTAR GAMBAR ... x

DAFTAR TABEL ... xii

DAFTAR SIMBOL ... xiv

DAFTAR LAMPIRAN ... xvi

BAB 1 PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Rumusan Masalah ... 2

1.3 Maksud dan Tujuan ... 2

1.4 Batasan Masalah ... 2

1.5 Metodologi Penelitian ... 3

1.5.1 Metode Pengumpulan Data ... 3

1.5.2 Tahap Analisis Perangkat Lunak... 4

1.6 Sistematika Penulisan ... 6

BAB 2 LANDASAN TEORI ... 7

2.1 Definisi Perangkat Lunak ... 7

vi

2.3 Definisi Website ... 8

2.4 Pemrograman Berorientasi Objek ... 9

2.4.1 Analisis dan Desai Berorientasi Objek... 10

2.4.2 Orientasi Objek ... 10

2.4.3 Kelas ... 11

2.4.4 Pembungkusan ... 11

2.4.5 Pewarisan ... 11

2.5 UML ... 12

2.5.1 Diagram Class ... 14

2.5.2 Diagram Use Case ... 14

2.5.3 Diagram Sequence ... 15

2.6 Orientasi Objek Metriks ... 17

2.7 Model Metriks Perangkat Lunak ... 19

2.7.1 Standar ISO 9126 ... 20

2.7.2 Model Quality in Use ... 21

2.8 Metode Pengukuran Perangkat Lunak ... 25

2.9 Pengukuran ... 26

2.10 Metode Pembobotan ... 26

2.11 Metode Pengolahan Kuesioner... 27

vii

BAB 3 ANALISIS DAN PEMBENTUKAN ... 29

3.1 Penentuan Domain Masalah ... 29

3.2 Penentuan Metriks Kualitas ... 29

3.3 Penentuan Perhitungan OO Metriks ... 30

3.3.1 Weight Method per Class ... 30

3.3.2 Depth of Inheritance Tree ... 33

3.3.3 Number of Children ... 34

3.3.4 Coupling Between Object ... 35

3.3.5 Sequence Diagram ... 38

3.3.6 Class Diagram ... 50

3.3.7 Respon for a Class... 52

3.3.8 Lack Of Cohesion in Method ... 55

3.3.7 Penilaian Akhir Faktor Internal ... 59

3.4 Pembentukan Kuisioner Quality in Use ... 60

3.4.1 Pengolahan Kuisioner Quality in Use ... 62

3.4.2 Penilaian Faktor Effectiveness ... 63

3.4.3 Penilaian Faktor Productivity ... 64

3.4.4 Penilaian Faktor Safety ... 65

3.4.5 Penilaian Faktor Satifaction ... 65

viii

BAB 4 PERHITUNGAN METRIKS ... 69

4.1 Perhitungan OO Metriks Pada Source Code ... 69

4.1.1 Perhitungan Weight Method per Class ... 69

4.1.2 Perhitungan Depth of Inheritance Tree ... 80

4.1.3 Perhitungan Number of Children ... 80

4.1.4 Coupling Between Object ... 81

4.1.5 Respon for a Class... 93

4.1.6 Lack Of Cohesion in Method... 106

4.2 Penilaian Akhir Faktor Internal ... 120

4.3 Rekomendasi Perbaikan Nilai Kualitas ... 127

4.3.1 Rekomendasi Perbaikan Source Code CBO ... 129

4.3.2 Rekomendasi Perbaikan Nilai KualitasCBO... 137

4.3.2 Rekomendasi Perbaikan Proses CBO ... 138

4.4 Kesimpulan Faktor Internal ... 142

4.5 Pengajuan Kuisioner ... 143

4.5.1 Pengolahan Nilai Kuisioner ... 144

4.5.2 Penilaian Faktor Effectiveness ... 146

4.5.3 Penilaian Faktor Productivity ... 146

4.5.4 Penilaian Faktor Safety ... 147

4.5.5 Penilaian Faktor Satisfaction ... 148

ix

4.6 Kesimpulan Faktor Quality in Use ... 150

BAB 5 SARAN DAN KESIMPULAN ... 151

5.1 Kesimpulan... 151

5.2 Saran ... 151

153

DAFTAR PUSTAKA

[1] Wahyu Rifa’i Dwi Septian, “Analisis Perbandingan Framework PHP

berdasarkan MOOSE CK dan Properti Kualitas Menggunakan AHP”, 2010. [2] Zeist Van and Hendrik, “Software Quality Journal, “ Specifying Software

Quality with extended ISO Model, 1996.

[3] S. Rosa A. Dan M. Shalahuddin. “Rekayasa Perangkat Lunak Terstruktur dan Berorientasi Objek”.Bandung Informatika, 2013.

[4] P. P. Widodo dan Heriawati. “Menggunakan Unified Modeling Language (UML)”. Bandung Informatika, 2011.

[5] Rafa E.Al-Qutaish, Ali Idri and Asma Sellami Leila Cheikhi “Chidamber and Kemerer Object-Oriented Measure, “ Analysis of their Design from the Metrology Perspective.

[6] B., & Dutoit, A. H. Bruegge, “Object-Oriented Software Engineering”, Prentice Hall, 2000.

[7] S.R, & Kemerer, C.F Chidamber, “Metrics Suite for Object Oriented,“IEEE

Transaction on Software Engineering, pp. 476-493,1993.

[8] H, Jung, “Computer standars & Interface, “Validating the external quality subcharactheristics of software product according to ISO/IEC 9126.

[9] ISO/IEC,” Metrics External and Quality in Use,”JTI/SC7 in N2416R, p.4, 2002.

[10] A Kotze, and Padayachee Der Merwe Van,”ISO 9126 external system quality charactheristics, subcharactheristics and domai spesific criteria for evaluating e-learning systems,” Chicago 2010.

[11] James F. Peters and Witold Pedrcyz,” Software Engineering : Engineering Approach,” John Wiley & Sons, 2002.

[12] Su Hua Wang and Dangjie Chen Durgest Samadhiya,”Software Quality :

Role and Value of Quality Models”.

[13] Amira Salsabila, “Sistem pendukung keputusan penentuan resep makanan berdasarkan ketersediaan bahan makanan menggunakan metode SAW (simple aditive weight).

154

[14] Yiannis Kanellopoulos, Panos Antonella, Dimitris Antoniou, Cristos Makris, Evangelos Theodoridis, Christos Tjorjis and Nikos Trisakis, “Code

quality evaluating methodology using the ISO/IEC 9126 Standard ,

International Journal of software engineering & application (USEA) vol.1, no.3 July 2010.

[15] Amit Sharma, Sanjay Kumar Dubey, “ Comparison os SoftwareQuality Metrics fot Object-Oriented System

1 BAB 1 PENDAHULUAN

1.1Latar Belakang Masalah

Polisi Daerah Jawa Barat (Polda Jabar) adalah markas kesatuan polisi yang bertanggung jawab mengamankan, melindungi dan melayani masyarakat yang berada di wilayah pemerintahan provinsi Jawa Barat. Kepolisian daerah Jawa Barat merupakan induk dari seluruh kantor Polisi didaerah Jawa Barat, alamat Polda jabar berada di Jl. Soekarno-Hatta no.748 Bandung. Polda Jabar sendiri dipimpin oleh Inspektur Jendral Polisi bintang dua atau setara dengan Gubernur apabila disistem pemerintahan sipil.

Kepolisian daerah Jawa Barat mempunyai website resmi yang digunakan untuk memberikan pelayanan secara online pada masyarakat. Website Polda Jabar sendiri dibuat dengan pemrograman PHP dan menggunakan Framework

CodeIgneter dengan konsep OOP (Object Oriented Progaming). Namun menurut

pihak humas kendala yang terjadi pada website Polda Jabar terkait performansi yang terkadang lama saat diakses. Masalah yang ada pada website Polda bisa dikarenakan dari hosting yang bermasalah atau sebuah perancangan framework yang tidak baik. Sebuah framework yang didesain untuk membantu sebuah pemrograman tidak selamanya baik, hal ini dikarenakan tergantung pada pembuat program dalam mendesain arsitektur code dan arsitektur class dalam desain OOP (Object Oriented Progaming) [1]. Karena tidak tepatnya mendesain arsitektur code dan arsitektur class akan mempengaruhi performa dan pemeliharaan sebuah perangkat lunak. Selain itu pihak Polda belum mendapatkan tanggapan secara keseluruhan dari masyarakat terhadap website agar mengetahui kelayakan website dari sisi penggunaan.

Penilaian kualitas pada website Polda Jabar dapat menggunakan metode penilaian kualitas perangkat lunak. Penilaian kualitas perangkat lunak dapat menilai dari sisi tanggapan pengguna (quality) dan dari program (internal). Untuk melakukan penilaian kualitas perangkat lunak ada banyak model penilaian perangkat lunak yang dapat digunakan diantaranya model Mc Call, model

2

Dromey, model Boehm dan standar ISO. Pada penelitian ini akan menggunakan standar ISO 9126, karena standar ISO 9126 merupakan standar internasional dalam penilaian kualitas perangkat lunak yang sudah disepakati. Menurut standar ISO Penilaianterdiri dari sisi pengguna(quality in use), faktor luar(external) dan sisi program (internal) [2].

Berdasarkan latar belakang masalah diatas maka saya akan mengajukan judul skripsi ” Penilaian Kualitas Website Polda Jabar Dari Sisi Quality in Use dan Sisi Internal Menggunakan Standar ISO”

1.2Rumusan Masalah

Berdasarkan pemaparan pada latar belakang masalah, dapat diambil perumusan masalah pada penelitian ini adalah bagaimana menilai serta mengevaluasi website Polda Jabar dari sisi Quality in use dan Internal.

1.3Maksud dan Tujuan

Adapun yang menjadi maksud dari penulisan tugas akhir ini adalah membantu pihak Polda Jabar untuk menilai dan mengevaluasi website Polda Jabar menggunakan standar ISO 9126.

Sedangkan tujuan yang ingin dicapai dari penelitian ini adalah sebagai berikut:

1. Membantu pihak Polda untuk mengetahui nilai kualitas website.

2. Memberikan rekomendasi perbaikan terhadap arsitektur penulisan code dan class apabila ada kekurangan.

3. Membantu pihak Polda untuk mendapatkan tanggapan dari masyarakat terkait penggunaan website.

1.4Batasan Masalah

Agar masalah yang dibahas tidak menyimpang, maka diperlukan adanya batasan masalah. Adapun yang menjadi batasan masalah dalam penulisan tugas akhir ini adalah sebagai berikut :

3

1. Penilaian kualitas pada website Polda Jabar.

2. Standar faktor untuk penilaian kualitas perangkat lunak menggunakan standar ISO 9126 karena model ini merupakan standar internasional. 3. Penilaian yang dilakukan untuk mengetahui nilai dari sisi internal dan

quality in use.

4. Penilaian internal menggunakan perhitungan metriks OO pada source code.

5. Penilaian internal hanya meliputi efficiency, Reusability, Undertandability dan Maintanability.

6. Penilaian quality in use menggunakan kuisioner berdasarkan metriks quality in use model ISO 9126.

1.5Metodologi Penelitian

Metodologi penelitian yang akan digunakan dalam menyusun tugas akhir ini menggunakan metode Analisis Kuantitatif, yaitu metode yang sudah ada model sebelumnya yaitu standar ISO 9126. Pada penelitian ini ada pengumpulan data, penentuan karakter website Polda Jabar, perhitungan metriks berdasarkan pengumpulan data untuk mengetahui nilai dari sisi quality in use dan internal.

1.5.1 Metode Pengumpulan Data

Adapun teknik pengumpulan data yang akan digunakan, diantaranya : 1. Studi literatur

Pengumpulan data dilakukan dengan mempelajari hal yang bersinggungan dengan standar ISO 9126 untuk menentukan kualitas perangkat lunak, dan pengumpulan data diperoleh dari jurnal penelitian lain dan pada buku untuk mengetahui penilaian dari sisi quality in use dan penilaian internal program. 2. Kuesioner

Pengumpulan data diperoleh dari kuesioner yang disebar pada para pengguna website Polda Jabar untuk mengetahui kualitas perangkat lunak yang dijadikan pada penelitian ini.

4

1.5.2 Metode Analisis Perangkat Lunak

Metode pembentukan kualitas perangkat lunak yang digunakan pada penelitian ini diantaranya :

1. Penentuan domain masalah

Pada tahap ini dilakukan penentuan domain masalah yang akan dijadikan penelitian.

2. Penentuan metriks kualitas

Penentuan metriks dilakukan dengan memilih metriks yang digunakan untuk mengukur kualitas website.

3. Penentuan perhitungan OO metrik

Penentuan perhitungan OO metrik pada source code dilakukan agar mengetahui cara menilai dan merancang penilaian dalam kaidah OO metriks.

4. Perhitungan OO metriks pada source code dan evaluasi

pada source code dilakukan agar mengetahui nilai sesuai dengan faktor yang terdapat pada penilaian OO metrik dan memberikan evaluasi.

5. Rekomendasi perbaikan nilai kualitas, arsitektur code dan class

Perbaikan perhitungan nilai kualitas arsitektur code dan class dilakukan agar mendapat nilai yang baik dari sisi Internal.

6. Kesimpulan faktor Internal

Setelah hasil penilaian website Polda Jabar dari faktor internal diketahui dan dievaluasi, maka didapatkan kesimpulan dari penilaian akhir dari faktor internal website Polda Jabar.

7. Pembentukan kuesioner

Pembentukan kuesioner ini dilakukan untuk merancang kuesioner yang diajukan pada para pengguna atau responden untuk mengetahui nilai dari para pengguna berdasarkan faktor quality in use metriks ISO.

8. Pengajuan kuesioner

Pengajuan kuesioner dilakukan untuk mencari pendapat dari pengguna atau responden Website Polda Jabar agar dapat dijadikan hasil penelitian.

5

9. Pengolahan kuesioner

Setelah membagikan kuesioner pada para responden, kemudian dilakukan pengolahan kuisioner untuk dianalisis agar mengetahui hasil dari hasil kuesioner.

10.Kesimpulan faktor Quality in use

Setelah hasil penilaian website Polda Jabar diketahui, maka didapatkan kesimpulan dari penilaian akhir dari faktor quality in use Polda Jabar. 11.Kesimpulan Akhir Penilaian Kualitas Polda Jabar

Setelah mendapatkan kesimpulan internal dan quality in use maka kedua kesimpulan itu dijadikan acuan untuk kesimpulan nilai akhirwebsite Polda Jabar.

Gambar 1.1 Tahap Penilaian Penentuan Domain Masalah Penentuan Metriks Kualitas Penentuan perhitungan OO metrik Pembentukan Kuisioner Quality in use

Pengajuan Kuisioner Pengolahan Nilai Kuisioner Kesimpulan Faktor Quality in Perhitungan OO metriks Pada Source Code dan

evaluasi Rekomendasi perbaikan nilai kualitas Kesimpulan Faktor Internal Kesimpulan Akhir Penilaian

6

1.6Sistematika Penulisan

Sistematika penulisan tugas akhir ini disusun untuk memberikan gambaran secara umum tentang penelitian yang dijalankan. Sistematika penulisan tugas akhir ini adalah sebagai berikut :

BAB 1 PENDAHULUAN

Bab ini akan membahas mengenai latar belakang masalah, perumusan masalah, maksud dan tujuan, batasan masalah, metodologi penelitian yang digunakan, serta sistematika penulisan.

BAB 2 LANDASAN TEORI

Membahas berbagai konsep dasar dan teori-teori yang berkaitan dengan topik penelitian yang dilakukan dan hal-hal yang berguna dalam proses analisis permasalahan.

BAB 3 ANALISIS DAN PEMBENTUKAN FAKTOR KUALITAS

Membahas tentang hasil analisis penilaian perangkat lunak yang digunakan sebagai objek penelitian, pembentukan kuisioner dam contoh perhingan metriks berdasarkan standar penilaian.

BAB 4 PERHITUNGAN METRIKS DAN PENGOLAHAN KUISIONER Bab ini berisi tentang perhitungan metriks penilaian berdasarkan faktor penilaian yang telah ditentukan dan dilakukan penilaian akhir dari setiap faktor dan sub faktor serta rekomendasi perbaikan yang bisa diperbaiki.

BAB 5 KESIMPULAN DAN SARAN

Bab ini akan dijelaskan mengenai kesimpulan terhadap hasil penelitian berikut saran-saran.

7 BAB 2

LANDASAN TEORI

2.1Definisi Perangkat Lunak

Menurut definisi IEEE Institute of Electrical Enggineers, Perangkat lunak adalah Program komputer, prosedur, dan dokumentasi yang menyertai serta data yang digunakan untuk mengoprasikan sistem komputer. Definisi IEEE tersebut hampir identik dengan definisi ISO [1]. Perangkat lunak terdiri dari 4 komponen, yaitu :

1. Program Komputer 2. Prosedur

3. Dokumentasi

4. Data yang diperlukan agar perangkat lunak beroperasi

2.2Definisi Kualitas Perangkat Lunak

Menurut steve McConnell’s, Code Complete membagi perangkat lunak

kedalam dua hal yaitu internal quality dan eksternal quality characteristics. Karakteristik kualitas eksternal merupakan bagian dari suatu produk yang berhubungan dengan para pemakainya, sedangkan kualitas internal tidak secara langsung berhubungan dengan pemakai. Software quality didefinisikan sebagai kesesuaian yang diharapkan pada semua software yang dibangun dalam fungsi

software yang diutamakan dan untuk kerja software, standar pembangunan yang

terdokumentasi dan karakteristik yang ditunjukan software [1]. Definisi ini menekankan pada 3 hal yaitu :

1. Kebutuhan software adalah pondasi ukuran kebutuhan software adalah pondasi ukuran kualitas software, jika software tidak sesuai dengan kebutuhan yang ditentukan maka kualitasnya pun kurang.

2. Jika menggunakan suatu standar untuk pembangunan software maka jika

software tidak memenuhi standar tersebut maka dianggap kurang

8

3. Seringkali ada kualitas yang secara langsung diutarakan (tersirat) seperti kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software dipertanyakan jika tidak memenuhi kebutuhan ini.

Hal lain yang perlu diperhatikan dalam kualitas perangkat lunak adalah quality assurarance (QA) yang merupakan acctivity of providing revidence. Selain itu harus adanya software quality management (SQM). Tujuan dari SQM adalah untuk mengembangkan suatu pemahaman kuantitatif dari kualitas proyek produk perangkat lunak dan mencapai tujuan spesifik kualitasnya. Menurut IEEE, kualitas perangkat lunak didefinisikan sebagai derajat dari sebuah sistem, komponen atau proses yang memenuhi kebutuhan-kebutuhan yang dispesifikasikan dan kebutuhan pengguna atau harapan pengguna. Menurut Pressman, kualitas perangkat lunak adalah kesesuaian antara kebutuhan fungsional dan kebutuhan performansi yang terdefinisi, standar pengembangan yang terdokumentasi secara ekplisit dan karakteristik-karakteristik yang tersirat yang diharapkan dari perangkat lunak yang dikembangkan secara profesional [5].

2.3Definisi Website

Definisi website adalah sekumpulan halaman yang terdiri dari beberapa halaman yang berisi informasi dalam bentuk digital baik itu teks, gambar, animasi yang disediakan melalui jalur internet sehingga dapat diakses dari seluruh dunia. Pada dasarnya website dibagi menjadi dua yaitu:

1. Website statis

Merupakan website yang halamannya tidak berubah, biasanya untuk melakukan perubahan dilakukan secara manual dengan mengubah code. Website statis ini informasinya satu arah, yakni hanya berasal dari pemilik software nya saja dan hanya bisa di update oleh pemilik software nya saja.

9

2. Website dinamis

Merupakan web halaman yang selalu di update, biasanya terdapat halaman

backend (halaman administator) yang digunakan untuk mengubah konten.

Web dinamis membutuhkan database untuk menyimpan data. Web dinamis mempunyai informasi dua arah, yakni berasal dari pengguna dan pemiliknya.

2.4Pemrograman Berorientasi Objek

Objek adalah kesatuan entitas yang memiliki sifat dan tingkah laku. Dalam kehidupan sehari-hari, objek adalah benda, baik benda berwujud nyata seperti manusia, hewan, mobil, komputer, handphone, pena, ataupun benda yang tidak nyata atau konsep, seperti halnya tabungan bank, sistem antrian, sistem internet banking, dan sebagainya. Jadi pengertian OOP adalah konsep yang membagi program menjadi objek-objek yang saling berinteraksi satu sama lain. Objek adalah benda, baik benda yang berwujud nyata maupun benda yang tidak nyata (konsep). Jika menggunakan OOP maka akan ada enam keuntungan yang dapat diperoleh, yaitu [3]:

1. Alami (Natural).

2. Dapat diandalkan (Reliable).

3. Dapat digunakan kembali (Reusable).

4. Mudah untuk dalam perawatan (Maintainable). 5. Dapat diperluas (Extendable).

6. Efisiensi waktu.

Berikut ini beberapa bahasa pemrograman yang sudah menggunakan konsep OOP, adalah :

1. C++. 2. C#.

3. Visual Basic. 4. Java.

10

2.4.1 Analisis dan Desain Berorientasi Objek (Object-Oriented Analysis and Design Process)

Pemrograman berorientasi objek bekerja dengan baik ketika dibarengi dengan object-oriented analysis and design process (OOAD). Jika membuat program berorientasi objek tanpa OOAD, ibarat membangun rumah tanpa terlebih dahulu menganalisa apa saja yang dibutuhkan oleh rumah itu, tanpa perencanaan tanpa blueprint, tanpa menganalisis ruangan apa saja yang diperlukan, berapa besar rumah yang akan dibangun dan sebagainya.

2.4.2 Orientasi Objek (Object)

Orientasi objek merupakan teknik dalam menyelesaikan masalah yang kerap muncul dalam pengembangan perangkat lunak. Teknik ini merupakan titik kulminasi dalam menemukan cara yang efektif dalam membangun sistem dan menjadi metode yang paling banyak dipakai oleh para pengembang perangkat lunak saat ini. Orientasi objek merupakan teknik pemodelan sistem riil yang berbasis objek. Inti dari konsep ini adalah objek yang merupakan model dari sistem nyata.

Objek adalah entitas yang memiliki atribut, karakter dan kadangkala disertai kondisi. Objek merepresentasikan sesuatu sistem nyata seperti siswa, sistem kontrol permukaan sayap pesawat, sensor atau mesin. Objek juga merepresentasikan sesuatu dalam bentuk konsep seperti nasabah bank, merek dagang, pernikahan atau sekedar listing. Bahkan bisa juga mengatakan visualisasi seperti, bentuk huruf, histogram, poligon, garis atau lingkaran. Semuanya memiliki fitur atribut (untuk data), behavior (operation atau method), keadaan (memori), identitas dan tanggung jawab. Proses menjabarkan sistem nyata menjadi objek dinamakan abstraksi (abstraction). Abstraksi mengeliminir aspek yang tidak perlu dalam suatu objek.

11

2.4.3 kelas (Class)

Kelas adalah penggambaran satu set objek yang memiliki atribut dan behaviour yang sama. Kelas mirip tipe data pada pemrograman non objek, tapi lebih komprehensif karena terdapat struktur sekaligus karakteristiknya. Programmer dapat membentuk kelas baru yang lebih spesifik dari kelas general -nya. Kelas dan objek merupakan jantung dari pemrograman berorientasi objek.Untuk menghasilkan program jenis ini sangat penting untuk selalu berfikir dalam bentuk objek [15].

2.4.4 Pembungkusan (Encapsulation)

Pembungkusan sebagai penggabungan potongan-potongan informasi dan perilaku-perilaku spesifik yang bekerja pada informasi tersebut, kemudian mengemasnya menjadi apa yang disebut sebagai objek. Dalam perbankan dikenal objek rekening yang memiliki perilaku-perilaku misalnya buka, tutup, penarikan, penyimpanan, ubah nama, ubah alamat, dan sebagainya. Akibatnya, perubahan-perubahan pada sistem perbankan yang berkaitan dengan rekening-rekening dapat secara sederhana diimplementasikan satu kali saja pada objek rekening. Keuntungan lainnya adalah membatasi efek-efek perubahan pada sistem. Misalnya, saat manajemen bank menentukan jika seseorang memiliki rekening pinjaman di bank yang bersangkutan, rekening pinjaman itu harus dapat juga digunakan sebagai sarana bagi penarikan rekening [3].

2.4.5 Pewarisan (Inheritance) dan Generalisasi/Spesialisasi

Konsep dimana metode dan atau atribut yang ditentukan di dalam sebuah objek kelas dapat diwariskan atau digunakan lagi atau digunakan lagi oleh objek kelas lainnya. Sedangkan generalisasi/spesialisasi merupakan teknik dimana atribut dan perilaku yang umum pada beberapa tipe kelas objek, dikelompokkan (atau diabstraksi) ke dalam kelasnya sendiri (dinamakan supertype). Atribut dan metode kelas objek supertype kemudian diwariskan oleh kelas objek tersebut (dinamakan subtype) [3].

12

2.5UML (Unified Modeling Language)

UML adalah keluarga notasi grafis yang didukung oleh meta-modeltunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek. Definisi ini merupakan definisi sederhana. Pada kenyataannya, pendapat orang-orang tentang UML berbeda satu sama lain. Hal ini dikarenakan oleh sejarahnya sendiri dan oleh perbedaan persepsi tentang apa yang membuat sebuah proses rancang bangun perangkat lunak efektif.

UML merupakan standar yang relatif terbuka yang dikontrol oleh Object

Management Group (OMG), sebuah konsorsium terbuka yang terdiri dari banyak

perusahaan. OMG dibentuk untuk membuat standar-standar yang mendukung interoperabilitas, khususnya interoperabilitas sistem berorientasi objek. OMG mungkin lebih dikenal dengan standar-standar COBRA (Common Object Request Broker Architecture).

UML lahir dari penggabungan banyak bahasa pemodelan grafis berorientasi objek yang berkembang pesat pada akhir 1980-an dan awal 1990-an. Sejak kehadirannya pada tahun 1997, UML menggantikan menara Babel yang telah menjadi sejarah. UML merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM.

Bagian-bagian utama dari UML adalah view, diagram, model element, dan

general mechanism [3]. Diagram berbentuk grafik yang menunjukkan simbol

elemen model yang disusun untuk mengilustrasikan bagian atau aspek tertentu dari sistem. Sebuah diagram merupakan bagian dari suatu view tertentu dan ketika digambarkan biasanya.

13

Gambar 2.1 Diagram UML [4] Berikut ini penjelasan singkat dari pembagian kategori tersebut.

1. Structure diagrams yaitu kumpulan diagram yang digunakan untuk

menggambarkan suatu struktur statis dari sistem yang dimodelkan.

2. Behavior diagrams yaitu kumpulan diagram yang digunakan untuk

menggambarkan kelakuan sistem atau rangkain perubahan yang terjadi pada sebuah sistem.

3. Interaction diagrams yaitu kumpulan diagram yang digunakan untuk

menggambarkan interaksi sistem dengan sistem lain maupun interaksi antarsubsistem pada suatu sistem.

14

2.5.1 Diagram Kelas (Class Diagram)

Diagram kelas menggambarkan struktur sistem dari segi pendefinisian kelas-kelas yang akan dibuat untuk membangun sistem. Kelas memiliki apa yang disebut atribut dan metode atau operasi.

1. Atribut merupakan variabel-variabel yang dimiliki oleh suatu kelas. 2. Operasi atau metode adalah fungsi-fungsi yang dimiliki oleh suatu kelas.

Diagram kelas dibuat agar pembuat program atau programmer membuat kelas-kelas sesuai rancangan di dalam diagram kelas-kelas agar antara dokumentasi perancangan dan perangkat lunak sinkron. Berikut adalah contoh dari diagram kelas.

KoneksiDatabase +host

+database +username +password +open() +execute() +getResult() +close()

Gambar 2.2 Contoh Class Diagram [4]

2.5.2 Diagram Use Case

Diagram use case merupakan pemodelan untuk kelakuan (behaviour) sistem informasi yang akan dibuat. Use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem informasi yang akan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi itu. Syarat penamaan pada use case adalah nama didefinisikan sesimpel mungkin dan dapat dipahami. Ada dua hal utama pada use case yaitu pendefinisian apa yang disebut aktor dan use case.

15

Gambar 2.3 Contoh Use Case Diagram [4]

2.5.3 Diagram Sekuen (Sequence Diagram)

Diagram sekuen menggambarkan kelakuan pada objek use case dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima antar objek. Oleh karena itu untuk menggambar diagram sekuen maka harus diketahui objek-objek yang terlibat dalam sebuah use case beserta metode-metode yang dimiliki kelas yang diinstansiasi menjadi objek itu. Membuat diagram sekuen juga dibutuhkan untuk melihat skenario yang ada pada use case. Banyaknya diagram sekuen yang harus digambar adalah minimal sebanyak pendefinisian use case yang memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi jalannya pesan sudah dicakup pada diagram sekuen sehingga semakin banyak use case yang didefinisikan maka diagram sekuen yang harus dibuat juga semakin banyak.

16

Petugas Pertukaan

m : Main

an : Antarmuk a

v : Valida si

k :

KoneksiBasi sData

p :

Petuga s

1 : main()

2 : formLogin()

3 : username dan passwor d 4 : login()

5 <<create>>

6 <<create>>

7 : open()

8 : queryCekLogin()

9 : execute() 10 : getResult()

11 : username dan password petugas 12 : close()

13 <<destroy>> 14 <<destroy>>

17

2.6 Orientasi Objek Metriks

Menurut Chidamber dan Kemerer Metric untuk mengukur perangkat lunak berbasis objek oriented dapat menggunakan enam buah metriks [7], yaitu :

1. Weight Methods per Class (WMC)

Pengkuran metriks WMC adalah menghitung jumlah method yang diimplementasikan dalam suatu class. Untuk mengetahuinya maka dihitung seluruh method lokal pada sebuah perangkat lunak [7].

Rumus : m1+m2+m3+...+mn

m adalah sebuah method lokal yang dijumlahkan pada setiap class. 2. Depth of Inheritance Tree (DIT)

DIT merupakan penghitungan jalur inhereitance maksimum dari sebuah class. Kedalaman sebuah class dalam hirarki pewarisan diukur oleh DIT. Rumus : Apabila ada pewarisan diberikan nilai 1 dan apabila tidak ada diberikan nilai 0 [4].

3. Number of Children (NOC)

Pengukuran NOC adalah menghitung jumlah children atau anak class [7]. Rumus : Apabila ada anak diberi nilai dan apabila tidak tidak diberi nilai.

4. Coupling Between Objects (CBO)

Coupling adalah ketergantungan modul satu dengan modul lainnya,

coupling yang baik adalah coupling yang rendah dimana modul satu dengan modul lainnya tidak saling ketergantungan. Suatu fungsi yang berpasangan dihitung sebagai coupling. Semakin kecil jumlah CBO maka semakin baik kualitas class tersebut.

Rumus : Menghitung jumlah dari method lokal ditambah method eksternal [7].

18

5. Respon for a Class (RFC)

RFC adalah method yangg diimplementasikan dalam class ditambahkan class yang diakses objek dari jenis class tersebut Semakin tinggi nilai RFC maka semakin besar kompleksitas class tersebut dan semakin membutuhkan waktu yang lama dalam pemeliharaannya. Pengukuran RFC yaitu menghitung jumlah method lokal yang diimplementasikan ditambah method yang dipanggil dalam objek[7].

Rumus : jumlah method lokal + jumlah method eksternal.

6. Lack OF Cohesion in Method (LCOM)

Cohesi yang baik adalah cohesi yang tinggi, semakin tinggi cohesi semakin baik perancangannya. Cohesi yang mempunyai nilai tumbukan antara 0-1 adalah nilai cohesi yang baik dan sedang. Sedangkan nilai cohesi yang rendah mempunyai nilai 2 yang menandakan class tersebut harus dipecah menjadi dua. Cohesion sebuah class adalah karakteristik seberapa dekat method-method lokal terhubung dengan variabel lokal dalam sebuah class. Pengukuran LCOM dilakukan dengan menghitung jumlah koneksi pada method. Rumus Perhitungannya adalah:

LCOM*= (m – sum (mA) / a) / (m-1). Dimana:

m adalah jumlah method dalam class. a adalah jumlah variable dalam class.

mA adalah method yang mengakses variable. Sum (mA) adalah jumlah variable yang dipanggil.

19

Faktor penilaian yang mempengaruhi ada pada tabel dibawah ini: 2.1 Tabel Faktor Penilaian Akhir Faktor Internal

Faktor Penilaian Metriks

Efficiency

Understandability

Reusability

Maintanability/testability

2.7 Model Metriks Kualitas Perangkat Lunak

Dalam ilmu rekayasa perangkat lunak terdapat beberapa model pennilaian kualitas perangkat lunak. Pada setiap model terdapat faktor penilaian yang menjadi poin utama dan subfaktor yang mendukung penilaian atas faktor tersebut. Model ISO-9126 dikenalkan pada tahun 1991 sebagai standarisasi kualitas produk perangkat lunak. Standarisasi ini dibuat karena banyaknya model kualitas yang ditawarkan sebagai penilaian kualitas perangkat lunak. Dalam model ISO 9126 terdiri dari beberapa bagian model kualitas untuk kualitas sebuah produk perangkat lunak, yaitu:

1. Internalquality

2. External quality

20

2.7.1 Standar ISO 9126

Gambar 2.5 Faktor ISO 9126 [8]

Standar ISO 9126 Adalah standar internasional yang diterbitkan ISO untuk evaluasi kualitas perangkat lunak. Ada 6 ukuran kualitas yang ditetapkan oleh ISO 9126, yaitu Functionality (Fungsionalitas), Reliability (Kehandalan), Usability (Kebergunaan), Efficiency (Efisiensi), Maintanability (Pemeliharaan), dan Portability (Portabilitas). Standar ISO 9126 pertama kali dikenalkan pada tahun 1991. Standar ISO 9126 mengidentifikasi 6 karakteristik kualitas perangkat lunak utama yaitu:

a. Functionality

Kemampuan menutupi fungsi produk perangkat lunak yang menyediakan kepuasan kebutuhan user.

b. Reliability

Kemampuan perangkat lunak untuk perawatan dengan level performansi.

c. Usability

Kemampuan yang berhubungan dengan kebergunaan perangkat lunak. d. Efficiency

adalah faktor kemampuan yang berhubungan dengan pengaksesan sebuah peerangkat lunak yang sedang berjalan.

ISO-9126

21

e. Maintanability

adalah kemampuan yang dibutuhkan untuk membuat perubahan serta pemeliharaan pada sebuah perangkat lunak.

f. Portability

Kemampuan yang berhubungan dengan kemampuan perangkat lunak yang dikirim kelingkungan yang berbeda.

2.7.2 Model Quality In Use

Gambar 2.6 Faktor Quality in Use ISO 9126 [8]

Model Quality In Use mempunyai 4 Faktor yaitu Effectiveness, Productivity,

Safety dan Satisfaction. Masing masing faktor juga mempunyai beberapa metriks.

Berikut penjelasannya : a. Effectiveness

Effectiveness ( Efektivitas ) berhubungan dengan seberapa efektif suatu perangkat lunak terhadap penggunanya.

22

Tabel 2.2 Effectiveness

Karakteristik Metriks Rumus

Effectiveness Task completion X = A/B

A = jumlah tugas diselesaikan B = jumlah tugas yang dicoba

Error frequency X = A/T

A = jumlah kesalahan yang dibuat oleh pengguna

T = jumlah tugas dicoba

b. Productivity

Productivity ( Produktivitas ) berhubungan dengan seberapa produktif kah

perangkat lunak terhadap penggunanya

Tabel 2.3 Productivity

Karakteristik Metriks Rumus

Productivity Task time X = Ta

Ta = Waktu mencoba

Task efficiency X = M1 / T

M1 = efektivitas tugas T = Waktu

Economic productivity

X = M1 / C

M1 = efektivitas tugas C = total biaya tugas Productive

proportion

X = Ta / Tb

Ta = waktu produktif =

waktu tugas – waktu bantu - waktu error - waktu pencarian

23

Karakteristik Metriks Rumus

Relative user

efficiency

Relative user efficiency X = A / B A = efisiensi tugas pengguna biasa ini

B = efisiensi tugas ahli pengguna

c. Safety

Safety ( Keamanan ) berhubungan dengan seberapa aman perangkat lunak

yang dianalisis terhadap penggunanya.

Tabel 2.4 Safety

Karakteristik Metriks Rumus

Safety Safety of people

affected by use of the system

X = 1-A / B

A = jumlah orang menaruh di hazard B = Jumlah orang yang berpotensi terkena dampak oleh sistem Economic

damage

X = 1-A / B

A = jumlah kejadian kerusakan ekonomi

B = Jumlah situasi penggunaan

Software damage X = 1-A / B

A = jumlah kejadian perangkat lunak corrupt

24

d. Satisfaction

Satisfaction (Kepuasan) berhubungan dengan kepuasan pelanggan

terhadap perangkat lunak yang digunakan.

Tabel 2.5 Satisfaction

Karakteristik Metriks Rumus

Satisfaction Discretionary

usage

X = A / B

A = berapa kali fungsi perangkat lunak tertentu / aplikasi / sistem yang digunakan

B = jumlah pengguna menggunakan Satisfaction

questionnaire

X = A / n

Ai) menanggapi pertanyaan n = jumlah tanggapan

e. Kriteria nilai akhir kualitas perangkat lunak quality in use standar ISO 9126.

Tabel 2.6 Kriteria Nilai Metriks Quality in use

Weight Range Nilai

Kurang 0 – 0.33

Cukup Baik 0.34 – 0.67

Baik 0.68 – 1

Apabila nilai akhir dari sisi Quality in Use berada dalam kategori kurang maka perangkat lunak tersebut mendapatkan respon yang kurang baik dari masyarakat, apabila penilaian akhir dalam kategori cukup maka perangkat lunak tersebut mendapatkan respon yang cukp baik dari masyarakat dan apabila penilaian akhir mendapatkan respon baik maka perangkat lunak mendapatkan respon yang baik dari masyarakat.

25

2.8 Metode Pengukuran Kualitas Perangkat Lunak

Pengukuran kualitas perangkat lunak merupakan hal yang terpenting dari praktek rekayasa perangkat lunak yang baik. Pengukuran ini membantu untuk membuat karakteristik khusus dari proses dan produk informasi. Pengukuran meliputi evaluasi kuantitatif yang biasanya menggunakan metriks serta ukuran dapat menggunakan secara langsung menentukan pencapaian tujuan kualitas numerik. Pengukuran selalu menjadi fundamental bagi kemajuan untuk setiap disiplin rekayasa dan pengujian perangkat lunak. pengukuran perangkat lunak dan metrik menjadi peran mendasar dalam siklus hidup pengembangan perangkat lunak, dan Metriks perangkat lunak telah digunakan dalam membuat keputusan kuantitatif / kualitatif maupun dalam penilaian risiko dan pengurangan dalam proyek perangkat lunak. Proses pengukuran merupakan cara untuk melakukan pengukuran faktor kualitas dari sebuah perangkat lunak.

Pengukuran kualitas perangkat lunak website Polda Jabar akan menggunakan pehitungan OO Metriks untuk menghitung bagian internal program, karena OO metriks sesuai dengan website Polda Jabar yang berorientasi objek. Sedangkan untuk perhitungan ekstenal menggunakan metriks ISO 9126, Metriks 9216 ini melakukan perhitungan External dan Quality in use berdasarkan karakteristik dari 6 faktor yang ada pada model ISO 9126 [7][9]. Penghapusan kesalahan adalah Sebuah ukuran seberapa banyak cacat yang ditemukan selama review dihapus (dikoreksi) selama desain dan implementasi tahap. Metrik dapat dihitung dengan rumus X = A / B. dimana A adalah jumlah bug tetap selama desain dan coding dan B adalah Jumlah yang ditemukan selama review. Semakin dekat nilai adalah 1, yang lebih baik. A Nilai penghapusan kesalahan orang akan berarti bahwa setiap cacat terdeteksi telah dihapus. Metriks Eksternal ISO 9126 mempunyai beberapa metrik eksternal. Metriks eksternal didefinisikan dalam ISO 9126-2 dan diukur selama pengujian dinamis. Kategori metrik ini sesuai dengan yang internal

yaitu maturity, fault tolerance, recoverability, and compliance. Metriks

Kematangan mengukur kebebasan sistem perangkat lunak dari kegagalan disebabkan oleh bug di sistem itu sendiri.

26

2.9 Pengukuran

Pengukuran perangkat lunak adalah faktor utama untuk mengetahui seberapa baik perangkat lunak yang akan dinilai berdasarkan metode yang digunakan. Pengukuran perangkat lunak dilakukan dengan cara mencari nilai kriteria perangkat lunak tersebut dan juga mencari bobot kepentingan berdasarkan metode yang akan digunakan. Penilaian keseluruhan dapat diperoleh dari hasil nilai kriteria dan juga nilai bobot. Perhitungan bobot dan nilai kriteria bisa bervariasi tergantung dengan metode apa yang digunakan [10].

2.10 Metode Pembobotan

Rank Order Centroid (ROC) didasarkan pada tingkat kepentingan atau

prioritas dari kriteria. Menurut Jeffreys dan Cockfield dalam Afiefah Rahma, teknik ROC memberikan bobot pada setiap kriteria sesuai dengan ranking yang dinilai berdasarkan tingkat prioritas. Biasanya dibentuk dengan pernyataan “Kriteria 1 lebih penting dari kriteria 2, yang lebih penting dari kriteria 3” dan seterusnya hingga kriteria ke n, ditulis . Untuk menentukan bobotnya, diberikan aturan yang sama yaitu dimana merupakan bobot untuk kriteria [10][13].

Atau dapat dijelaskan sebagai berikut: Jika

Cr1 ≥ Cr2 ≥ Cr3 ≥ ... ≥ Crn Maka

W1 ≥ W2 ≥ W3 ≥ ... ≥ Wn

Selanjutnya, jika k merupakan banyaknya kriteria, maka

27

Secara umum pembobotan ROC dapat dirumuskan sebagai berikut :

∑

2.11 Metode Pengolahan Kuesioner

Kuesioner merupakan sekumpulan pertanyaan yang diajukan kepada responden dengan tujuan dan maksud tertentu untuk memperoleh data, sehingga data tersebut dapat digunakan atau diolah kembali. Untuk mengolah data dari kuesioner tersebut dapat menggunakan berbagai macam metode pengolahan data sesuai dengan rumus metriks yang digunakan pada ISO 9126. Kuisioner ini diajukan untuk memenuhi nilai A, B maupun T yang dibutuhkan untuk menghitung nilai metriks dai setiap kriteria yang sudah ada. Dari hasil jawaban yang diberikan oleh responden akan dicari nilai rata rata, hasil jawaban responden akan dijumlahkan dan totalnya akan dibagi dengan jumlah responden. Maka akan didapat nilai A, B ataupun T.

2.12 Metode Penilaian

Perhitungan nilai sub faktor , faktor maupun nilai keseluruhan menjadi faktor penting untuk mengetahui hasil akhir sebuah nilai. menentukan nilai kriteria per faktor nya dan nilai akhir dengan rumus perhitungan Weight Summation. Nilai w adalah nilai metriks yang diperoleh dari hasil pengolahan kuisioner dan m adalah bobot dari sub faktor atau faktor yang sudah diperoleh dari hasil perhitungan dengan menggunakan metode Rank Order Centroid (ROC) [12].

1 Nilai kriteria

Kriteria ∑ ... =w1m1 + w2m2+…… wnmn

151 BAB 5

KESIMPULAN DAN SARAN

Pada bab ini berisikan kesimpulan dari hasil penelitian yang telah dilakukan serta saran untuk perbaikan dan pengembangan penelitian lebih lanjut.

5.1 Kesimpulan

Berdasarkan hasil yang didapatkan dalam penelitian dan penyusunan skripsi ini serta disesuaikan dengan tujuan, maka diperoleh kesimpulan bahwa:

1. Pihak Polda mendapatkan nilai kualitas website.

2. Rekomendasi perbaikan yang diberikan adalah perbaikan nilai kualitas, arsitektur code dan arsitektur class agar website Polda dapat diakses lebih cepat dan mudah dalam pemeliharaannya.

3. Setelah mengolah kuesioner yang berkaitan dengan website Polda Jabar dari sisi penggunaan hasil yang didapatkan menunjukkan sudah mendapapatkan respon yang baik dari masyarakat.

5.2 Saran

Berdasarkan hasil dari perhitungan metriks dam pengolahan kuesioner, maka dapat diberikan saran yaitu perbaikan pada website Polda tidak hanya dari arsitektur code dan arsitektur class, namun dari sisi arsitektur tampilan agar lebih menarik untuk masyarakat. Sehingga diharapkan kedepannya makin banyak masyarakat yang menggunakan website Polda Jabar.

2.8 Metode Pengukuran Kualitas Perangkat Lunak

Pengukuran kualitas perangkat lunak merupakan hal yang terpenting dari praktek rekayasa perangkat lunak yang baik. Pengukuran ini membantu untuk membuat karakteristik khusus dari proses dan produk informasi. Pengukuran meliputi evaluasi kuantitatif yang biasanya menggunakan metriks serta ukuran dapat menggunakan secara langsung menentukan pencapaian tujuan kualitas numerik. Pengukuran selalu menjadi fundamental bagi kemajuan untuk setiap disiplin rekayasa dan pengujian perangkat lunak. pengukuran perangkat lunak dan metrik menjadi peran mendasar dalam siklus hidup pengembangan perangkat lunak, dan Metriks perangkat lunak telah digunakan dalam membuat keputusan kuantitatif / kualitatif maupun dalam penilaian risiko dan pengurangan dalam proyek perangkat lunak. Proses pengukuran merupakan cara untuk melakukan pengukuran faktor kualitas dari sebuah perangkat lunak.

Pengukuran kualitas perangkat lunak website Polda Jabar akan menggunakan pehitungan OO Metriks untuk menghitung bagian internal program, karena OO metriks sesuai dengan website Polda Jabar yang berorientasi objek. Sedangkan untuk perhitungan ekstenal menggunakan metriks ISO 9126, Metriks 9216 ini melakukan perhitungan External dan Quality in use berdasarkan karakteristik dari 6 faktor yang ada pada model ISO 9126 [7][9]. Penghapusan kesalahan adalah Sebuah ukuran seberapa banyak cacat yang ditemukan selama review dihapus (dikoreksi) selama desain dan implementasi tahap. Metrik dapat dihitung dengan rumus X = A / B. dimana A adalah jumlah bug tetap selama desain dan coding dan B adalah Jumlah yang ditemukan selama review. Semakin dekat nilai adalah 1, yang lebih baik. A Nilai penghapusan kesalahan orang akan berarti bahwa setiap cacat terdeteksi telah dihapus. Metriks Eksternal ISO 9126 mempunyai beberapa metrik eksternal. Metriks eksternal didefinisikan dalam ISO 9126-2 dan diukur selama pengujian dinamis. Kategori metrik ini sesuai dengan yang internal yaitu maturity, fault tolerance, recoverability, and compliance. Metriks Kematangan mengukur kebebasan sistem perangkat lunak dari kegagalan disebabkan oleh bug di sistem itu sendiri.

26

2.9 Pengukuran

Pengukuran perangkat lunak adalah faktor utama untuk mengetahui seberapa baik perangkat lunak yang akan dinilai berdasarkan metode yang digunakan. Pengukuran perangkat lunak dilakukan dengan cara mencari nilai kriteria perangkat lunak tersebut dan juga mencari bobot kepentingan berdasarkan metode yang akan digunakan. Penilaian keseluruhan dapat diperoleh dari hasil nilai kriteria dan juga nilai bobot. Perhitungan bobot dan nilai kriteria bisa bervariasi tergantung dengan metode apa yang digunakan [10].

2.10 Metode Pembobotan

Rank Order Centroid (ROC) didasarkan pada tingkat kepentingan atau prioritas dari kriteria. Menurut Jeffreys dan Cockfield dalam Afiefah Rahma, teknik ROC memberikan bobot pada setiap kriteria sesuai dengan ranking yang dinilai berdasarkan tingkat prioritas. Biasanya dibentuk dengan pernyataan “Kriteria 1 lebih penting dari kriteria 2, yang lebih penting dari kriteria 3” dan seterusnya hingga kriteria ke n, ditulis . Untuk menentukan bobotnya, diberikan aturan yang sama yaitu dimana merupakan bobot untuk kriteria [10][13].

Atau dapat dijelaskan sebagai berikut: Jika

Cr1 ≥ Cr2 ≥ Cr3 ≥ ... ≥ Crn Maka

W1 ≥ W2 ≥ W3 ≥ ... ≥ Wn

Selanjutnya, jika k merupakan banyaknya kriteria, maka

Secara umum pembobotan ROC dapat dirumuskan sebagai berikut :

∑

2.11 Metode Pengolahan Kuesioner

Kuesioner merupakan sekumpulan pertanyaan yang diajukan kepada responden dengan tujuan dan maksud tertentu untuk memperoleh data, sehingga data tersebut dapat digunakan atau diolah kembali. Untuk mengolah data dari kuesioner tersebut dapat menggunakan berbagai macam metode pengolahan data sesuai dengan rumus metriks yang digunakan pada ISO 9126. Kuisioner ini diajukan untuk memenuhi nilai A, B maupun T yang dibutuhkan untuk menghitung nilai metriks dai setiap kriteria yang sudah ada. Dari hasil jawaban yang diberikan oleh responden akan dicari nilai rata rata, hasil jawaban responden akan dijumlahkan dan totalnya akan dibagi dengan jumlah responden. Maka akan didapat nilai A, B ataupun T.

2.12 Metode Penilaian

Perhitungan nilai sub faktor , faktor maupun nilai keseluruhan menjadi faktor penting untuk mengetahui hasil akhir sebuah nilai. menentukan nilai kriteria per faktor nya dan nilai akhir dengan rumus perhitungan Weight Summation. Nilai w adalah nilai metriks yang diperoleh dari hasil pengolahan kuisioner dan m adalah bobot dari sub faktor atau faktor yang sudah diperoleh dari hasil perhitungan dengan menggunakan metode Rank Order Centroid (ROC) [12].

1 Nilai kriteria

Kriteria ∑ ... =w1m1 + w2m2+…… wnmn

151

serta saran untuk perbaikan dan pengembangan penelitian lebih lanjut. 5.1 Kesimpulan

Berdasarkan hasil yang didapatkan dalam penelitian dan penyusunan skripsi ini serta disesuaikan dengan tujuan, maka diperoleh kesimpulan bahwa:

1. Pihak Polda mendapatkan nilai kualitas website.

2. Rekomendasi perbaikan yang diberikan adalah perbaikan nilai kualitas, arsitektur code dan arsitektur class agar website Polda dapat diakses lebih cepat dan mudah dalam pemeliharaannya.

3. Setelah mengolah kuesioner yang berkaitan dengan website Polda Jabar dari sisi penggunaan hasil yang didapatkan menunjukkan sudah mendapapatkan respon yang baik dari masyarakat.

5.2 Saran

Berdasarkan hasil dari perhitungan metriks dam pengolahan kuesioner, maka dapat diberikan saran yaitu perbaikan pada website Polda tidak hanya dari arsitektur code dan arsitektur class, namun dari sisi arsitektur tampilan agar lebih menarik untuk masyarakat. Sehingga diharapkan kedepannya makin banyak masyarakat yang menggunakan website Polda Jabar.