Implementasi Pengukuran Perangkat Lunak Dengan Menggunakan Metode Lines Of Code (LOC) Dan Function Point (FP)

IMPLEMENTASI PENGUKURAN KUALITAS PADA

PERANGKAT LUNAK DENGAN MENGGUNAKAN

METODE LINES OF CODE (LOC)

DAN FUNCTION POINT (FP)

SKRIPSI

AULIA ARFAN 041401045

PROGRAM STUDI S-1 ILMU KOMPUTER DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS SUMATERA UTARA

MEDAN 2010

IMPLEMENTASI PENGUKURAN KUALITAS PADA

PERANGKAT LUNAK DENGAN MENGGUNAKAN

METODE LINES OF CODE (LOC)

DAN FUNCTION POINT (FP)

SKRIPSI

Diajukan untuk melengkapi tugas dan memenuhi syarat mencapai gelar Sarjana Komputer

AULIA ARFAN 041401045

PROGRAM STUDI S-1 ILMU KOMPUTER DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS SUMATERA UTARA

MEDAN 2010

PERSETUJUAN

Judul : IMPLEMENTASI PENGUKURAN PERANGKAT

LUNAK DENGAN MENGGUNAKAN METODE

LINES OF CODE (LOC) DAN FUNCTION

POINT (FP)

Kategori : SKRIPSI

Nama : AULIA ARFAN

Nomor Induk Mahasiswa : 041401045

Program Studi : SARJANA (S1) ILMU KOMPUTER

Departemen : ILMU KOMPUTER

Fakultas : MATEMATIKA DAN ILMU PENGETAHUAN

ALAM (FMIPA) UNIVERSITAS SUMATERA UTARA

Diluluskan di Medan, Komisi Pembimbing :

Pembimbing 2 Pembimbing 1

Rahmat W. Sembiring, SE, MSc, IT Prof. Dr. Tulus, M.Si

NIP. 131 997 892 NIP. 196209011988031002

Diketahui/Disetujui oleh

Program Studi S1 Ilmu Komputer FMIPA USU Ketua,

Prof. Dr. Muhammad Zarlis NIP. 195707011986011003

PERNYATAAN

IMPLEMENTASI PENGUKURAN KUALITAS PADA PERANGKAT LUNAK DENGAN MENGGUNAKAN METODE LINES OF CODE (LOC) DAN

FUNCTION POINT (FP)

SKRIPSI

Saya mengakui bahwa skripsi ini adalah hasil kerja saya sendiri, kecuali beberapa kutipan dan ringkasan yang masing-masing disebutkan sumbernya.

Medan, Desember 2010

AULIA ARFAN 041401045

PENGHARGAAN

Segala puji dan syukur penulis panjatkan kepada Allah SWT yang Maha Pemurah dan Maha Penyayang, dengan limpahan karunia-Nya tugas akhir ini berhasil diselesaikan dalam waktu yang ditetapkan.

Selawat berangkaikan salam disampaikan kepada Rasulullah Muhammad SAW beserta sahabat dan keluarganya yang telah membawa inspirasi dan pencerahan bagi kehidupan umat manusia dan dunia.

Ucapan terima kasih penulis sampaikan kepada Bapak Dr. Tulus, M.Si dan Bapak Rahmat W. Sembiring, SE, MSc, IT. selaku pembimbing yang telah banyak memberikan panduan dan penuh kepercayaan kepada penulis untuk menyempurnakan kajian ini dan juga kepada Bapak Drs.James P. Marbun, M.Kom dan Bapak M. Andri Budiman, ST, MCompSc, MEM selaku pembanding. Panduan ringkas, padat dan profesional telah diberikan kepada penulis agar dapat menyelesaikan tugas ini. Ucapan terimakasih juga ditujukan kepada Ketua dan Sekretaris Departemen Ilmu Komputer Bapak Prof. Dr. Muhammad Zarlis dan Bapak Syahriol Sitorus, S.Si, M.I.T, Dekan dan Pembantu Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam Universitas Sumatera Utara, Semua dosen pada Departemen Ilmu Komputer FMIPA USU, pegawai di Ilmu Komputer FMIPA USU. Teristimewa kepada Ayahanda H. Risman Kusnandar dan Ibunda Hj. Najibah, S.Pd yang telah memberikan doa, dukungan, perhatian dan kasih sayang yang tulus serta pengorbanan yang tidak ternilai harganya semenjak penulis dilahirkan hingga menyelesaikan tugas akhir ini. Juga kepada kedua adik saya, Taufik Hendra, S.S.T dan Nurul Nofriza yang selalu meluangkan waktunya untuk membantu saya. Dan seluruh rekan-rekan kuliah angkatan ’04 khususnya Ismail Arif, Dhanny Pratama, Muhammad Arief Siregar, Foni Sanjaya, Ainul Hijriadi, Subhansyah Yushan, Ichsan Kurniawan, Rozi Putra dan Izhari Ishaq Aksa yang selalu memberikan semangat, dukungan dan bantuan terus menerus tanpa bosan dan pamrih. Terspesial juga kepada Azizah Mahary, dan Teguh Imanda Trg yang selalu mendorong penulis untuk terus mengerjakan skripsi hingga tuntas. Semoga Allah SWT memberikan limpahan karunia kepada semua pihak yang telah memberikan bantuan, perhatian, serta kerja samanya kepada penulis dalam menyelesaikan tugas akhir ini.

Akhirnya penulis berharap bahwa tugas akhir ini bermanfaat terutama kepada penulis maupun para pembaca serta semua pihak yang berhubungan dengannya. Penulis menyadari sepenuhnya bahwa kajian ini sangat jauh dari sempurna. Oleh karena itu kritik dan saran yang membangun sangat diharapkan demi perbaikan kedepannya.

ABSTRAK

Pengukuran perangkat lunak adalah jenis pengukuran apapun yang berkaitan dengan sistem perangkat lunak. Ukuran merupakan faktor utama untuk menentukan biaya, penjadwalan dan usaha. Kegagalan dari perkiraan ukuran yang tepat akan mengakibatkan penggunaan biaya yang berlebih atau keterlambatan penyelesaian proyek. Manfaat pengukuran adalah membandingkan antara perangkat lunak dan menghitung usaha yang dibutuhkan untuk membuat suatu perangkat lunak. Estimasi ukuran software merupakan suatu aktifitas yang komplek dan sukar berdasarkan pada beberapa alasan seperti kemampuan programmer, faktor lingkungan dan sebagainya. untuk mendapatkan estimasi dari software adalah dengan mengukur ukuran proyek menggunakan ukuran yaitu jumlah baris program (Lines of code/LOC) dan Function

Points. Lines of code adalah satuan pengukuran perangkat lunak berdasarkan jumlah

baris dalam naskah program (source code) dari suatu perangkat lunak. Sedangkan

Function Points adalah satuan pengukuran yang mendasarkan pada macam-macam

IMPLEMENTATION OF SOFTWARE QUALITY MEASUREMENT BY USING LINE OF CODE (LOC) AND FUNCTION POINT (FP) METHODES

ABSTRACT

Software measurement is a type of measurement associated to the software system. The measurement is the main factor which determine the cost, scheduling, and workload. The failure of the right estimation could cause excessive cost or over schedule of the project. The benefit of measurement is to comparing between software and to estimates the required to workload needed to make a software. Estimation of software measuremant is a complex and difficult activity based on several reasons such as the ability of programmers, environmental factors and so forth. To get the software estimation is by measuring the project using methods such as lines of codes (LOC) and function points. Lines of code is a unit of software measurement based on the number of lines in the source code of the software. While Function Points is the unit of measurement based on various functionalities which is contained in a software.

DAFTAR ISI

Halaman

PERSETUJUAN ii

PERNYATAAN iii

PENGHARGAAN iv

ABSTRAK v

ABSTRACT vi

DAFTAR ISI vii

DAFTAR GAMBAR ix

DAFTAR TABEL x

BAB 1 PENDAHULUAN

1.1 Latar Belakang 1

1.2 Rumusan Masalah 2

1.3 Batasan Masalah 2

1.4 Tujuan Penelitian 3

1.5 Manfaat Penelitian 3

1.6 Tinjauan Pustaka 3

1.7 Metode Penelitian 6 BAB 2 LANDASAN TEORI

2.1 Pengukuran 7 2.1.1 Definisi Pengukuran 7 2.1.2 Metrik Perangkat Lunak 7 2.2 Metrik dalam Proses dan Domain Proyek 8

2.2.1 Metrik Proses dan Peningkatan Perangkat Lunak 9

2.2.2 Metrik Proyek 11

2.3 Mengimplementasikan Metrik Pada Perangkat Lunak 12 2.3.1 Pengukuran yang Berhubungan dengan Ukuran 13 2.3.2 Pengukuran yang Berhubungan dengan Function Point 14 2.4 Estimasi Proyek Perangkat Lunak 17

2.4.1 Estimasi Berbasis Masalah 17 2.5 Model Estimasi Empiris 18

2.5.1 Struktur Model-Model Estimasi 18

2.5.2 Model COCOMO 19

2.5.3 Persamaan pada Perangkat Lunak 21

BAB 3 DESAIN SISTEM

3.1 Deskripsi 23

3.2 Spesifikasi Keperluan Perangkat Lunak 23 3.3 Sistem Informasi Organisasi BKM Al Khuwarizmi 24

3.3.1 Usulan Sistem 24

3.3.2 Lingkungan Perangkat Lunak 24

3.3.3 Spesifikasi Keperluan Fungsional 24 3.3.4 Spesifikasi Desain Perangkat Lunak 26

3.4 Sistem Informasi Perpustakaan SMA Negeri 2 Binjai 33

3.4.1 Usulan Sistem 33

3.4.2 Lingkungan Perangkat Lunak 33

3.4.3 Spesifikasi Keperluan Fungsional 34 3.4.4 Spesifikasi Desain Perangkat Lunak 34 BAB 4 IMPLEMENTASI BERDASARKAN TEORI

4.1 Estimasi Perangkat Lunak 38

4.2 Implementasi Berdasarkan Teori 39

4.2.1 Estimasi Berbasis LOC 39

4.2.2 Analisis LOC 41

4.2.3 Estimasi Berbasis FP 43

4.2.4 Model Estimasi Empiris 46

4.2.5 Hasil Pengamatan Lapangan 50

4.3 Perbandingan Hasil Estimasi 50

BAB 5 KESIMPULAN DAN SARAN

5.1 Kesimpulan 53

5.2 Saran 53

DAFTAR GAMBAR

Halaman

Gambar 1.1 Pengukuran kontrol dan prediktor 4

Gambar 3.1 DFD level 0 Sistem Informasi Manajemen Organisasi BKM

Al Khuwarizmi 27

Gambar 3.2 DFD level 1 Sistem Informasi Manajemen Organisasi BKM

Al Khuwarizmi 28

Gambar 3.3 Perancangan antarmuka modul 29

Gambar 3.4 Rancangan antarmuka tampilan data 30

Gambar 3.5 Rancangan antarmuka pengisian data 31

Gambar 3.6 DFD level 0 Sistem Informasi Perpustakaan SMAN 2 Binjai 35

Gambar 3.7 Rancangan antarmuka modul 36

DAFTAR TABEL

Halaman

Tabel 2.1 Blanko penghitungan CFP 15

Tabel 2.2 Blanko penghitungan RCAF 16

Tabel 2.3 Model COCOMO dasar 20

