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
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
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,
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
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.
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
DAFTAR ISI
2.2.1 Metrik Proses dan Peningkatan Perangkat Lunak 9
2.2.2 Metrik Proyek 11
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.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
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
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.
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).
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
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
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
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
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
(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:
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 :
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 :
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.
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.
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
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
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
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)
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 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
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.
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.
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.
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
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
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
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
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
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.
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
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
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.
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)
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
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
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
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
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
6 Tingkat kebutuhan knowledge pengembang 2 7 Tingkat kompleksitas updating file master 2
8 Tingkat kompleksitas instalasi 2
9 Tingkat kompleksitas aplikasi input, output, query online dan file
3
10 Tingkat kompleksitas pemrosesan data 3
11 Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse)
1
12 Tingkat variasi organisasi pelanggan 1
13 Tingkat kemungkinan perubahan/fleksibilitas 2 14 Tingkat kebutuhan kemudahan penggunaan 5
Total = RCAF 28
Faktor peubah kompleksitas
FP = CFP x (0,65 + 0,01 x RCAF) FP = 112 x (0.65 + 0,01 x 28) FP = 104,16
Estimasi FP setelah dikalikan faktor peubah kompleksitas: 104,16 FP
b. Analisa Estimasi Berbasis FP Pada Sistem Informasi Perpustakaan SMA
Negeri 2 Binjai.
Tabel 4.5 Perhitungan estimasi FP
Sederhana Menengah Kompleks
Count Faktor
Sesuai dengan teori, hasil dari penjumlahan FP kemudian dikalikan konstanta dan faktor pemberat yang dijabarkan dalam perhitungan berikut:
Tabel 4.6 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
6 Tingkat kebutuhan knowledge pengembang 1
7 Tingkat kompleksitas updating file master 2
8 Tingkat kompleksitas instalasi 1
9 Tingkat kompleksitas aplikasi input, output, query online dan file 2
10 Tingkat kompleksitas pemrosesan data 2
11 Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse) 1
12 Tingkat variasi organisasi pelanggan 1
13 Tingkat kemungkinan perubahan/fleksibilitas 3
14 Tingkat kebutuhan kemudahan penggunaan 4