Tabel 3.1 Spesifikasi Proses Diagram Konteks Level 0 27

Tabel 3.2 Spesifikasi Proses DFD Level 1 28

Tabel 4.1 Analisa LOC Sistem Informasi Organisasi BKM Al Khuwarizmi 40 Tabel 4.2 Analisa LOC Sistem Informasi SMA Negeri 2 Binjai 41

Tabel 4.3 Perhitungan Estimasi FP 43

Tabel 4.4 Perhitungan faktor peubah kompleksitas 43 Tabel 4.5 Perhitungan Estimasi FP Sistem Informasi SMA Negeri 2 Binjai 45 Tabel 4.6 Perhitungan faktor peubah kompleksitas 45

ABSTRAK

Pengukuran perangkat lunak adalah jenis pengukuran apapun yang berkaitan dengan sistem perangkat lunak. Ukuran merupakan faktor utama untuk menentukan biaya, penjadwalan dan usaha. Kegagalan dari perkiraan ukuran yang tepat akan mengakibatkan penggunaan biaya yang berlebih atau keterlambatan penyelesaian proyek. Manfaat pengukuran adalah membandingkan antara perangkat lunak dan menghitung usaha yang dibutuhkan untuk membuat suatu perangkat lunak. Estimasi ukuran software merupakan suatu aktifitas yang komplek dan sukar berdasarkan pada beberapa alasan seperti kemampuan programmer, faktor lingkungan dan sebagainya. untuk mendapatkan estimasi dari software adalah dengan mengukur ukuran proyek menggunakan ukuran yaitu jumlah baris program (Lines of code/LOC) dan Function

Points. Lines of code adalah satuan pengukuran perangkat lunak berdasarkan jumlah

baris dalam naskah program (source code) dari suatu perangkat lunak. Sedangkan

Function Points adalah satuan pengukuran yang mendasarkan pada macam-macam

IMPLEMENTATION OF SOFTWARE QUALITY MEASUREMENT BY USING LINE OF CODE (LOC) AND FUNCTION POINT (FP) METHODES

ABSTRACT

Software measurement is a type of measurement associated to the software system. The measurement is the main factor which determine the cost, scheduling, and workload. The failure of the right estimation could cause excessive cost or over schedule of the project. The benefit of measurement is to comparing between software and to estimates the required to workload needed to make a software. Estimation of software measuremant is a complex and difficult activity based on several reasons such as the ability of programmers, environmental factors and so forth. To get the software estimation is by measuring the project using methods such as lines of codes (LOC) and function points. Lines of code is a unit of software measurement based on the number of lines in the source code of the software. While Function Points is the unit of measurement based on various functionalities which is contained in a software.

PENDAHULUAN

1.1Latar Belakang

Pengukuran merupakan dasar dari setiap disiplin rekayasa dan berlaku juga dalam perekayasaan perangkat lunak. Untuk mengevaluasi performa suatu sistem atau proses diperlukan suatu mekanisme untuk mengamati dan menentukan tingkat efisiensinya. Melalui pengukuran, maka akan diperoleh tingkat pencapaian di dalam proyek perangkat lunak yang sedang diamati. Untuk setiap pengukuran yang dilakukan dibutuhkan tersedianya suatu ukuran kuantitatif yang disebut metrik. Metrik berdasarkan istilah rekayasa perangkat lunak didefinisikan sebagai sebuah ukuran kuantitatif yang dimiliki oleh suatu sistem, komponen atau proses tertentu dengan

attribute-atribute yang diberikan. Ukuran merupakan faktor utama untuk menentukan

biaya, penjadwalan, dan usaha. Kegagalan dari perkiraan ukuran yang tepat akan mengakibatkan penggunaan biaya yang berlebih atau keterlambatan penyelesaian proyek.

Menurut IEEE Standard Glossary of Software Engineering Technology, kualitas (quality) adalah ” the degree to which a system, component, or process meets

customer or user needs or expectation”. Ini berarti pengukuran kualitas suatu

perangkat lunak dapat dilihat dari sudut pengembangan perangkat lunak (process) dan produk yang dihasilkan (product) dengan orientasi akhir adalah pengembangan perangkat lunak yang sesuai dengan kebutuhan pengguna (user). Dilihat dari pemahaman di atas maka untuk proses pengukuran perangkat lunak dibagi atas dua, yaitu pengukuran kualitas perangkat lunak yang digunakan pada proses pengembangan perangkat lunak dan pada produk perangkat lunak.

Pengukuran kualitas pada proses perangkat lunak berhubungan dengan tenaga dan pikiran yang diperlukan untuk menyelesaikan proyek perangkat lunak, waktu

yang dibutuhkan untuk penyelesaian proses tertentu dan banyak sumber daya yang berpartisipasi. Pada sisi produk yang ingin diketahui seperti jumlah baris kode, tingkat kerumitan, fungsionalitas yang dipenuhi, jumlah kesalahan yang terjadi, jumlah ujicoba yang dilakukan dan lain sebagainya. Pada sisi lainnya, bagaimana reliabilitas dari produk perangkat lunak dapat diukur setelah diterima oleh user.

Hingga saat ini para ahli rekayasa perangkat lunak sebenarnya belum berhasil dan memiliki kesepakatan bersama mengenai metodologi pengukuran kualitas perangkat lunak yang dapat diterima secara universal. Penggunaan berbagai macam metode pengukuran perangkat lunak untuk atribut-atribut yang berbeda dalam suatu perangkat lunak memang menimbulkan kontroversi yang beragam sebagai akibat keragaman hasil akhir pengukuran. Tetapi hal itu dapat menjadi tolak ukur untuk membandingkan aktifitas dan fakta di lapangan baik dari segi proses, hasil dan kepuasan user dengan metode yang penulis terapkan sehingga akan didapat metode manakah yang dapat memberikan pertimbangan bagi pelaksana proyek untuk mengembangkan proyek perangkat lunaknya ke depan. Oleh karena itu, penulis mengambil pokok pembahasan mengenai pengukuran kualitas perangkat lunak dengan menggunakan metode Lines of Code dan Function Point sebagai tema pembahasan karya ilmiah (skripsi) tugas akhir.

1.2 Rumusan Masalah

Rumusan masalah pada tugas akhir ini adalah jika pengukuran kualitas perangkat lunak diukur dari prosesnya, maka metode dan teori apakah yang sesuai digunakan untuk melakukan pengukuran tersebut ?

1.3Batasan Masalah

Dalam tugas akhir ini hanya membatasi pada beberapa bagian masalah yaitu:

a. Implementasi pengukuran pada perangkat lunak dengan menggunakan teori LOC dan Function Point (FP).

b. Pengukuran digunakan untuk mengukur estimasi tenaga kerja dan waktu yang dibutuhkan untuk menyelesaikan proyek perangkat lunak.

1.4Tujuan Penelitian

Penulisan tugas akhir ini bertujuan:

a. Mengimplementasikan metode pengukuran perangkat lunak LOC dan Funtion

Point berdasarkan teori yang ada pada proyek pengembangan perangkat lunak

yang nyata.

b. Mengenalkan penggunaan metode LOC dan Function Point sebagai metode pengukuran kualitas perangkat lunak yang umum digunakan namun jarang dibahas dalam pembahasan rekayasa perangkat lunak.

1.5Manfaat Penelitian

Adapun manfaat peneltian ini adalah

a. Penulisan tugas akhir ini bermanfaat untuk mengukur kualitas suatu perangkat lunak pada saat pengembangannya apakah sesuai antara fakta di lapangan dengan metode yang digunakan untuk mengukurnya.

b. Memperkaya literatur pada ilmu rekayasa perangkat lunak mengenai pentingnya suatu pengukuran pada perangkat lunak.

1.6Tinjauan Pustaka

Pengukuran (metric) menurut IEEE adalah ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen atau proses memiliki atribut tertentu. Sedangkan mengukur (measure) adalah mengindikasikan kuantitatif dari luasan, jumlah, dimensi dan kapasitas.

Kualitas (quality) menurut IEEE Standard Glossary of Software Engineering

Technology adalah ”the degree to which a system, component, or process meets customer or user needs or expectation” atau derajat pada suatu sistem, komponen atau

proses pertemuan persyaratan yang ditetapkan dan kebutuhan pengguna atau harapan. Oleh karena itu, definisi dari kualitas produk harus didasarkan kepada kelengkapan kualitas yang terukur yang memberikan kepuasan pada pengguna program sesuai

dengan kebutuhan yang ditetapkan. Karena persyaratan-persyaratan yang berbeda antar program-program, kualitas kelengkapan juga akan berubah.

Rekayasa perangkat lunak adalah suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal requirement capturing (analisa kebutuhan pengguna), specification (menentukan spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai pemeliharaan sistem setelah digunakan ( Wahono, Romi Satria , SDA Magazine). Sedangkan dalam IEEE standard 610.12 didefinisikan ”The application of a systematic, disciplined, quantifiable approach to

the development, operation and maintenance of software; that is, the application of engineering to software”. Menilik dari definisi di atas maka rekayasa perangkat lunak

tidak hanya berhubungan dengan masalah teknis pengembangan perangkat lunak tetapi juga kegiatan strategis seperti manajemen proyek perangkat lunak, penentuan metode, proses pengembangan, dokumentasi, aspek teoritis dan konfigurasi data yang berhubungan yang mendukung terjadinya produksi perangkat lunak.

Metrik (pengukuran) perangkat lunak adalah jenis pengukuran apapun yang berhubungan dengan sistem perangkat lunak, proses dan dokumentasi terkait. Menurut Sommerville, pengukuran terbagi atas dua, yaitu pengukuran (metrik) kontrol dan pengukuran prediktor. Pengukuran kontrol berkaitan dengan proses perangkat lunak sedangkan pengukuran prediktor berkaitan dengan produk perangkat lunak.

Gambar 1.1 Pengukuran kontrol dan predik

Pengukuran kontrol Proses Perangkat

lunak

Keputusan Manajemen

Pengukuran Prediktor

Produk Perangkat

Karena faktor terjadinya berbagai perbedaan proses pengukuran maka perlu normalisasi pada proses pengukuran. Normalisasi dilakukan untuk membandingkan pengukuran pada cakupan yang lebih luas dengan mengevaluasi proses dan produknya. Ada dua proses normalisasi yang cukup dikenal, yaitu:

a. Metric Size Oriented (pengukuran yang berorientasi pada ukuran/size)

b. Metrik Function Oriented (pengukuran yang berorientasi pada fungsi). 1.6.1 Metric Size Oriented

Metric size oriented adalah pengukuran dengan normalisasi kualitas dan

produktifitas atau mempertimbangkan ukuran perangkat lunak yang dihasilkan. Metric

size oriented dilakukan dengan menghitung LOC (Line of Code) dari baris kode suatu

perangkat lunak. Pada pengembangan, pengukuran ini juga dapat mengukur: a. Kesalahan per KLOC (Kilo Line Of Code)

b. Biaya per LOC c. Cacat per LOC

d. Halaman dokumentasi per LOC e. Kesalahan perorang perbulan f. LOC perorang perbulan

g. Biaya perhalaman dokumentasi.

1.6.2 Metric Function Oriented

Metrik yang berhubungan dengan fungsi ( Metric Function Oriented) adalah pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi. Perhitungan dengan metode Function Point menuntut untuk dilakukan oleh seorang profesional yang berpengalaman karena memiliki tingkat subyektifitas yang cukup tinggi. Metrik berorientasi fungsi diusulkan oleh Albrecth pada tahun 1979, yang menyarankan pengukuran yang disebut Function Point. Function Point tidak bergantung pada bahasa sehingga produktivitas pada bahasa pemrograman yang berbeda dapat dibandingkan. Produktivitas dinyatakan sebagai poin fungsi yang dihasilkan per orang-bulan. Function point di-bias menuju system pemrosesan data

yang didominasi oleh operasi input dan output. Metode ini sendiri terdiri dari banyak varia. Variasi yang adalah pada langkah/tahapan yang ada maupun pada isi dari tiap tahapan. Varian-varian ini timbul karena metode ini dapat diubah sesuai dengan kebijakan perusahaan pengembang software. Namun apapun varian yang digunakan oleh pengembang, hendaknya digunakan dengan konsisten agar tercipta komparasi yang benar antara software-software yang dinilai.

Metode dalam metric ini berdasarkan publikasi varian yang populer seperti Gramus dan Herron, IEEE, Caldiera (Pressman,2001) yang menghasilkan manual penggunaan function point seperti IFPUG 3, IFPUG 4 dan Mark II.

1.7Metode Penelitian

Metode yang dilakukan dalam Tugas Akhir ada beberapa yaitu: a. Studi Literatur

Mempelajari buku referensi atau sumber – sumber yang berkaitan dengan Rekayasa Perangkat Lunak dan metode tentang pengkuran kualitas pada perangkat lunak

b. Analisis Data

Menganalisis teori dan metodologi serta teknik yang digunakan untuk melakukan pengukuran kualitas pada perangkat lunak.

c. Perancangan Sistem

Merancang proyek perangkat lunak yang akan digunakan sebagai bahan

implementasi teori dan metodologi yang digunakan . Perangkat Lunak yang akan dibangun menggunakan Bahasa pemrograman Borland Delphi 7.0

d. Implementasi Teori dan Metodologi

Mengimplementasikan teori dan metodologi pengukuran kualitas perangkat lunak ke dalam proyek perangkat lunak yang telah jadi.

e. Pembuatan Laporan

BAB 2

LANDASAN TEORI

2.1 Pengukuran

2.1.1 Definisi Pengukuran

Pengukuran merupakan dasar dari setiap disiplin rekayasa dan berlaku juga dalam perekayasaan perangkat lunak. Untuk mengevaluasi performa suatu system atau proses diperlukan suatu mekanisme untuk mengamati dan menentukan tingkat efisiensinya. Melalui pengukuran, maka akan diperoleh tingkat pencapaian di dalam proyek perangkat lunak yang sedang diamati.

Pengukuran menurut IEEE adalah ukuran kuantitatif dari tingkat dimana sebuah system, komponen atau proses memiliki atribut tertentu. Sedangkan mengukur (measure) adalah mengindikasikan kuantitatif dari luasan, jumlah, dimensi dan kapasitas. ( IEEE Std 610.12-1990, 1990)

Untuk setiap pengukuran yang dilakukan dibutuhkan tersedianya suatu ukuran kuantitatif yang disebut metrik. Istilah ukuran, pengukuran dan metrik sering digunakan secara bergantian. Metrik berdasarkan istilah rekayasa perangkat lunak didefinisikan sebagai sebuah ukuran kuantitatif yang dimiliki oleh suatu system, komponen atau proses tertentu dengan attribute-atribute yang diberikan. Oleh karena itu, untuk selanjutnya akan digunakan istilah metrik untuk menyebutkan pengukuran dalam pengukuran perangkat lunak

2.1.2 Metrik Perangkat Lunak

Ukuran merupakan faktor utama untuk menentukan biaya, penjadwalan, dan usaha. Kegagalan dari perkiraan ukuran yang tepat akan mengakibatkan penggunaan biaya yang berlebih atau keterlambatan penyelesaian proyek.

Menurut Sommerville (2003), pengukuran terbagi atas dua, yaitu pengukuran (metrik) kontrol dan pengukuran (metrik) prediktor. Metrik kontrol biasanya dihubungkan dengan proses perangkat lunak, misalnya usaha dan waktu rata-rata yang dibutuhkan untuk memperbaiki cacat yang dilaporkan. Sedangkan metrik prediktor berhubungan dengan produk perangkat lunak, misalnya kompleksitas sikomatik modul, panjang rata-rata identifier pada program dan jumlah atribut dan operasi yang berhubungan dengan objek pada suatu rancangan.

Metrik juga dapat dipisahkan dalam dua kategori, yaitu metrik langsung dan metrik tidak langsung. Metrik langsung dalam proses rekayasa perangkat lunak berhubungan dengan biaya dan sumber daya yang diperlukan, misalnya: pengukuran jumlah baris kode, kecepatan eksekusi, ukuran memori, dan kesalahan yang ditemui dalam suatu periode waktu. Metrik tidak langsung dari suatu produk berhubungan dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, dan lain sebagainya. Pengukuran secara langsung lebih mudah dilakukan, karena hasil dapat diperoleh secara langsung, sedangkan pengukuran tidak langsung lebih sulit dilakukan, karena harus melalui proses yang lebih kompleks.

Metrik dipisahkan menjadi metrik proses, proyek, dan produk. Metrik produk bersifat privat untuk individu dan sering dikombinasikan untuk membuat metrik proyek yang bersifat publik bagi tim pengembang. Metrik proyek kemudian dikonsolidasikan untuk membuat metrik proses yang publik untuk seluruh organisasi atau perusahaan. Kesulitan yang biasanya dihadapi adalah pada saat melakukan kombinasi pada metrik-metrik yang diukur disebabkan karena sering terjadi perbedaan metrik antara individu satu dengan individu lainnya. Masalah tersebut biasa diatasi apabila dilakukan normalisasi pada proses pengukuran. Dengan adanya normalisasi maka dapat dilakukan perbandingan metrik pada cakupan yang lebih luas.

2.2 Metrik Dalam Proses dan Domain Proyek

Metrik harus dikumpulkan sehingga indikator proses dan produk dapat dipastikan. Indikator proses memungkinkan sebuah organisasi rekayasa perangkat lunak memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung

(misalnya paradigma, tugas-tugas rekayasa perangkat lunak, produk kerja, dan kejadian penting). Indikator proses memungkinkan manajer dan pelaksana memperkirakan apa yang harus dikerjakan dan yang tidak.

Indikator proyek memungkinkan manajer proyek perangkat lunak : a. Memperkirakan status sebuah proyek yang sedang berlangsung b. Menelusuri risiko-risiko potensial

c. Menemukan area masalah sebelum masalah ”menjadi semakin kritis” d. Menyesuaikan aliran kerja atau tugas-tugas; dan

e. Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja rekayasa perangkat lunak

2.2.1 Metrik Proses dan Peningkatan Perangkat Lunak

Satu-satunya cara yang paling rasional untuk meningkatkan proses adalah dengan mengukur atribut tertentu dari proses, mengembangkan serangkaian metrik yang berarti berdasarkan atribut-atribut tersebut, dan kemudian menggunakan metrik itu untuk memberikan indikator yang akan membawa kepada sebuah strategi pengembangan.

Keterampilan dan motivasi yang diperlihatkan oleh manusia merupakan satu-satunya faktor yang paling berpengaruh pada kualitas dan unjuk kerja tim. Kita mengukur reliabilitas proses perangkat lunak secara tidak langsung yaitu dengan mengambil serangkaian metrik berdasarkan keluaran yang dapat diambil oleh proses. Keluaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan perangkat lunak, cacat yang disampaikan dan dilaporkan oleh pemakai akhir, produk kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan, konfirmasi jadwal, serta pengukuran yang lain.

Menurut Sommerville, ada tiga kelas metrik proses:

a. Waktu yang dibutuhkan untuk penyelesaian proses tertentu. Bisa merupakan waktu total yang dicurahkan untuk proses, waktu kalender, waktu yang dihabiskan pada proses oleh insinyur tertentu dan sebagainya.

b. Sumber daya yang dibutuhkan untuk suatu proses tertentu. Sumber Daya bisa berupa usaha dalam orang-hari, biaya perjalanan, sumber daya komputer, dan lain-lain.

c. Jumlah terjadinya even tertentu. Contoh event yang dapat dipantau mencakup jumlah cacat yang ditemukan pada saat inspeksi kode, jumlah perubahan persyaratan yang diminta, jumlah rata-rata baris kode yang dimodifikasi sebagai tanggapan terhadap perubahan persyaratan dan lain-lain

Grady menyatakan bahwa ”etika metrik perangkat lunak” merupakan hal yang tepat bagi para manajer ketika mereka melembagakan program metrik proses:

a. Gunakan istilah umum dan kepekaan organisasi ketika menginterpretasi data metrik.

b. Berikan umpan balik reguler kepada individu dan tim yang telah bekerja untuk mengumpulkan pengukuran dan metrik.

c. Jangan menggunakan metrik untuk menilai individu

d. Bekerja dengan pelaksana dan tim untuk menentukan tujuan dan metrik yang jelas yang akan dipakai untuk mencapainya.

e. Jangan pernah menggunakan metrik untuk mengancam individu dan tim.

f. Metrik data yang menunjukkan sebuah area masalah tidak boleh “dianggap negative.” Data-data itu hanya merupakan sebuah indicator bagi peningkatan proses.

g. Jangan tergoda pada sebuah metrik dan kemudian mengabaikan metrik penting yang lain.

Pada dasarnya statistical software process improvement (SSPI) menggunakan analisis kegagalan perangkat lunak untuk mengumpulkan informasi seputar semua kesalahan dan cacat yang terjadi pada saat sebuah aplikasi, sistem, atau produk dikembangkan dan dipakai. Analisis kegagalan bekerja dengan cara sebagai berikut :

a. Semua kesalahan dan cacat dikategorikan dari awal (contohnya, kekurangan dalam spesifikasi, kekurangan dalam logika, ketidaksesuaian dengan standar).

b. Biaya untuk mengkoreksi setiap kesalahan dan cacat dicatat.

c. Jumlah kesalahan dan cacat dari setiap kategori dihitung dan ditata dalam urutan naik.

d. Biaya keseluruhan dari kesalahan dan cacat dari setiap kategori dihitung. e. Data resultan dianalisis untuk menemukan kategori yang menelan biaya besar. f. Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi

(mengurangi frekuensi kejadian) kelas kesalahan dan cacat yang paling membutuhkan banyak biaya.

2.2.2 Metrik Proyek

Metrik yang dikumpulkan dari proyek terdahulu digunakan sebagai dasar yang dari sana perkiraan usaha dan durasi waktu dibuat untuk kerja perangkat lunak saat ini. Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yang digunakan dibandingkan dengan perkiraan awal (dan jadwal proyek).

Nilai produksi yang disajikan dalam bentuk halaman dokumentasi, jam kajian, titik-titik fungsi, dan deretan sumber yang disampaikan diukur serta kesalahan yang ditemukan selama masing-masing tugas kerja rekayasa perangkat lunak kemudian ditelusuri.

Metrik proyek mempunyai tujuan ganda. Pertama, metrik tersebut digunakan untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang diperlukan untuk menghindar penundaan serta mengurangi masalah dan risiko potensial. Kedua, metrik proyek dipakai untuk memperkirakan kualitas produk pada basis yang berlaku dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas.

Model lain dari metrik proyek mengusulkan bahwa setiap proyek seharusnya mengukur :

a. input (pengukuran sumber daya seperti manusia, lingkungan yang dibutuhkan untuk melakukan pekerjaan).

b. Output (pengukuran kemampuan penyampaian atau produk kerja yang diciptakan selama proses rekayasa perangkat lunak).

c. Hasil (pengukuran yang menunjukkan efektivitas kemampuan penyampaian).

.

2.3 Mengimplementasikan Metrik pada Perangkat Lunak

Implementasi metrik pada perangkat lunak berkaitan erat dengan estimasi usaha dan biaya kegiatan proyek perangkat lunak. Produktivitas pada sistem dapat diukur dengan menghitung jumlah satuan yang dihasilkan dan membagi nilai ini dengan jumlah orang-jam yang dibutuhkan untuk menghasilkannya. Estimasi produktivitas biasanya berdasar atas pengukuran beberapa atribut perangkat lunak dan membaginya dengan usaha total yang dibutuhkan untuk pengembangan. Ada dua jenis pengukuran yang telah dipakai:

a. Metrik yang berhubungan dengan ukuran.

Pengukuran ini berhubungan dengan ukuran output dari suatu kegiatan. Pengukuran yang berhubungan dengan ukuran yang paling umum adalah jumlah baris kode sumber yang diserahkan. Pengukuran lain yang dapat digunakan adalah jumlah instruksi kode objek yang diserahkan atau jumlah halaman dokumentasi sistem.

b. Metrik yang berhubungan dengan fungsi.

Pengukuran ini berhubungan dengan fungsionalitas menyeluruh dari perangkat lunak yang diserahkan. Produktivitas dinyatakan dalam jumlah fungsionalitas yang berguna dalam waktu tertentu. Poin fungsi dan poin objek merupakan pengukuran yang paling dikenal dari jenis ini.

Estimasi ukuran software merupakan suatu aktifitas yang komplek dan sukar berdasarkan pada beberapa alas an seperti kemampuan programmer, faktor lingkungan dan sebagainya. Tetapi karena tindakan ini harus dilakukan dan untuk mendapatkannya dengan mengukur ukuran proyek menggunakan ukuran seperti jumlah baris program (Source lines of code/SLOC) dan Function Points.

2.3.1 Pengukuran Yang Berhubungan Dengan Ukuran

Pegukuran yang berhubungan dengan ukuran (Metric Size Oriented) adalah pengukuran dengan normalisasi kualitas dan produktifitas atau mempertimbangkan ukuran perangkat lunak yang dihasilkan. Metric size oriented dilakukan dengan menghitung LOC (Line of Code) dari baris kode suatu perangkat lunak. Pada pengembangan, pengukuran ini juga dapat mengukur:

h. Kesalahan per KLOC (Kilo Line Of Code) i. Biaya per LOC

j. Cacat per LOC

k. Halaman dokumentasi per LOC l. Kesalahan perorang perbulan m. LOC perorang perbulan

n. Biaya perhalaman dokumentasi.

Menurut Jones (Pressman,2001) LOC merupakan ukuran yang kurang akurat dan merupakan sebuah topik yang menimbulkan perdebatan selama bertahun-tahun, dipandang sebagai sebuah ukuran untuk mengestimasi biaya dan waktu, tidak dapat dipastikan bahwa dua program yang mempunyai LOC sama akan membutuhkan waktu implementasi yang sama walaupun keduanya diimplementasikan dengan kondisi pemrograman yang standard. Meskipun metode ini kurang akurat dan merupakan metodologi yang belum diterima secara luas, tetapi metrik dengan orientasi ukuran ini merupakan kunci pengukuran dan banyak estimasi software yang menggunakan model ini.

Secara virtual tidak mungkin untuk menghitung LOC dari dokumen requirement awal. LOC pengukurannya didasarkan pada bahasa pemrograman tertentu, oleh karena itu muncul banyak masalah dalam membuat standard pengukuran dengan teknik LOC. Ukuran lain yang ada untuk mengukur besaran software adalah

ukuran yang berorientasi fungsi dan ukuran yang berorientasi object. Metode ini merupakan metode yang lebih konsisten dan diterima secara luas.

2.3.2 Pengukuran yang Berhubungan dengan Function Point

Pengukuran yang berhubungan dengan fungsi (Metric Function Oriented) adalah pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai normalisasi. Perhitungan dengan metode Function Point menuntut untuk dilakukan oleh seorang profesional yang berpengalaman karena memiliki tingkat subyektifitas yang cukup tinggi. Metrik berorientasi fungsi diusulkan oleh Albrecth pada tahun 1979, yang menyarankan pengukuran yang disebut Function Point. Function Point tidak bergantung pada bahasa sehingga produktivitas pada bahasa pemrograman yang berbeda dapat dibandingkan. Produktivitas dinyatakan sebagai poin fungsi yang dihasilkan per orang-bulan. Function Point di-bias menuju system pemrosesan data yang didominasi oleh operasi input dan output. Metode ini sendiri terdiri dari banyak varia. Variasi yang adalah pada langkah/tahapan yang ada maupun pada isi dari tiap tahapan. Varian-varian ini timbul karena metode ini dapat diubah sesuai dengan kebijakan perusahaan pengembang software. Namun apapun varian yang digunakan oleh pengembang, hendaknya digunakan dengan konsisten agar tercipta komparasi yang benar antara software-software yang dinilai.

Metode dalam metrik ini berdasarkan publikasi varian yang populer seperti Gramus dan Herron, IEEE, Caldiera (Pressman, 2001) yang menghasilkan manual penggunaan function point seperi IFPUG 3, IFPUG 4 dan Mark II. Tahapan-tahapan yang ada dalam menentukan function point adalah sebagai berikut :

Langkah 1 : Menghitung crude function points (CFP)

Jumlah dari komponen fungsional sistem pertama kali diidentifikasi dan dilanjutkan dengan mengevaluasi kuantitasi bobot kerumitan dari tiap komponen tersebut. Pembobotan tersebut kemudian dijumlahkan dan menjadi angka CFP.

Perhitungan CFP melibatkan 5 tipe komponen sistem software berikut : a. Jumlah macam aplikasi input (user inputs)

c. Jumlah macam aplikasi query online – aplikasi ini berhubungan dengan query terhadap data yang tersimpan (Inquiry)

d. Jumlah macam file/tabel logic yang terlibat

e. Jumlah macam interface eksternal – output atau input yang dapat berhubungan dengan komputer lewat komunikasi data, CD, disket, dan lain-lain.

Kemudian diberikan faktor bobot pada tiap komponen di atas berdasarkan kompleksitasnya. Tabel 2.1 di bawah ini merupakan contoh blanko pembobotan tersebut.

Tabel 2.1 Blanko penghitungan CFP

Komponen Sistem Software

Level kompleksitas Total

CFP

Sederhana Menengah Kompleks

Count Faktor Bobot

Point Count Faktor Bobot

Point Count Faktor Bobot

Point

A B C=

AxB

D E F=

DxE

G H I=

GxH

J=C+F+I

Input 3 4 6

Output 4 5 7

Query Online

3 4 6

File logic 7 10 15

Interface Eksternal

5 7 10

Total CFP

Langkah 2 : Menghitung faktor pengubah kompleksitas relatif/Relative

Complexity Adjustment Factor (RCAF).

RCAF berfungsi untuk menghitung kesimpulan kompleksitas dari sistem software dari beberapa subyek karakteristik. Penilaian berskala 0 sampai 5 diberikan pada tiap subyek yang paling berpengaruh terhadap usaha pengembangan yang dibutuhkan. Blanko penilaian yang diusulkan penulis diberikan seperti Tabel 2.2

Tabel 2.2 Blanko penghitungan RCAF

No Subyek Nilai

1 Tingkat kompleksitas kehandalan backup/recovery 0 1 2 3 4 5 2 Tingkat kompleksitas komunikasi data 0 1 2 3 4 5 3 Tingkat kompleksitas pemrosesan terdistribusi 0 1 2 3 4 5

4 Tingkat kompleksitas kebutuhan akan kinerja 0 1 2 3 4 5 5 Tingkat kebutuhan lingkungan operasional 0 1 2 3 4 5 6 Tingkat kebutuhan knowledge pengembang 0 1 2 3 4 5 7 Tingkat kompleksitas updating file master 0 1 2 3 4 5

8 Tingkat kompleksitas instalasi 0 1 2 3 4 5

9 Tingkat kompleksitas aplikasi input, output, query online dan file 0 1 2 3 4 5 10 Tingkat kompleksitas pemrosesan data 0 1 2 3 4 5 11 Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse) 0 1 2 3 4 5 12 Tingkat variasi organisasi pelanggan 0 1 2 3 4 5 13 Tingkat kemungkinan perubahan/fleksibilitas 0 1 2 3 4 5 14 Tingkat kebutuhan kemudahan penggunaan 0 1 2 3 4 5

Total = RCAF

Langkah 3 : Menghitung Function Point (FP)

Nilai function point untuk sistem software tersebut kemudian dihitung berdasarkan hasil dari tahap 1 dan 2 yang dimasukkan ke dalam formula

FP = CFP x (0.65 + 0.01 x RCAF) (2.1)

2.4 Estimasi Proyek Perangkat Lunak

Estimasi biaya dan tenaga sukar untuk menjadi sebuah ilmu pasti. Banyak faktor seperti manusia, teknis, lingkungan, atau politik, yang dapat mempengaruhi besarnya biaya dan tenaga yang diperlukan untuk mengembangkan perangkat lunak. Bagaimanapun juga, estimasi proyek perangkat lunak dapat ditransformasikan dari sesuatu yang abstrak menjadi suatu urutan langkah langkah sistematis yang menghasilkan perkiraan-perkiraan dengan tingkat resiko yang dapat diterima.

Ada beberapa cara yang dapat digunakan untuk melakukan perkiraan proyek: 1. Perkiraan keterlambatan suatu proyek dapat diselesaikan

3. Menggunakan teknik dekomposisi sederhana untuk membuat suatu kisaran biaya dan tenaga

4. Menggunakan satu atau lebih model empiris untuk perkiraan biaya dan tenaga Teknik yang disarankan oleh para ahli di bidang perangkat lunak adalah dengan menggunakan kombinasi antara teknik dekomposisi dan model empiris. Teknik dekomposisi menggunakan pendekatan dengan cara membagi suatu proyek ke dalam beberapa fungsi mayor yang berhubungan dengan aktivitas rekayasa perangkat lunak. Model estimasi empiris dapat digunakan sebagai pelengkap bagi teknik dekomposisi.

2.4.1 Estimasi Berbasis Masalah

Estimasi berbasis LOC dan FP memiliki teknik yang unik. Keduanya memiliki karakteristik sendiri. Perencana proyek memulai dengan kumpulan pernyataan yang berisi kerangka dan batasan-batasan dari perangkat lunak dan dari peryataan-pernyataan tersebut kemudian mencoba untuk melakukan dekomposisi perangkat lunak ke dalam banyak fungsi permasalahan (problem function) dan melakukan estimasi variabel-variabel (LOC dan FP) pada tiap fungsi permasalahan. Sebagai alternatif, perencana proyek dapat memilih komponen untuk menentukan ukuran, seperti kelas obyek, perubahan, atau proses bisnis yang terpengaruh.

Metrik produktivitas (misalnya: LOC/pm atau FP/pm9) diaplikasikan ke dalam variabel estimasi. Akronim pm digunakan untuk menyatakan satuan person-month (orang-bulan). Metrik kemudian dikombinasikan untuk memperoleh estimasi dari keseluruhan proyek. Dengan menggunakan data dari proyek di masa lalu, perencana proyek dapat membagi nilai perkiraan ke dalam nilai ukuran (S),

2.5 Model Estimasi Empiris

Model estimasi perangkat lunak menggunakan formula yang diperoleh secara empiris untuk memperkirakan tenaga sebagai sebuah fungsi dari LOC atau FP. Data empiris yang paling banyak mendukung dalam model-model estimasi diperoleh dari sampel proyek yang jumlahnya terbatas. Dengan alasan ini, maka tidak ada model

estimasi yang cocok untuk semua lingkungan pengembangan perangkat lunak. Maka dari itu, penerapan hasil yang diperoleh dari model-model yang sudah disediakan harus digunakan secara bijaksana sesuai dengan keadaan lingkungan masing-masing pengembang.

2.5.1 Struktur Model-Model Estimasi

Model estimasi diperoleh melalui analisis regresi pada data yang diperoleh pada proyek-proyek di masa lalu. Keseluruhan struktur dari beberapa model mengambil dari persamaan yang dipaparkan oleh Matson ( Matson, 1994):

E = A + B x (ev)C (2-3)

Dimana E adalah effort dalam orang-bulan, dan A, B, C adalah konstanta yang diperoleh secara empiris. Dalam perkembangannya persamaan tersebut dikembangkan sesuai dengan proyek yang dikerjakan oleh masing-masing pengembang perangkat lunak. Perbedaan persamaan yang digunakan oleh masing-masing pengembang dikarenakan persamaan tersebut harus dikalibrasi terlebih dahulu, sesuai dengan kondisi maupun kebutuhan.

Di antara berbagai model perkiraan yang berorientasi pada LOC yang diusulkan dalam literatur ini adalah :

E = 5,2 x (KLOC)0,91 Walston-felix Model (2.4)

E = 5,5 + 0,73 x (KLOC)1,16 Baily-Basili Model (2.5)

E = 3,2 x (KLOC)1,05 Model sederhana Boehm (2.6)

E = 5,288 x (KLOC)1,047 Dotu Model untuk KLOC > 9 (2.7)

Model-model orientasi FP juga telah diusulkan, yaitu :

E = -13,39 + 0,0545 FP Albercht dan Gaffney Model (2.8)

E = 60,62 x 7,728 x 10-8FP3 Kemerer Model (2.9)

2.5.2 Model COCOMO

COCOMO adalah sebuah model yang didesain oleh Barry Boehm untuk memperoleh perkiraan dari jumlah orang-bulan yang diperlukan untuk mengembangkan suatu produk perangkat lunak. Satu hasil observasi yang paling penting dalam model ini adalah bahwa motivasi dari tiap orang yang terlibat ditempatkan sebagai titik berat. Hal ini menunjukkan bahwa kepemimpinan dan kerja sama tim merupakan sesuatu yang penting, namun demikian poin pada bagian ini sering diabaikan.

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:

1. Proyek organik, adalah proyek dengan ukuran relatif kecil, dengan anggota tim yang sudah berpengalaman, dan mampu bekerja pada permintaan yang relatif fleksibel.

2. Proyek sedang (semi-terpisah), adalah proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda.

3. Proyek terintegrasi, adalah proyek yang dibangun dengan spesifikasi dan operasi yang ketat.

Persamaan dasar model COCOMO adalah:

E = ab (KLOC)bb (2.11)

D = cb (E)db (2.12)

P = E / D (2.13)

Dimana E adalah usaha dalam orang-bulan, D adalah waktu pengerjaan dalam satuan bulan, KLOC adalah estimasi jumlah baris kode dalam ribuan, dan P adalah jumlah orang yang diperlukan. Koefisien ab, bb, cb, dan db diberikan pada tabel berikut:

Tabel 2.3 Model Cocomo Dasar

Proyek Perangkat Lunak ab bb cb db

Organik 2,4 1,05 2,5 0,38

Semi-detached 3,0 1,12 2,5 0,35

Embedded 3,6 1,20 2,5 0,32

Hirarki model Boehm berbentuk sebagai berikut:

Model 1 : Model COCOMO Dasar menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran prgram yang diekspresikan dalam baris kode yang diestimasi.

Model 2 : Model COCOMO Intermediate menghitung usaha pengembangan perangkat lunak sebagai fungsi ukuran program dan serangkaian “pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, perangkat keras personil, dan atribut proyek.

Model 3 : Model COCOMO advanced menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dan lain-lain) dari proses rekayasa perangkat lunak.

Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori dan subkategori sebagai berikut:

1. Atribut produk

a. Reliabilitas perangkat lunak yang diperlukan b. Ukuran basis data aplikasi

c. Kompleksitas produk 2. Atribut perangkat keras

a. Performa program ketika dijalankan b. Memori yang dipakai

c. Stabilitas mesin virtual

3. Atribut Sumber Daya Manusia a. Kemampuan analisis

b. Kemampuan ahli perangkat lunak c. Pengalaman membuat aplikasi

d. Pengalaman menggunakan mesin virtual

e. Pengalaman dalam menggunakan bahasa pemrograman 4. Atribut proyek

a. Menggunakan perangkat lunak tambahan b. Metode rekayasa perangkat lunak

c. Waktu yang diperlukan

Masing-masing subkategori diberi bobot antara 0 (sangat rendah) sampai 6 (sangat tinggi), dan kemudian dijumlahkan. Dari pengembangan ini diperoleh persamaan:

E=ai(KLOC)(b)i.EAF (2.14)

2.5.3 Persamaan pada Perangkat Lunak

Persamaan perangkat lunak merupakan model variabel jamak yang menghitung suatu distribusi spesifik dari usaha pada jalannya pengembangan perangkat lunak. Persamaan berikut ini diperoleh dari hasil pengamatan terhadap lebih dari 4000 proyek perangkat lunak:

E = [LOC x B0.333/P]3 x (1 / t4) (2.15)

E = usaha dalam orang-bulan atau orang-tahun t = durasi proyek dalam bulan atau tahun B = faktor kemampuan khusus

P = parameter produktivitas

Nilai B diambil dengan berdasarkan perkiraan. Untuk program berukuran kecil (0.5 < KLOC < 5), B = 0.16. Untuk program yang lebih besar dari 70 KLOC, B = 0.39.

Nilai P merefleksikan:

1. Kematangan proses dan praktek manajemen 2. Kualitas rekayasa perangkat lunak

3. Tingkat bahasa pemrograman yang digunakan 4. Keadaan lingkungan perangkat lunak

5. Kemampuan dan pengalaman tim pengembang 6. Kompleksitas aplikasi

Berdasarkan teori, diperoleh P = 2000 untuk sistem terapan, P = 10000 untuk perangkat lunak pada sistem informasi dan sistem telekomunikasi, dan P = 28000 untuk sistem aplikasi bisnis.

2.6 Konversi Waktu Tenaga Kerja

Konversi waktu tenaga kerja pada tugas akhir ini ini diperoleh dari angka pembanding yang digunakan pada rata-rata pengerjaan proyek perangkat lunak (Sommervile, 2003), dengan hubungan persamaan antara bulan (OB), jam (OJ), orang-minggu (OM), dan orang-tahun (OT) adalah sebagai berikut:

OM = 40 OJ OT = 12 OB OT = 52 OM

Dari persamaan di atas, diperoleh konversi orang-bulan ke orang-jam sebagai berikut

OB = (40 OJ x 52) / 12

BAB 3 DESAIN SISTEM

3.1 Deskripsi

Untuk menerapkan teori yang telah dibahas pada bab sebelumnya tentang pengukuran perangkat lunak maka perlu dibuat suatu desain perangkat lunak. Berdasarkan teori LOC dan Function Point sebagai acuan untuk melakukan estimasi pada proyek perangkat lunak ini. LOC adalah pengukuran dengan normalisasi kualitas dan produktivitas atau mempertimbangkan ukuran perangkat lunak yang dihasilkan. Hal ini dilakukan dengan menghitung LOC (Line of Code) dari baris kode pada aplikasi yang akan diteliti. Sedangkan FP ( Function Point) lebih dekat ke arah kawasan nilai informasi pada fungsi dari aplikasi yang diteliti. Sebagai bahan pembanding pada tugas akhir ini dipilih tiga aplikasi sebagai bahan penelitian yaitu aplikasi Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi Ilmu Komputer dan Sistem Informasi Perpustakaan SMA Negeri 2 Binjai.

Dalam studi ini, yang digunakan sebagai acuan untuk melakukan estimasi pada proyek perangkat lunak adalah spesifikasi keperluan perangkat lunak dan spesifikasi desain perangkat lunak. Proyek yang digunakan sebagai bahan untuk keperluan studi kasus adalah kegiatan pembuatan prototype ketiga aplikasi tersebut di atas.

3.2 Spesifikasi Keperluan Perangkat Lunak

Sistem Informasi Manajemen Organisasi BKM AlKhuwarizmi digunakan sebagai perangkat lunak untuk melakukan pengolahan data pada proses manajemen di BKM Alkhuwarizmi. Hal ini berguna untuk memudahkan proses kerja kesekretariatan BKM Al Khuwarizmi yang sebelumnya menggunakan sistem konvensional dalam menjalankan aktivitas manajemen.

Aplikasi Sistem Informasi Perpustakaan SMA Negeri 2 Binjai digunakan sebagai perangkat lunak untuk pengolahan data sirkulasi pinjam-kembali pustaka dan data kepustakaan lainnya. Sedangkan aplikasi Kamus Sederhana Inggris-Indonesia digunakan sebagai aplikasi kamus sederhana penerjemahan kata-kata dalam bahasa Inggris dan juga sebaliknya.

3.3 Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi

3.3.1 Usulan Sistem.

Sistem yang diusulkan adalah sebuah sistem informasi dengan fasilitas untuk memasukkan rancangan program kerja, data sirkulasi surat, data inventaris dan kuangan organisasi, data anggota dan laporan cetak . Akses hanya diberikan kepada administrator dengan hak akses untuk memasukkan data tambahan yang diperlukan. Sistem dirancang menggunakan antarmuka berbasis Oriented Object Programming, dengan akses ke basis data dalam waktu-nyata.

3.3.2 Lingkungan Perangkat Lunak.

Sistem Informasi Organisasi BKM Al Khuwarizmi dijalankan pada lingkunan end

user dengan sistem operasi Windows, memakai antar muka berbasis OOP. Bahasa

Pemrograman yang digunakan adalah Borland Delphi 7 dan basis data yang digunakan adalah Interbase.

3.3.3 Spesifikasi Keperluan Fungsional.

Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi dibagi dalam fungsi-fungsi spesifik, yang dijabarkan dalam fungsi-fungsi-fungsi-fungsi sebagai berikut:

a. Fungsi Login.

Fungsi login digunakan untuk autentikasi pengguna Sistem Informasi Manajemen Organisasi dengan memasukkan nama pengguna dan sandi yang telah ditentukan. Nama pengguna dan sandi digunakan untuk menjaga keamanan sistem .

b. Fungsi Pengubahan Sandi.

Fungsi pengubahan sandi (password) digunakan untuk melakukan pengubahan sandi oleh user. Masukan dari sistem ini adalah sandi lama untuk autentikasi pengguna dan sandi baru.

c. Fungsi Administrasi Sirkulasi Surat.

Sirkulasi Surat adalah setiap surat yang masuk dan keluar melalui meja sekertariat. Jenis surat digunakan sebagai parameter dasar untuk pengisian data oleh pengguna Sistem Informasi Manajemen Organisasi. Administrasi sirkulasi surat terdiri dari: fungsi menampilkan data surat, menambah data surat, menyimpan data surat, mengedit data surat dan menghapus data surat.

d. Fungsi Administrasi Data Anggota.

Fungsi administrasi data anggota digunakan untuk data anggota dari BKM Al Khuwarizmi. Data anggota tergantung dengan data jenis keanggotaan di BKM. Administrasi data bidang terdiri dari: fungsi menampilkan data anggota, menambah data anggota, mengubah data anggota, mengedit data anggota, menyimpan data anggota dan menghapus data anggota.

e. Fungsi Administrasi Data Keuangan.

Data Keuangan adalah segala hal mengenai kondisi keuangan di BKM Al-Khuwarizmi. Administrasi data keuangan terdiri dari: menampilkan data keuangan, menambah data keuangan, mengubah data keuangan, mengedit data keuangan dan menghapus data unit kerja.

f. Fungsi Administrasi Inventarisasi.

Inventaris adalah segala harta kekayaan yang dimiliki oleh BKM baik yang bergerak ataupun tidak bergerak, baik bersifat permanen maupun non permanen.

Fungsi administrasi data pnventaris meliputi: menampilkan data inventaris, menambah data inventaris, mengubah data inventaris, mengedit data inventaris, mencari data inventaris dan menghapus data inventaris.

g. Fungsi Administrasi Data Program Kerja.

Fungsi administrasi data program kerja digunakan untuk menentukan program-program yang berjalan pada tahun kepengurusan tertentu. Data program-program kerja tergantung pada data tahun dan bidang organisasi. Fungsi administrasi data program kerja terdiri dari: menampilkan data program, menambah data program, mengubah data program, mengedit data program dan menghapus data program.

h. Fungsi Laporan.

Fungsi pelaporan digunakan untuk menampilkan laporan-laporan seperti: laporan sirkulasi surat, laporan data anggota, laporan data keuangan dan laporan data inventaris selama satu tahun kepengurusan.

3.3.4 Spesifikasi Desain Perangkat Lunak.

Spesifikasi desain yang terdapat dalam Sistem Informasi Manajemen Organisasi digunakan sebagai acuan pada tim pengembang untuk diterapkan pada proses pengembangan Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi.

3.3.4.1Data Flow Diagram.

Untuk lebih menjelaskan proses yang bekerja di dalam proyek perangkat lunak Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi maka dituangkan dalam bentuk Data Flow Diagram. DFD adalah suatu model logika data atau proses yang dibuat untuk menggambarkan darimana asal data dan kemana tujuan data yang keluar dari sistem, dimana data disimpan, proses apa yang menghasilkan data tersebut dan interaksi antaradata yang tesimpan dan proses yang dikenakan pada data tersebut. DFD menunjukan hubungan antar data pada sistem dan proses pada sistem.

Ada 2 teknik dasar DFD yang umum dipakai yaitu Gane and Sarson dan Yourdon and De Marco. Pada tugas akhir ini menggunakan teknik yang digunakan Yourdon and De Marco. Untuk Diagram Konteks rekayasa perangkat lunak Sistem Informasi Manajemen Organisasi BKM Al-Khuwarizmi bisa dilihat pada gambar 3.1 berikut

Gambar 3.1 DFD level 0 Sistem Informasi Manajemen Organisasi BKM

Diagram Konteks di atas menggambarkan sistem secara garis besar yang memperlihatkan masukan, proses, dan keluaran dari sistem yang akan dirancang.

Proses yang terjadi pada diagram konteks di atas dapat dijelaskan dengan menggunakan spesifikasi proses pada tabel 3.1 berikut :

Tabel 3.1 Spesifikasi Proses Diagram Konteks Level 0

No / Nama Proses Input Keterangan Proses Output

Proses 0 / Pengolahan data manajemen organisasi BKM Al khuwarizmi

Record surat, record anggota, record

inventaris, record progja, record keuangan

Pada proses ini seluruh record yang diinput diolah untuk menghasilkan data untuk laporan dan query untuk ditzanpilkan pada interface dalam bentuk borang

Laporan dan query

Dari Diagram Konteks diatas, Proses 0 dapat dijabarkan menjadi proses yang lebih kecil. Proses 0 dibagi lagi ke dalam 2 proses. Proses tersebut dapat dilihat pada gambar 3.2 DFD Level 1 dari Proses P.0. Berikut ini adalah uraian proses yang terjadi pada program.

Gambar 3.2 DFD Level 1 SIM Organisasi BKM Al Khuwarizmi.

Dari DFD Level 1 Proses P.0 terdapat 2 proses utama. Kedua proses ini merupakan proses yang sangat penting karena merupakan inti dari proses aplikasi ini. Proses tersebut dapat diuraikan pada tabel spesifikasi proses berikut ini :

Tabel 3.2 Spesifikasi Proses DFD Level 1 P.0

No / Nama Proses

Input Keterangan Proses Output

Proses P.1/ Proses record

Reqord Reqord diproses untuk di masukkan ke dalam database

Database

Proses

P.2/memproses laporan dan query

Data dari database

Seluruh data diproses untuk menghasilkan query untuk ditampilkann pada laporan dan borang pada tampilan

Laporan dan query

aplikasi

3.3.4.2 Rancangan Antarmuka.

Antarmuka dirancang memiliki 4 (empat) bagian, yaitu: header, menu dan isi. Menu berada di dalam header, digunakan sebagai pranala untuk mengakses modul-modul yang ada di Sistem Informasi Manajemen organisasi BKM Al Khuwarizmi. Bagian isi digunakan sebagai tempat untuk meletakkan modul yang memuat fungsi-fungsi yang dikehendaki dalam Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi.

Gambar 3.3 Perancangan antarmuka modul

Standarisasi rancangan antarmuka dibagi ke dalam 3 (tiga) bagian, yaitu: menampilkan data, menambah data, dan Laporan. Menu penghapusan, pengeditan dan penambahan data ditempatkan sebagai pranala pada halaman penambahan data. Data ditampilkan pada bagian isi yang berisi borang yang digunakan untuk melakukan

output data berdasarkan parameter-parameter tertentu. Rancangan antarmuka tampilan

data dijabarkan dalam gambar 3.2 berikut ini HEADER

ISI MENU

Gambar 3.4 Rancangan antarmuka tampilan data

Rancangan antarmuka untuk menambah data memiliki kemiripan dengan antarmuka pada tampilan untuk mengubah data, karena borang yang menjadi alat pemasukan data memiliki struktur desain yang mirip. Perbedaan yang terdapat pada kedua macam borang tersebut adalah borang penambahan berisi data kosong, sedangkan pada borang pengubahan data bersisi data-data yang hendak diubah. Pranala menuju borang penambahan dan pengubahan data diletakkan pada sub bagian Menu utama. Borang penambahan dan pengubahan data dirancang diletakkan di Menu Utama. Rancangan antarmuka untuk menambah atau mengubah data terdapat pada gambar sebagai berikut:

HEADER

ISI MENU

Borang menampilkan data

Tombol Database Link

Tombol Input Data

Tombol Menampilkan Laporan

Gambar 3.5 Rancangan tampilan pengisian data

3.3.4.3 Rancangan Komponen

Rancangan komponen berisi tentang deskripsi dan cara kerja tiap modul pada Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi. Rancangan komponen dibedakan dengan spesifikasi keperluan fungsional.

a. Login

Fungsi : Autentikasi untuk masuk ke dalam sistem Hak Akses : Administrator

Antarmuka : Tampilan borang nama pengguna dan sandi Proses : Validasi pengguna dan sandi yang dimasukkan

b. Pengubahan Sandi

Fungsi : Pengubahan sandi Hak Akses : Administrator

Antarmuka : Tampilan borang pengubahan sandi

Proses : Validasi dan penggantian sandi lama dengan sandi baru Borang Tampilan Data

simpan Tambah Cancel

Edit Hapus simpan

c. Administrasi Data Sirkulasi Surat

Fungsi : Administrasi sirkulasi surat masuk dan keluar Hak Akses : Administrator

Antarmuka : Tampilan sirkulasi surat , tampilan input sirkulasi surat Proses : Penambahan, penghapusan, pengeditan data surat.

d. Administrasi Data Anggota.

Fungsi : Administrasi data anggota Hak Akses : Administrator

Antarmuka : Tampilan data anggota , tampilan input data anggota Proses : Penambahan, penghapusan, pengeditan data anggota

e. Administrasi Data Keuangan.

Fungsi : Administrasi data keuangan Hak Akses : Administrator

Antarmuka : Tampilan data debet dan kredit keuangan , tampilan input data keuangan

Proses : Penambahan, penghapusan, pengeditan data keuangan

f. Administrasi Data Inventaris.

Fungsi : Administrasi data inventaris organisasi Hak Akses : Administrator

Antarmuka : Tampilan data benda-benda inventaris , tampilan input data inventaris

Proses : Penambahan, penghapusan, pengeditan data inventaris

Fungsi : Menampilkan laporan untuk Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi

Hak Akses : Administrator

Antarmuka : Tampilan data hasil pengolahan administrasi dalam bentuk cetak

Proses : Pencentakan data berdasarkan hasil pengolahan data

3.4 Sistem Informasi Perpustakaan SMA Negeri 2 Binjai

3.4.1 Usulan Sistem.

Sistem Informasi Perpustakaan SMA Negeri 2 Binjai adalah perangkat lunak yang digunakan oleh perpustakaan Sekolah SMA Negeri 2 Binjai untuk mengelola sirkulasi pinjam-kembali benda-benda kepustakaan yang ada di dalam perpustakaan SMA Negeri 2 Binjai. Selain itu juga digunakan sebagai aplikasi pengelolaan data kepustakaan yang dimiliki oleh perpustakaan SMA Negeri 2 Binjai.

Sistem yang diusulkan adalah sebuah sistem informasi dengan fasilitas untuk mengatur sirkulasi pinjam-kembali benda-benda kepustakaan, memasukkan data anggota perpustakaan, data benda kepustakaan dan data klasifikasi kepustakaan. Akses hanya diberikan kepada administrator yang dalam hal ini adalah pegawai perpustakaan dengan hak akses untuk memasukkan data tambahan yang diperlukan. Sistem dirancang menggunakan antarmuka berbasis Oriented Object Programming, dengan akses ke basis data dalam waktu-nyata.

3.4.2 Lingkungan Perangkat Lunak.

Sistem Informasi Perpustakaan SMA Negeri 2 Binjai dijalankan pada lingkunan end

user dengan sistem operasi Windows, memakai antar muka berbasis OOP. Bahasa

Pemrograman yang digunakan adalah Borland Delphi 7 dan basis data yang digunakan adalah Ms Acces.

3.4.3 Spesifikasi Keperluan Fungsional.

Sistem Informasi Perpustakaan SMA Negeri 2 Binjai dibagi dalam fungsi-fungsi spesifik, yang dijabarkan dalam fungsi-fungsi sebagai berikut:

a. Fungsi Menu Master Data.

Fungsi pada Menu Master Data digunakan untuk melakukan pengubahan data yang pada sistem administrasi perpustakaan baik berupa data pemilikan kepustakaan, data anggota dan data klasifikasi kepustakaan. Master data terdiri dari pengaturan untuk menambah data, menghapus data dan mencetak data.

b. Fungsi Menu Transaksi.

Fungsi pada Menu Transaksi digunakan untuk proses peminjaman dan pengembalian benda-benda kepustakaan yang dipinjamkan perpustakaan kepada anggota perpustakaan. Di dalam menu Transaksi terdapat pengaturan untuk peminjaman dan pengembalian.

c. Fungsi Laporan.

Fungsi pelaporan digunakan untuk menampilkan laporan-laporan seperti: laporan catalog kepustakaan, laporan data anggota, laporan data klasifikasi kepustakaan. Tampilan laporan dapat dicetak atau disimpan dalam aplikasi word document.

3.4.4 Spesifikasi Desain Perangkat Lunak.

Spesifikasi desain yang terdapat dalam Sistem Informasi Perpustakaan SMA Negeri 2 Binjai digunakan sebagai acuan pada tim pengembang untuk diterapkan pada proses pengembangan selanjutnya. Dengan melihat spesifikasi desain yang ada pada aplikasi tersebut dapat diambil kesimpulan berbagai kekurangan dan hal-hal yang harus diperbaiki baik dari sisi front end maupun back end aplikasi itu.

3.4.4.1Data Flow Diagaram.

Untuk lebih menjelaskan proses yang bekerja di dalam proyek perangkat lunak Sistem Informasi Perpustakaan SMA Negeri 2 Binjai sebagaimana juga diterapkan pada aplikasi Sistem Informasi Manajemen BKM Al Khuwarizmi, maka dituangkan juga bentuk Data Flow Diagram .

Gambar 3.6 DFD level 0 Sistem Informasi Perpustakaan SMAN 2 Binjai

3.4.4.2Rancangan Antarmuka

Antarmuka dirancang memiliki 3 (tiga) bagian, yaitu: header, menu dan isi. Menu terletak di bawah header, digunakan sebagai pranala untuk mengakses modul-modul yang ada di Sistem Informasi Perpustakaan SMA Negeri 2 Binjai. Bagian isi terletak di dalam menu digunakan sebagai tempat untuk meletakkan modul yang memuat fungsi-fungsi yang dikehendaki dalam Sistem Informasi Perpustakaan SMA Negeri 2 Binja

Gambar 3.7 Perancangan antarmuka modul

Standarisasi rancangan antarmuka dibagi ke dalam 3 (tiga) bagian, yaitu: Master data, Transaksi, dan Report. Masing-masing bagian terdapat menu-menu seperti penambahan data dan daftar data yang ada, juga terdapat menu transasksi pengembalian dan peminjaman serta laporan . Data ditampilkan pada bagian Master data yang berisi borang yang digunakan untuk melakukan output data berdasarkan parameter-parameter tertentu. Rancangan antarmuka tampilan data dijabarkan dalam gambar 3.2 berikut ini

Gambar 3.8 Perancangan antarmuka menu

HEADER MENU

HEADER

Program Master Data Transaksi Report About Tambah data

Tambah Anggota

3.4.4.3 Rancangan Komponen.

Rancangan komponen berisi tentang deskripsi dan cara kerja tiap modul pada Sistem Informasi Perpustakaan SMA Negeri 2 Binjai. Rancangan komponen dibedakan dengan spesifikasi keperluan fungsional.

a. Master Data

Fungsi : Input dan output data anggota dan kepustakaan Hak Akses : Administrator

Antarmuka : Tampilan menu input data dan output data dalam bentuk borang pengisian dan kolom-kolom data

Proses : Penambahan, batal dan penampilan.

b. Transasksi

Fungsi : Pengaturan transaksi peminjaman dan pengembalian benda kepustakaan

Hak Akses : Administrator

Antarmuka : Tampilan transaksi peminjaman, tampilan transasksi pengembalian

Proses : input data

d. Report

Fungsi : Menampilkan data anggota, benda pustaka dan klasifikasinya dalam bentuk cetak dan preview

Hak Akses : Administrator

Antarmuka : Tampilan laporan data anggota, pustaka dan kategori

Proses : Pencetakan dan preview data di tampilan layer dan aplikasi Word.

BAB 4

IMPLEMENTASI BERDASARKAN TEORI

4.1 Estimasi Perangkat Lunak

Dari hasil perancangan sistem yang telah dibuat, maka tahap selanjutnya adalah mengimplementasikan teori yang dipilih yaitu pengukuran menggunakan teori Metric size oriented dan Function Point terhadap sistem yang dibuat untuk mengukur estimasi dari proyek perangkat lunak tersebut. Estimasi dilakukan pada analisis fungsi dan desain yang diperoleh dari spesifikasi keperluan perangkat lunak dan spesifikasi desain perangkat lunak. Estimasi ini lebih mengandalkan intuisi yang dikombinasikan dengan pengalaman selama merancang sistem yang ada sebagai bahan pertimbangan dalam melakukan estimasi. Estimasi fungsi diperoleh dari spesifikasi keperluan perangkat lunak, sedangkan estimasi desain data, antarmuka, menu, dan komponen diperoleh dari spesifikasi desain perangkat lunak. Estimasi fungsi dan desain digunakan sebagai acuan untuk estimasi proses maupun estimasi LOC dan FP.

Estimasi LOC dan FP juga menggunakan pengalaman proyek di masa lalu sebagai salah satu bahan pertimbangan dalam estimasi. Pada estimasi berbasis LOC, Sistem dibagi kedalam modul-modul yang sesuai, dan modul dibagi ke dalam fungsi, lalu dilakukan estimasi jumlah LOC untuk tiap fungsi di dalam modul tersebut. Estimasi jumlah LOC untuk tiap fungsi kemudian dijumlahkan sehingga diperoleh estimasi LOC pada tiap modul. Estimasi LOC pada tiap modulkemudian dijumlahkan sehingga diperoleh estimasi jumlah LOC perangkat lunak secara keseluruhan.

Estimasi FP dilakukan berdasarkan jumlah masukan, jumlah keluaran, jumlah permintaan (inquiries), jumlah berkas, dan jumlah antarmuka eksternal. Masing-masing jumlah estimasi tersebut dikalikan dengan faktor pemberat berdasarkan kompleksitas fungsi perangkat lunak, yang menghasilkan estimasi FP untuk tiap komponen. Estimasi FP tersebut dijumlahkan untuk memperoleh estimasi FP total. Estimasi FP total kemudian dikalikan dengan faktor peubah kompleksitas untuk memperoleh estimasi FP akhir. Hasil estimasi LOC dan FP kemudian dimasukkan ke dalam persamaanpersamaan yang sudah ditentukan, untuk mengubah estimasi LOC

dan FP menjadi estimasi tenaga kerja dan usaha yang diperlukan untuk menyelesaikan proyek pengembangan perangkat lunak.

4.2 Implementasi berdasarkan Teori

Implementasi berdasarkan teori dilakukan dengan menggunakan sumber tulisan mengenai pengukuran perangkat lunak. Teori yang digunakan untuk melakukan perhitungan mengacu pada Pressman [2001].

4.2.1 Estimasi Berbasis LOC

Untuk melakukan penghitungan LOC dilakukan dekomposisi dengan menggunakan persamaan (2-2). Dalam proyek SIMANCA diasumsikan beberapa fungsi perangkat lunak yang diidentifikasi, di antaranya adalah: antarmuka pengguna dan fasilitas kendali (UICF), manajemen basis data (DBM), dan modul analisis desain (DAM). Pada analisa LOC di dalam sub bab ini, digunakan analisa berdasarkan data yang diperoleh dari pengerjaan sistem.

a. Antarmuka pengguna dan fasilitas kendali (UICF)

Antarmuka pengguna dirancang dengan menggunakan tampilan berbasis non-web (berkedudukan sebagai front-end). Kendali fungsi dilakukan melalui pranala-pranala yang disediakan untuk tiap modul yang terdapat pada Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi.

b. Manajemen Basis Data (DBM)

Dalam estimasi desain basis data digunakan analisa berdasarkan rancangan diagram E-R yang terdapat pada spesifikasi desain perangkat lunak. Perkiraan dilakukan dengan menjumlahkan atribut dan entitas-entitas yang telibat pada desain basis data. Perkiraan tersebut kemudian dijumlahkan dengan perkiraan jumlah query yang akan dilakukan. Perkiraan LOC DBM ditampilkan dalam table berikut:

c. Modul Analisis Desain (DAM)

Modul analisis desain digunakan untuk memperkirakan jumlah LOC yangdiperlukan pada fungsi yang ada pada Sistem Manajemen Organisasi BKM Al Khuwarizmi.

Berikut adalah tabel hasil analisa LOC dari aplikasi yang dijadikan sebagai objek penelitian :

Tabel 4.1 Analisa LOC Sistem Informasi Organisasi BKM Al Khuwarizmi

No Modul UICF DBM DAM Total estimasi

1 Login 35 2 70 107

2 Pengubahan login 21 3 80 104

3 Administrasi Sirkulasi Surat 100 5 72 227

4 Administrasi Data Anggota 71 8 34 113

5 Administrasi Data Keuangan 90 7 78 175

6 Administrasi Inventarisasi 95 4 83 182

7 Administrasi Program Kerja

Sub data progja PA 48 4 23 75

Sub data progja PW 47 4 23 74

Sub data Progja Kemakmuran 47 4 23 74

Sub data Progja Sekretariat 48 4 23 75

Sub data Progja Logistik 47 4 23 74

Input data 34 5 94 133

8 Laporan 89 15 167 271

9 Menu Utama 66 66

10 Menu Tambahan 44 44

Total estimasi untuk LOC 882 69 793 1774

Untuk Aplikasi Sisrem Informasi Perpustakaan SMA Negeri 2 Binjai ditunjukkan pada tabel berikut

Tabel 4.2 Analisa LOC Sistem Informasi Perpustakaan SMA Negeri 2 Binjai

No Modul UICF DBM DAM Total Estimasi

1 Menu Master Data 88 46 85 219

2 Menu Transaksi 33 33 38 104

3 Menu Laporan 100 5 72 177

Total estimasi untuk LOC 221 84 205 510

4.2.2 Analisa LOC

a. Analisa LOC Pada Sistem Informasi Manajemen BKM Al Khuwarizmi

Berdasarkan indikasi data historis yang diambil dari proyek-proyek yang telah dikerjakan, produktifitas organisasi untuk sistem adalah 620 LOC/orangbulan. Jumlah total estimasi LOC pada Sistem Informasi Manajemen Organisasi BKM Al khuwarizmi adalah:

LOC = LOC UICF + LOC DBM + LOC DAM = 882 + 69 + 793

= 1744 LOC = 1,744 KLOC

Estimasi tenaga yang diperlukan untuk mengembangkan prototype Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi adalah:

EOB = LOC / 620 = 1744 / 620

= 2.81 orang-bulan Estimasi dalam orang jam: EOJ = EOB x 173,33

= 2.81 x 173,33

= 487,56 orang-jam

Jadi, berdasarkan perhitungan yang diperoleh dari estimasi LOC berdasarkan konstanta yang diambil dari proyek-proyek yang telah dikerjakan, perkiraan jumlah tenaga yang diperlukan untuk mengembangkan Sistem

Informasi Manajemen Organisasi BKM Al Khuwarizmi adalah 2,81 orang-bulan atau setara dengan 487,56 orang-jam.

b. Analisa LOC Pada Sistem Informasi Pepustakaan SMA Negeri 2 Binjai

Bersadarkan kalkulasi yang dilakukan Line Of Code pada aplikasi Sistem Informasi Perpustakaan SMA Negeri 2 Binjai. Maka didapat total estimasi LOC pada Sistem Informasi Perpustakaan SMA Negeri 2 Binjai. adalah:

LOC = LOC UICF + LOC DBM + LOC DAM = 221 + 84 + 205

= 510 LOC = 0,510 KLOC

Estimasi tenaga yang diperlukan untuk mengembangkan prototype Sistem Informasi Perpustakaan SMA Negeri 2 Binjai i adalah:

EOB = LOC / 620 = 510 / 620

= 0.82 orang-bulan Estimasi dalam orang jam: EOJ = EOB x 173,33

= 0.82 x 173,33

= 142,57 orang-jam

Jadi, berdasarkan perhitungan yang diperoleh dari estimasi LOC berdasarkan konstanta yang diambil dari proyek-proyek yang telah dikerjakan, perkiraan jumlah tenaga yang diperlukan untuk mengembangkan Sistem Informasi Perpustakaan SMA Negeri 2 Binjai adalah 0,82 orang-bulan atau setara dengan 142,57 orang-jam.

4.2.3 Estimasi Berbasis FP

a. Analisa Estimasi Berbasis FP Pada Sistem Informasi Organisasi BKM Al Khuwarizmi.

Dekomposisi estimasi berbasis FP lebih dekat ke arah kawasan nilai informasi pada fungsi dari perangkat lunak. Oleh karena itu, faktor pemberat untuk kompleksitas perangkat lunak Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi diasumsikan bernilai sedang.

Tabel 4.3 Perhitungan estimasi FP

Komponen Sistem Software

Level kompleksitas Total

CFP

Sederhana Menengah Kompleks

Cou nt

Faktor Bobot

Point Count Faktor Bobot

Point Count Faktor Bobot

Point

A B C=

AxB

D E F=

DxE

G H I=

GxH

J=C+F +I

Input 5 3 15 4 6 15

Output 5 4 20 4 5 20 7 40

Query Online

4 3 12 4 6 12

File logic 4 7 28 10 15 28

Interface Eksternal

2 5 10 1 7 7 10 17

Total CFP 112

Sesuai dengan teori, hasil dari penjumlahan FP kemudian dikalikan konstanta dan faktor pemberat yang dijabarkan dalam perhitungan berikut:

Tabel 4.4 Perhitungan faktor peubah kompleksitas

No Subyek Nilai

1 Tingkat kompleksitas kehandalan backup/recovery 3

2 Tingkat kompleksitas komunikasi data 2

3 Tingkat kompleksitas pemrosesan terdistribusi 0 4 Tingkat kompleksitas kebutuhan akan kinerja 1 5 Tingkat kebutuhan lingkungan operasional 1

b. Estimasi Empiris Berbasis FP

Model Albrecth dan Gaffney EOB = -13,39 + 0,0545 FP

= -13,39 + (0,0545 x 89,89) = 8,49 orang-bulan

EOJ = EOB x 173,33 = 8,49 x 173,33 = 1471,57 orang-jam Model Kemerer

EOB = 60,62 x 7,728 x 10-8 FP3 = 60,62 x 7,728 x 89,893 x 10-8 = 3,40 orang-bulan

EOJ = EOB x 173,33 = 3,40 x 173,33 = 589,78 orang-jam

Model Matson, Barnett, dan Mellichamp EOB = 585,7 + 15,12 FP

= 585.7 + (15,12 x 89,89) = 1944,83 orang-bulan EOJ = EOB x 173,33

= 1944,83 x 173,33 = 337098,5 orang-jam c. Model COCOMO.

Dalam model COCOMO, tingkat kompleksitas data diasumsikan bernilai sedang, sehingga diperoleh ab = 3,0 dan bb = 1,12. Model COCOMO yang diimplementasikan untuk memperoleh estimasi adalah model COCOMO dasar, dengan asumsi bahwa pada model COCOMO tingkat menengah, EAF memiliki nilai 1,00

= 3,0 x 1,7441,12 = 5,59 orang-bulan EOJ = EOB x 173,33

= 5,59 x 173,33 = 968,9 orang-jam

Untuk Sistem Informasi Perpustakaan SMA Negeri 2 Binjai, maka didapat hasil dari model COCOMO adalah

.EOB = ab (KLOC) b

= 3,0 x 0,5101,12 = 1,41 orang-bulan EOJ = EOB x 173,33

= 1,41 x 173,33 = 244,60 orang-jam

4.2.5 Hasil Pengamatan Lapangan

Hasil pengamatan yang dilakukan pada proses perancangan sampai proyek pembuatan prototype Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi selesai dilakukan. Pengamatan dilakukan dengan menghitung jumlah hari dan jam pembuatan sistem tersebut. Sumber daya manusia yang terlibat dalam pengembangan prototype Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi adalah dua orang dengan lama waktu selama 3 bulan ( 2160 jam ). Sedangkan Untuk Sistem Informasi Perpustakaan SMA Negeri 2 Binjai dikerjakan oleh satu orang dengan lama waktu selama dua minggu (300 jam)

4.3 Perbandingan Hasil Estimasi

Dari perhitungan yang dilakukan, maka nilai estimasi EOJ yang diperoleh dari beberapa model ditampilkan berikut :

a. Sistem Informasi Organisasi BKM Al Khuwarizmi Model Estimasi EOJ

Estimasi Berbasis LOC

Analisis LOC dasar = 487,56 OJ

Model Waltson-Felix = 1494,10 OJ

Model Bailey-Basili = 1194,24OJ

Model Sederhana Boehm = 993,18 OJ

Model COCOMO = 968,9 OJ

Estimasi berbasis FP

Model Albrecth dan Gaffney = 1336,94 OJ

Model Kemerer = 916,91 OJ

Model Matson, Barnett, dan Mellichamp = 374496,66 OJ b. Sistem Informasi Perpustakaan SMA Negeri 2 Binjai. Model Estimasi EOJ

Estimasi Berbasis LOC

Analisis LOC dasar = 142,57 OJ

Model Waltson-Felix = 488,38 OJ

Model Bailey-Basili = 1011,25 OJ

Model Sederhana Boehm = 993,18OJ

Model COCOMO = 244,60 OJ

Estimasi berbasis FP

Model Albrecth dan Gaffney = 1471,57 OJ

Model Kemerer = 589,78 OJ

Model Matson, Barnett, dan Mellichamp = 337098,5 OJ

Dari perhitungan diperoleh bahwa tiap model memiliki hasil perhitungan yang berbeda untuk LOC dan FP yang sama. Hasil yang berbeda diperoleh karena masing-masing model menggunakan indikator yang berbeda pada saat pembuatan estimasi. Selain itu, masing-masing hasil estimasi tersebut diperoleh berdasarkan pengalaman

dari masing-masing pencipta model estimasi. Apabila data hasil estimasi dibandingkan dengan hasil pengamatan pada proyek, maka diperoleh selisih, dimana hasil estimasi tenaga lebih besar dari kenyataan yang terjadi di lapangan..

Hasil estimasi tenaga terkecil diperoleh pada model estimasi persamaan pada LOC dasar. Dari hasil pengamatan pada estimasi proyek pengembangan Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi dan Sistem Informasi Perpustakaan SMA Negeri 2 Binjai, hasil analisis persamaan perangkat lunak yang diimplementasikan pada beberapa model memiliki rerata EOJ yang lebih kecil dibandingkan pada analisis serupa yang menggunakan FP. Hasil estimasi yang paling besar diperoleh pada model Matson, Barnett, dan Mellichamp. Hasil perhitungan menunjukkan bahwa hasil estimasi pada model Matson, Barnett, dan Mellichamp menghasilkan jumlah EOJ yang jauh lebih besar dari estimasi model lainnya.

Dari hasil implementasi terhadap proyek Sistem Informasi Manajemen Organisasi BKM Al Khuwarizmi dan Sistem Informasi Perpustakaan SMA Negeri 2 Binjai diperoleh bahwa model analisis yang paling mendekati hasil di lapangan adalah analisis berbasis LOC yang menggunakan indikasi data yang telah ada. Hasil analisis yang paling jauh dari hasil yang diperoleh dari lapangan adalah estimasi berbasis FP yang menggunakan model Matson, Barnett, dan Mellichamp.

BAB 5

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Berdasarkan pembahasan dan evaluasi dari bab-bab terdahulu dan teori yang ada, maka dapat ditarik kesimpulan sebagai berikut:

1. Pengukuran perangkat lunak diperlukan untuk melakukan perkiraan untuk mengetahui perkiraan sumber daya manusia dan waktu yang diperlukan menyelesaikan proyek perangkat lunak yang sedang dikembangkan.

2. Teori yang ada tidak menunjukkan hasil yang cukup akurat disebabkan pengalaman yang berbeda-beda dari masing-masing pembuat teori sehingga tidak semua hasil yang diturunkan dari teori-teori tersebut sama dan akurat dengan kondisi yang nyata.

3. LOC sangat sulit dijadikan sebagai alat ukur disebabkan ambiguitas dari cara menghitung LOC itu sendiri. Namun hasil yang didapat cukup mendekati kondisi sesungguhnya dari estimasi tenaga dan waktu dalam pengerjaan proyek disbanding menggunakan teori FP.

4. Kesulitan banyak ditemukan saat mengukur estimasi tenaga dan waktu pengerjaan proyek dengan menggunakan teori Function Point karena hasil yang diterima cukup abstrak.

5.2 Saran

Sebagai penutup dari skripsi ini adalah bahwa sangat penting sekali untuk pembelajaran yang lebih serius dalam mengkaji pengukuran pada perangkat lunak guna memperkirakan sumber daya, tenaga dan waktu yang digunakan untuk

Arif, Muhammad. 21 Maret 2010 Pengukuran perangkat lunak menggunakan metric size oriented dan metric function-oriented. 21 Maret 2010.

http://rpl07.wordpress.com/2007/06/21/pengukuran-perangkat-lunak-

menggunakan-metrik-size-oriented-dan-metrik-function-oriented-oleh-arif-m- 5105-100-139/.

Christianto V dan I Made Wiryana. 2002. Pengantar Manajemen Proyek Berbasis Internet. Jakarta: Elex Media Komputindo.

Grady, Robert B. 1992. Practical Software Metrics for Project Management and Process Improvement. London: Prentice-Hall, Inc.

IEEE Standard Glossary of Software Engineering Technology, IEEE Std 610.12-1990. 1990. New York: Institute of Electrical and Electronics Engineers.

Kadir, Abdul. 2006. Dasar aplikasi Database MySQL Delphi. Cetakan Kedua. Yogyakarta: ANDI.

McCall, J.A, P.K. Richards, and G.F. Walters. 1977. Factors in Software Quality. Tehnical Report RADC-TR-77-369. US: Department of Commerce.

Pressman, Roger.S. 2001. Software Engineering: A Practitioner’s Approach. 5th edition. New York : McGraw-Hill.

Sommerville, Ian. 2003. Software Engineering. Jilid 1. Edisi ke-6. Terjemahan Yuhilza Hanum. Jakarta: Erlangga.

---. 2003. Software Engineering. Jilid 2. Edisi ke-6. Terjemahan Yuhilza Hanum. Jakarta: Erlangga.