12 landasan teori - thesis.binus.ac.idthesis.binus.ac.id/doc/bab2/2012-1-00447-if bab2001.pdf · 17...
TRANSCRIPT
12
BAB 2
LANDASAN TEORI
2.1 Perangkat Lunak
2.1.1 Definisi dan Karakteristik Perangkat Lunak
Definisi perangkat lunak menurut Pressman adalah: (Pressman, 2010)
• Instruksi (program komputer) yang ketika dijalankan akan menyediakan
fitur, fungsi dan hasil yang diinginkan
• Struktur data yang mengaktifkan program untuk memanipulasi informasi,
dan
• Deskripsi informasi dari kedua point diatas yang menggambarkan operasi
dan penggunaan program.
Karakteristik perangkat lunak yang membedakan dengan perangkat
keras menurut Pressman diantaranya: (Pressman, 2010)
• “Software is developed or engineered; it is not manufactured in the
classical sense”.Yang dimaksud adalahperangkat lunak merupakan suatu
produk yang lebih menekankan pada kegiatan rekayasa (engineering)
dibandingkan kegiatan manufacturing.
• Software doesn’t “wear out”. Artinya adalahperangkat lunak bukanlah
produk yang dapat usang atau rusak untuk kemudian dibuang, seperti
13
halnya pada produk perangkat keras. Yang mungkin terjadi adalah
produkperangkat lunak tersebut tidak dapat memenuhi kebutuhan
penggunanya disebabkan berkembangnya kebutuhan-kebutuhan baru.
Sehingga perlu dilakukan perubahan pada perangkat lunak tersebut.
Berikut ini terdapat 2 (dua) kurva yang menjelaskan hubungan antara
tingkat kerusakan dan waktu pada masing-masing perangkat baik itu
perangkat keras maupun perangkat lunak.
Kurva yang menggambarkan siklus hidup perangkat keras atau
biasa disebut dengan “bathtub curve” ditunjukkan pada gambar dibawah
ini:
Gambar 2. 1: Kurva Siklus Kegagalan pada Perangkat Keras
(Pressman, 2010)
Gambar diatas menjelaskan tingkat kerusakan/kegagalan yang
terjadi pada perangkat keras. Mengindikasikan kegagalan yang relatif
14
tinggi pada masa awal terciptanya perangkat keras tersebut, tingkat
terendah terjadi pada keadaan dimana dilakukan perubahan dan perbaikan
pada perangkat keras untuk memenuhi kebutuhan penggunanya dan seiring
dengan berjalannya waktu tingkat kegagalan mengalami peningkatan yang
relatif tinggi yang disebabkan oleh terjadinya kerusakan-kerusakan,
penyalahgunaan, faktor lingkungan yang berpengaruh pada kestabilan
penggunaan perangkat keras.
Berikut ini adalah kurva yang menjelaskan siklus hidup perangkat
lunak, terdapat 2 (dua) kurva diantaranya “Idealized curve” dan “Actual
curve”:
Gambar 2. 2: Kurva Siklus Kegagalan pada Perangkat Lunak
(Pressman, 2010)
Dari gambar diatas, Idealized curve menjelaskan bahwa tingginya
tingkat kerusakan yang terjadi disebabkan oleh kecacatan yang belum
15
ditemukan pada masa awal terciptanya perangkat lunak tersebut. Namun
masalah itu bisa diselesaikan dan diperbaiki untuk memenuhi kebutuhan
penggunanya, dan tingkat kegagalan menurun secara berkala seperti yang
ditunjukkan pada gambar. Kondisi ini menjelaskan bahwa perangkat lunak
tidak akan pernah usang atau rusak melainkan hanya mengalami penurunan
kualitas.
Pada actual curve dijelaskan bahwa selama masa hidupnya
perangkat lunak mengalami perubahan-perubahan demi memenuhi
kebutuhan penggunanya, selama perubahan itu terjadi maka akan
ditemukan kesalahan-kesalahan yang tidak diinginkan, hal ini
menyebabakan kurva mengalami peningkatan untuk tingkat kerusakan
yang terjadi selama perubahan dan penemuan error tersebut seperti
ditunjukkan pada gambar kurva aktual diatas. Sebelum kurva kembali ke
keadaan awal, terjadi permintaan perubahan lain, hal ini menyebabkan
kurva kembali meningkat. Dalam kasus ini perangkat lunak hanya
mengalami penurunan kualitas yang disebabkan oleh perubahan.
• Although the industry is moving toward component-based construction,
most software continues to be custom built. Artinya adalahsebagian besar
perangkat lunak tidak dibangun dari perangkat lunak yang sudah ada.
Pembangunan aplikasi baru kebanyakan dimulai dari awal, dari tahap
analisis sampai tahap pengujian. Namun demikian, kini paradigma baru
mulai dikembangkan, yaitu konsep reuseabilityatau penggunaan kembali.
16
Dengan konsep ini suatu aplikasi baru dapat dikembangkan dari aplikasi
yang sudah ada yang menerapkan konsep reusability tersebut.
2.2 Object Oriented Programming
Object Oriented Programming adalah paradigma pemrograman yang
memandang perangkat lunak sebagai kumpulan objek yang saling berinteraksi di
dalam suatu sistem. (Aziz) Beberapa objek berinteraksi dengan saling memberikan
informasi satu terhadap yang lainnya. Masing-masing objek harus berisikan
informasi mengenai dirinya sendiri (encapsulation) dan objek yang dapat dikaitkan
(inheritance). (Febrian)
Dalam OOP, Class merupakan sekumpulan objek yang memiliki atribut-
atribut dan method. Class merupakan deskripsi dari satu atau lebih objek yang
memiliki kesamaan atribut, layanan, metode, hubungan, dan semantik, termasuk
deskripsi cara membuat objek baru dalam class. Ada juga yang disebut dengan
superclass, sebuah class induk yang nantinya mempunyai class-class yang terdiri
dari class dan subclass. (Lethbridge & Laganiere, 2005)
Objek dalam OOP adalah sebuah benda atau unit atau sifat kerja yang
memiliki atribut-atribut. Objek adalah sebuah abstraksi dari sesuatu pada domain
masalah, menggambarkan kemampuan untuk menyimpan informasi mengenai hal
tersebut, berinteraksi dengan hal tersebut atau keduanya.(Lethbridge & Laganiere,
2005)
Abstraksi prosedural dalam OOP disebut dengan operasi, yang menjelaskan
tipe dari perilaku dan terdiri dari fungsi-fungsi. (Lethbridge & Laganiere, 2005)
17
Selain yang disebutkan di atas, istilah lainnya yaitu encapsulation/
pengkapsulan, yang merupakan pembatasan ruang lingkup program terhadap data
yang diproses agar data terlindungi oleh prosedur atau objek lain, kecuali prosedur
yang berada di objek itu sendiri. (Lethbridge & Laganiere, 2005)
Polymorphism adalah konsep yang menyatakan bahwa sesuatu yang sama
dapat mempunyai bentuk dan perilaku yang berbeda, bahwa operasi yang sama
mungkin memiliki perbedaan dalam class yang berbeda. (Lethbridge & Laganiere,
2005)
Pada OOP, terdapat juga istilah yang disebut dengan inheritance
(pewarisan), yaitu kepemilikan yang bersifat implicit dari fitur subclass yang
didefinisikan dalam superclass. Fitur tersebut mencakup variabel dan method.
(Lethbridge & Laganiere, 2005)
2.3 Aplikasi berbasis Web
Menurut Pressman (Pressman, 2010) sistem aplikasi berbasis web(WebApps)
berbeda dengan sistem dan aplikasi lain karena hal-hal dibawah ini:
1. Network intensiveness
Sifat dasar dari WebApps adalah sistem ini ditujukan untuk berada di jaringan
dan memenuhi kebutuhan komunitas yang berbeda.
2. Concurrency
Pengguna dapat mengakses WebApps dalam satu waktu secara bersamaan.
18
3. Unpredictable load
Banyaknya pengguna yang mengakses WebApps tidak bisa diprediksi dari hari
ke hari.
4. Performance
Jika pengguna WebApps harus menunggu respon dari sistem, maka pengguna
dapat memilih untuk meninggalkan halaman tersebut dan pindah ke tempat lain.
5. Availability
Ketersediaan WebApps untuk dapat diakses secara terus menerus dalam
24/7/365.
6. Data driven
Sebagian besar dari fungsi WebApps adalah untuk menyajikan informasi dalam
bentuk teks, grafik, audio, dan video.
7. Content sensitive
Kualitas dan estetika dari content merupakan penentu utama bagaimana kualitas
WebApps.
8. Continuous evolution
WebApps selalu berkembang secara terus menerus.
9. Immediacy
Kebutuhan yang mendesak untuk mendapatkan perangkat lunak yang dapat
digunakan oleh pengguna akhir dapat dengan cepat diselesaikan oleh sistem
WebApps dalam beberapa hari atau minggu.
19
10. Security
Tingkat keamanan yang sulit untuk WebApps. Karena berada di jaringan, sulit
untuk menjamin content aplikasi yang sensitive dari pengguna akhir yang tidak
baik. Sulit untuk membatasi populasi pengguna yang ingin mengakses aplikasi.
11. Aesthetic
Segi keindahan tampilan untuk menarik minat pengguna. Ketika WebApps
didesain untuk pengguna, tampilan yang baiklah yang banyak digunakan oleh
pengguna WebApps.
Sistem dan aplikasi berbasis web (WebApps) memiliki beberapa kelebihan,
antara lain:(Darie, Brinzarea, Filip, & Bucica, 2006)
1. Web application mudah dan murah untuk pengiriman (deliver). Dengan web
application, perusahaan bisa mengurangi biaya pada bagian IT untuk instalasi
perangkat lunak setiap komputer pengguna di perusahaan karena komputer
pengguna hanya cukup memiliki browser dan koneksi internet/intranet.
2. Web application mudah dan murah untuk ditingkatkan (upgrade). Karena biaya
upgrade setiap komputer pengguna di perusahaan cenderung mahal dan harganya
hampir seperti membeli perangkat lunak baru maka dengan web application
cukup hanya upgrade server saja dan semua pengguna di perusahaan dapat
menikmati aplikasi baru.
3. Web application memiliki persyaratan yang fleksibel untuk penggunanya. Cukup
hanya menginstalasi web application pada server perusahaan maka semua
20
komputer pengguna, baik yang menggunakan Windows, Mac, atau Linux, dapat
menggunakan tanpa ada kendala pada perbedaan platform.
4. Web application memudahkan untuk menyimpan data secara terpusat. Ketika
berada pada lokasi yang berbeda dan ingin mengakses data yang sama pada
setiap komputer yang digunakan, cukup dengan server saja. Dengan cara ini, bisa
meminimalkan biaya operasi untuk sinkronisasi data dan menurunkan risiko
keamanan yang ada.
2.4 Pengukuran dan Metrik
2.4.1 Definisi dan Prinsip Dasar Pengukuran
Menurut Pressman (Pressman, 2010) dalam konteks rekayasa perangkat
lunak, ukuran merupakan indikasi yang bernilai kuantitatif yang didapatkan
dari perhitungan luas, jumlah, dimensi, kapasitas atau ukuran dari atribut
sebuah produk atau proses. Pengukuran adalah aksi atau tindakan untuk
menentukan ukuran.
Prinsip dasar pengukuran menurut Roche dalam buku “Software
Engineering a Practitioner’s Approach”(Pressman, 2010)menunjukkan
bahwa pengukuran dapat dikategorikan berdasarkan lima kegiatan,
diantaranya:
1. Formulation: menentukan cara perhitungan yang akan digunakan dalam
mengukur suatu perangkat lunak dan metrik yang sesuai untuk
diterapkan.
21
2. Collection: mekanisme yang digunakan untuk mengakumulasi data yang
dibutuhkan untuk memperoleh perumusan metrik.
3. Analysis: perhitungan metrik dan penerapan matematika.
4. Interpretation: evaluasi metrik yang menghasilkan pemahaman mengenai
representasi kualitas.
5. Feedback: rekomendasi yang diperoleh dari interpretasi metrik sebuah
produk yang ditransmisikan ke tim software.
Definisipengukuran menurut Pressman (Pressman, 2001)dibagi menjadi
2 cara, yaitu:
1. Pengukuran langsung, dalam proses rekayasa perangkat lunak
berhubungan dengan biaya dan usaha, misalnya: perhitungan jumlah Line
Of Code(LOC), kecepatan eksekusi, ukuran memori dan kesalahan yang
ditemui dalam suatu periode waktu.
2. Pengukuran 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 melalui proses yang lebih
kompleks.
22
2.4.2 Metrik Function Point
Menurut Pressman (Pressman, 2010) metrik Function Point (FP) dapat
digunakan untuk mengukur fungsionalitas yang dikirim oleh sistem. Dengan
menggunakan data historis, metrik Function Point dapat digunakan untuk:
1. Memperkirakan biaya atau upaya yang dibutuhkan dalam desain, kode
dan menguji perangkat lunak.
2. Memprediksi jumlah kesalahan yang akan ditemui selama pengujian.
3. Memperkirakan jumlah komponen dan/atau jumlah baris kode dalam
sistem.
Keuntungan menggunakan metode Function Point menurut Galin
diantaranya: (Galin, 2004)
• Estimasi dapat dipersiapkan pada tahap pra-proyek dan oleh karena itu
dapat mendukung manajemen dalam upaya persiapan proyek.
• Function point tidak bergantung pada bahasa pemrograman, sehingga
keandalan metode ini relatif tinggi.
Kerugian menggunakan metode Function Point menurut Galin
diantaranya: (Galin, 2004)
• Untuk tingkat tertentu, hasil perhitungan Function Point bergantung pada
perhitungan Function Point dengan instruksi manual yang digunakan oleh
project manageruntuk mempersiapkan estimasi.
23
• Estimasi harus didasarkan pada spesifikasi sistem perangkat lunak secara
mendetail yang tidak selalu tersedia pada tahap pra-proyek.
• Seluruh proses perhitungan memerlukan orang yang berpengalaman.
• Banyaknya evaluasi yang dibutuhkan berdampak pada hasil yang
subjektif.
• Perhitungan function point dilakukan hanya didasarkan pada sistem
pemrosesan data. Pada kenyataannya aspek-aspek lain dari
pengembangan sistem perangkat lunak juga ikut berpengaruh terhadap
pengembangan itu sendiri. Oleh karena itu metode function point tidak
dapat diterapkan secara universal atau masih membutuhkan dukungan
perhitungan faktor lain untuk memperkuat estimasi.
2.4.3 Pengukuran Perangkat Lunak
Pengukuran perangkat lunak dibawah ini berdasarkan teori dari Laird
dan Brennan dalam bukunya “Software Measurement and Estimation”,
diantaranya: (Laird & Brennan, 2006)
1. Measuring Size (Pengukuran Ukuran)
Ukuran adalah salah satu atribut dasar dari perangkat lunak.
Beberapa pertanyaan mengenai informasi yang ingin diperoleh dari
pengukuran ukuran sebuah perangkat lunak diantaranya:
a. Seberapa besar ukuran sebuah perangkat lunak ? Seberapa besar proyek
tersebut dibandingkan dengan proyek lainnya?
24
b. Berapa banyak usaha yang dibutuhkan untuk membangun perangkat
lunak?
c. Bagaimana kualitas proyek tersebut dibandingkan dengan proyek
lainnya?
d. Bagaimana produktifitas proyek tersebut dibandingkan dengan proyek
lainnya?
Ukuran adalah dasar untuk semua metrik. Untuk menjawab
pertanyaan tersebut harus mampu untuk mengukur ukuran dengan standar
yang memungkinkan dengan membandingkan suatu proyek dengan proyek
lainnya, dan menjadi sebuah tolak ukur.
Dalam analisis Function Point berdasarkan International Function
Point User Group (IFPUG) terdiri dari langkah-langkah sebagai berikut:
Langkah pertama dalam meghitung sebuah ukuran dimulai dengan
menghitung UFP (Unadjusted Function Points). UFP (Unadjusted
Function Points) adalah akumulasi keseluruhan dari Complexity Ratings.
Tabel 2. 1: Complexity Rating
Component Simple Average Complex
Inputs (I) 3 4 6
Outputs (O) 4 5 7
Data Files (F) 7 10 15
Interfaces (N) 5 7 10
Inquiries (Q) 3 4 6
25
Untuk masing-masing komponen diatas diperoleh dari jumlah field
yang diinput pengguna (external input), jumlah output yang dihasilkan
sistem untuk pengguna yang dapat berupa print out(external output),
jumlah query yang menyediakan informasi ke user melalui pengambilan
data yang ditampilkan ke layar (external queries), jumlah logic penyimpan
data yang dapat berupa file atau database (internal logical files), dan
jumlah informasi kontrol yang dirujuk oleh aplikasi, tapi dipelihara oleh
aplikasi lain. Kemudian dikategorikan berdasarkan 3 (tiga) tingkatan
kompleksitas (simple, average, complex) yangakan dikalikan dengan nilai
masing-masing dari tingkatan kompleksitas.(3)
Tabel 2. 2: Tabel Perhitungan Data UFP (Unadjusted Function Point)
UFP Data Simple Average Complex Total
EI (External Input) __ x 3 = __ __ x 4 = __ __ x 6 = __
EO (External Output) __ x 4 = __ __ x 5 = __ __ x 7 = __
ILF(Internal Logic Files) __ x 7 = __ __ x 10 = __ __ x 15 = __
EIF (External Interface Files) __ x 5 = __ __ x 7 = __ __ x 10 = __
EQ (External Queries) __ x 3 = __ __ x 4 = __ __ x 6 = __
Proses pertama yang dilakukan untuk akumulasi data UFP adalah
dengan memasukkan nilai dari masing-masing kelima data UFP di atas.
Setelah masing-masing nilai dari External Input, External Output, Internal
Logic Files, External Interface Files, dan External Queries dimasukkan
barulah akumulasi UFP di dapatkan.
26
Langkah kedua dalam menghitung sebuah ukuran adalah dengan
menghitung akumulasi VAF (Value Adjusment Factor). VAF (Value
Adjusment Factor) dihitung berdasarkan pada keseluruhan kompleksitas
sistem. Cara menghitung VAF (Value Adjusment Factor) dengan
menggunakan 14 (empat belas) GSC (General System Characteristics),
dimana nila masing-masing dari GSC berskala 0 (nol) sampai 5 (lima).
Skala 0 (nol) menunjukkan tidak adanya pengaruh dan skala 5 (lima)
menunjukkan adanya pengaruh yang luas terhadap keseluruhan proyek.
Tabel 2. 3: General System Characteristics
General System Characteristic Brief Description
1. Data Communication Berapa banyak fasilitas komunikasi yang ada untuk membantu pertukaran informasi dengan penerapan system aplikasi?
2. Distributed Data / Processing Bagaimana data di distribusikan dan pengolahan fungsi ditangani?
3. Performance Objectives Seberapa lama waktu yang diperlukan dan performa secara keseluruhan
4. Heavily Used Configuration Bagaimana platform perangkat keras yang digunakan saat ini dimana aplikasi akan dieksekusi?
5. Transaction Rate Tingkat transaksi yang tinggi?
6. Online Data Entry Berapa persentase dari informasi yang dimasukkan secara online?
7. End-User Efficiency Apakah aplikasi yang dirancang untuk pengguna efisien?
8. Online Update Berapa banyak data di ubah secara online?
9. Complex Processing Apakah proses internal yang
27
dilakukan kompleks?
10. Reusability Apakah aplikasi didesain dan dikembangkan untuk memudahkan pengguna?
11.Conversion / Installation Ease
Apakah konversi dan instalasi dilakukan secara otomatis?
12. Operational Ease Apakah operasi seperti backup, startup, dan recovery dilakukan secara otomatis?
13. Multiple Site Use Apakah spesifikasi aplikasi didesain, dikembangkan dan didukung untuk berb agai situs dengan berbagai organisasi?
14. Facilitate Change Apakah spesifikasi aplikasi didesain, dikembangkan dan didukung untuk memfasilitasi perubahan dan kemudahan penggunaan oleh user?
Akumulasi VAF ditentukan dari jumlah total seluruh skala GSC
(General Characteristics System) yang telah ditentukan oleh pengguna.
Langkah ketiga yang dilakukan untuk perhitungan ukuran adalah
dengan menghitung AFP (Adjusted Function Point). AFP (Adjusted
Function Point) adalah perhitungan dari perkalian VAF (Value Adjusment
Factor) dari UFP (Unadjusted function Point).
AFP = UFP * (0.65 + 0.01 * VAF)
Langkah keempat yang dilakukan untuk perhitungan ukuran
adalah dengan menentukan bahasa pemrograman yang digunakan pada
perangkat lunak. Dibawah ini adalah tabel untuk bahasa pemrograman
28
yang ada berdasarkan pada QSM (Quantitative Software Management):
(QSM Function Point Language Table, 2012)
Tabel 2. 4: QSM SLOC / FP Data
Language
Avg
QSM SLOC/FP
Median
Low
High
ABAP (SAP) 18 18 16 20
Access * 36 38 15 47
Ada 154 - 104 205
Advantage 38 38 38 38
APS 86 83 20 184
ASP * 56 50 32 106
Assembler* 209 203 91 320
C* 148 107 22 704
C++* 59 53 20 178
C#* 58 59 51 66
Clipper* 40 39 26 53
COBOL* 80 78 8 400
ColdFusion 68 56 52 105
Cool:Gen/IEF* 38 35 10 180
Culprit 51 - - -
Datastage 67 79 16 85
Dbase III - - - -
Dbase IV 52 - - -
29
Easytrieve+ 33 34 25 41
Excel 47 46 31 63
Focus* 45 45 40 49
FORTRAN 90 118 35 -
FoxPro* 36 35 34 38
HTML 43 42 35 53
Ideal 66 52 34 203
Informix* 42 31 24 57
J2EE* 57 50 50 67
Java* 55 53 9 214
JavaScript* 54 55 45 63
JCL* 96 59 58 173
JSP 59 - - -
KML 50 50 49 50
Lotus Notes* 23 21 15 46
Maestro 30 30 30 30
Mantis 71 27 22 250
Mapper* 69 70 58 81
Natural* 51 53 34 60
.NET 60 60 60 60
Netron/CAP 296 323 105 399
Openroad 39 34 20 69
Oracle* 42 29 12 217
Oracle Dev 2K* 35 30 23 100
Pacbase* 42 43 26 52
PeopleSoft* 37 32 34 40
Perl 57 57 45 60
30
PL/1* 58 57 27 92
PL/SQL* 47 39 16 78
Powerbuilder** 28 22 8 105
Powerhouse 63 25 79
REXX 50 - - -
RPG II/III 61 49 24 155
Sabretalk* 70 61 54 94
SAS* 50 35 32 102
Siebel Tools 13 13 5 20
Slogan* 81 80 66 100
Smalltalk** 28 19 17 55
SQL* 31 30 13 80
SQL Forms 11 11 10 15
Taskmate 45 47 37 51
Uniface 61 50 31 120
VB.Net 28 - - -
VBScript* 38 37 29 50
Visual Basic* 50 52 14 276
VPF 95 95 92 98
Web Scripts 44 15 9 114
Nilai bahasa pemrograman yang digunakan untuk perhitungan
SLOC di dapat dari nilai rata-rata yang berasal dari tabel QSM SLOC/FP
dengan formula sebagai berikut:
31
Physical Size = Language * AFP
2. Measuring Effort (Pengukuran Usaha)
Usaha didefinisikan sebagai jumlah dari staff per-hari, per-
minggu, per-bulan, bahkan per-tahun yang terkait dengan proyek.
Perhitungan usaha didapatkan dari perkalian staff dan schedule, dimana
schedule merupakan hasil dari perhitungan menggunakan nilai Function
Point yang telah diperoleh.
Untuk mengukur effort diperlukan variabel yang terdiri dari
schedule dan staff. Menurut Jones, schedule dipengaruhi oleh nilai indeks
dari skala 0.32 sampai 0.4. Dimana untuk indeks 0.32 digunakan pada
proyek berskala kecil atau menengah, dan untuk indeks 0.4 digunakan pada
proyek berskala besar dengan nilai function point rata-rata lebih besar dari
1000FP. (Capers, 1998)
Schedule = FP0.32-0.4
Staff = FP / 150
Effort = Staff * Schedule
3. Measuring Complexity (Pengukuran Kompleksitas)
Terdapat banyak struktur metrik kompleksitas yang sudah
ditetapkan, dicoba, dan dikembangkan. Berikut ini merupakan beberapa
metrik yang dijelaskan dalam mengestimasi kompleksitas suatu perangkat
lunak:
32
a. Ukuran sebagai dasar pengukuran kompleksitas
Perhitungan Line Of Code (LOC) atau Function Point yang
menjadi dasar perhitungan ukuran juga merupakan faktor utama dalam
memprediksi kecacatan. Perhitungan kecacatan dibutuhkan untuk
mengetahui kompleksitas suatu sistem. Dalam konteks ini terdapat 2 (dua)
jenis kesalahan, yaitu module-related faults dan instruction-related faults.
(Malayia & Denton, 2000) Untuk module-related faults, terdapat kesalahan
yang disebabkan dari kode modular yang diintegrasikan ke modul lain.
Karena itu, untuk modul yang terkait, jika sebuah modul dari ukuran
dilambangkan dengan ‘s’, kecacatan di lambangkan dengan Dm (dalam
defects / LOC)
Dm (s) = a/s
Dimana ‘s’ harus lebih besar dari pada 0 (nol) dan ‘a’ adalah nilai
konstan. Dalam kasus ini, faktor menurun sedangkan ukuran modul
meningkat.
Untuk instruction-related faults adalah jumlah baris kode yang
ditulis dengan 2 (dua) komponen. Komponen pertama, dilambangkan
dengan ‘b’ adalah peluang bahwa setiap baris kode memiliki bug
didalamnya. Komponen kedua adalah peluang bahwa setiap modul
memiliki kesalahan dalam berinteraksi dengan baris kode yang lain dalam
modul tersebut. Oleh karena itu, untuk instruction-related faults
menggunakan perhitungan sebagai berikut:
33
Di(s) = b + c * s
Dimana, ‘c’ adalah nilai yang berasal dari faktor interaksi secara
empiris. Dan oleh karena itu total dari defect density adalah
D(s) = a/s + b + c * s
Untuk ukuran modul optimal yang dilambangkan dengan ‘Smin’,
dan perhitungan minimal defect density menjadi:
Smin = ��/�
‘Smin’ ditentukan oleh kemampuan dan keahlian programmer,
perhitungannya berkisar antara 200 hingga 400 LOC (Line Of Code)
tergantung dari bahasa yang digunakan.
4. Cyclomatic Complexity
Cyclomatic complexity mengukur jumlah aliran kontrol dalam suatu
modul. Teori yang mendasari adalah semakin banyak jumlah path yang
melalui modul, semakin tinggi kompleksitasnya. Perhitungan jumlah
cyclomatic complexity berdasarkan grafik, yang dilambangkan dengan
‘V(g)’ , dengan menghitung jumlah path didalam program.
Modul didefinisikan sebagai satu set kode yang dieksekusi dengan
memiliki satu masukan dan satu keluaran. Cyclomatic dapat dihitung
dengan dua cara yang memberikan hasil yang sama, baik dengan
menghitung jumlah node dan edge atau dengan menghitung jumlah binary
decision dalam hal ini percabangan, formula perhitungannya sebagai
berikut:
34
V(g) = e – n + 2.....(1)
V(g )= bd + 1.....(2)
Pada persamaan pertama dimana ‘g’ adalah grafik kontrol modul,
‘e’ adalah jumlah edge, dan ‘n’ adalah jumlah node. Persamaan kedua
dimana ‘bd’ adalah jumlah dari binary decision dalam grafik kontrol. Jika
terdapat lebih dari satu percabangan di setiap node-nya, maka
perhitungannya menjadi: jumlah cabang-1.
Menurut Aivosto (Salste,2012) suatu cyclomatic complexity yang
tinggi menunjukkan prosedur yang kompleks, sulit untuk dipahami, diuji
dan dipelihara. Ada hubungan antara cyclomatic complexity dan resiko
dalam prosedur. Hubungannya ditunjukkan dengan tabel dibawah ini:
Tabel 2. 5: Standar Nilai Kompleksitas Siklomatik
Nilai CC Tipe Prosedur Tingkat Resiko 1-4 Prosedur sederhana Rendah 5-10 Prosedur yang terstruktur dengan
baik dan stabil Rendah
11-20 Prosedur yang lebih kompleks Menengah 21-50 Prosedur yang kompleks dan
kristis Tinggi
>50 Rentan kesalahan, sangat mengganggu, prosedur tidak dapat diuji.
Sangat tinggi
Aivosto menetapkan pada mulanya standar nilai maksimum untuk
cyclomatic complexity adalah 10. Namun stndar nilai lain seperti 15 atau 20
juga sudah disarankan. (Salste, 2012) Terlepas dari standar tersebut, jika
nilai cyclomatic melebihi angka 20 maka harus dipertimbangkan bahwa
35
hasil tersebut mengkhawatirkan untuk resiko terjadinya kecacatan. Salah
satu pandangan menurut Aivosto (Salste,2012) mengenai probabilitas
dalam memperbaiki kesalahan berdasarkan nilai cyclomatic complexity
diantaranya:
Tabel 2. 6: Probabilitas Perbaikan
Nilai CC Probabilitas Perbaikan
1-10 5%
20-30 20%
>50 40%
Mendekati 100 60%
Menurut Laird dan Brennan cyclomatic complexity berguna untuk:
(Laird & Brennan, 2006)
• Mengidentifikasikan bagian-bagian yang terlalu kompleks dari kode yang
membutuhkan rancnagan pemeriksaan secara rinci.
• Mengidentifikasikan bagian-bagian tidak kompleks yang membutuhkan
inspeksi.
• Mengestimasi usaha pemeliharaan, mengidentifikasi kode yang
bermasalah, dan mengestimasi pengujian usaha.
36
5. Halstead’s Metric
Halstead Metik merupakan perhitungan yang didapat dari jumlah
“operator” dan “operan” yang terdapat dalam baris kode. Menghitung
jumlah “operator” dan “operan” yang terdapat dalam baris kode. Pada
tahun 1977, Halstead memperkenalkan metrik kompleksitas berdasarkan
jumlah dari operator dan operan dalam sebuah program. Operan ditandai
dengan nilai, seperti variabel dan konstanta. Operator ditandai dengan
koma, tanda kurung, operator aritmatika. Metrik Halstead didefinisikan
sebagai:
Length : N = N1+N2
Vocabulary : n = n1+n2
Volume : V = N(log2(n))
Difficulty : D = (n1/2) * (N2/n2)
Effort : E = D * V
Dimana:
n1 = jumlah operator yang berbeda dalam program
n2 = jumlah operan yang berbeda dalam program
N1 = total jumlah kemunculan operator dalam program
N2 = total jumlah kemunculan operan dalam program
37
6. Information Flow Metric
Metrik Information Flow mengukur aliran informasi yang masuk
dan keluar dari modul. Teori yang mendasari adalah bahwa jumlah aliran
informasi yang tinggi menunjukkan kurangnya atau bahkan tidak adanya
kohesi dalam perancangan, yang menyebabkan kompleksitas yang lebih
tinggi. Metrik Henry-Kafuramendefinisikan Information Flow Complexity
(IFC) dari sebuah modul dengan persamaan:
IFC = (fanin * fanout)2
Bobot IFC = panjang * (fanin*fanout)2
Dimana:
Fanin: Jumlah aliran lokal ke dalam modul ditambah jumlah struktur data
yang digunakan sebagai masukan.
Fanout: Jumlah aliran lokal ke luar dari modul ditambah jumlah struktur
data yang digunakan sebagai keluaran.
Length: Jumlah pernyataan dalam source di prosedur (termasuk komentar).
7. System Complexity
Perhitungan kompleksitas seluruh sistem dalam hal pemeliharaan
dan/atau desain secara keseluruhan.
• Maintainability Index
Pada tahun 1990, metrik yang disebut “Maintainability Index” merupakan
metrik gabungan antara LOC (Line Of Code), metrik Halstead, Cyclomatic
38
Complexity dan number of comment. Berikut ini adalah tabel kategori
pemeliharaan dengan skor masing-masing menurut Coleman dan timnya:
(Coleman, Ash, Lowther, & Oman, 1994)
Tabel 2. 7: Penilaian Maintainability Index untuk Pemeliharaan
Kategori Pemeliharaan
Skor MI
MI Tinggi 85 ≤ �
MI Medium 65 ≤ �< 85
MI Rendah �< 65
Perhitungan untuk maintainability index didefinisikan sebagai berikut:
MI = 171 – 5.2ln(aV) – 0.23aV(g’) – 16.2ln(aLOC) + 50sin[(2.4*perCM)1/2]
Dimana:
aV = nilai volume (V) per modul dari metrik Halstead
aV(g') = Cyclomatic Complexity per modul
aLOC = Line Of Code (LOC) per modul
perCM = number of comment yang bersifat opsional
• The Agresti-Card-Glass System Complecity Metric
Tujuan metrik The Agresti-Card-Glass System adalah untuk menguji
seberapa tinggi pengaruh desain dan arsitektur. Perhitungan ini
menggunakan kompleksitas intramodul dan kompleksitas intermodul.
39
Card, Agresti dan Glass mendefinisikan formula sebagai berikut: (Laird &
Brennan, 2006)
Ct = St + Dt
Dimana
Ct = total kompleksitas sistem
St = total kompleksitas struktural (intermodul)
Dt = total kompleksitas data model (intramodul)
St berdasarkan pada metrik Henry-Kafura (Henry & Kafura, 1981) tanpa
komponen fanin. Artinya:
�� � ∑��� ��� cvghbcncvhfnjdfg∑�cdA � πr^2
Dimana
f(i) = fanout modul i (penyimpanan data internal yang ditulis tidak
dihitung)
Dt adalah rata-rata dari semua pengukuran kompleksitas internal untuk
semua modul. Artinya, untuk setiap modul i:
�� � � � �
�� � ! "
Dan menjadi:
Dt = ∑ �� �#
40
Relative System Complexity (RSC) adalah normalisasi dari kompleksitas
sistem berdasarkan pada jumlah modul. RSC merupakan rata-rata
kompleksitas per modul. Berikut formula perhitungannya:
RSC = St/n + Dt/n
Dimana:
‘n’ adalah jumlah modul dalam sistem
4. Measuring Response Time (Pengukuran Waktu)
Pengukuran kecepatan reaksi (Measuring Response Time) adalah
jarak waktu antara permintaan pengguna dan kecepatan respon sistem.
Gambar 2.3: Waktu Respon Antara User Dengan Sistem (Laird & Brennan, 2006)
Gambar diatas masih belum disempurnakan. Yang menjadi masalah
adalah apakah perhitungan dilakukan pada saat pengguna pertama kali
memulai permintaan atau saat pengguna meng-klik tombol “Submit” . Di
bawah ini merupakan gambar yang sudah disempurnakan:
41
Gambar 2.4: Waktu Respon yang Lebih Rinci(Laird & Brennan, 2006)
Gambar diatas menetapkan 2 (dua) potensi pada kecepatan reaksi,
keduanya dimulai pada saat pengguna menekan tombol “submit” ,
sedangkan yang lainnya menyelesaikan proses pada saat sistem mulai
merespon dan yang lainnya menyelesaikan pada saat sistem selesai
merespon.
Perhatikan spesifikasi untuk kecepatan reaksi :
1. Kecepatan reaksi harus ≤ 8 detik.
2. Kecepatan reaksi diukur sejak pengguna menekan tombol “sumbit” ke
sistem dan memulai reaksi harus ≤ 8 detik.
3. Kecepatan reaksi diukur sejak pengguna menekan tombol “sumbit” ke
sistem dan memulai reaksi harus:
a. Maximum ≤ 30 detik
b. Rata-rata ≤ 6 detik
42
4. Kecepatan reaksi diukur sejak pengguna menekan tombol “sumbit” ke
sistem dan memulai reaksi harus:
a. 95 percentile≤ 8 detik
b. 100 percentile ≤ 30 detik
Untuk perhitungan response time diambil dari rata-rata kecepatan
reaksi per modul antara pengguna dengan sistem.
5. Measuring Availability (Pengukuran ketersediaan)
Availability merupakan pengukuran yang diperoleh dari
probabilitas sistem yang akan terpenuhi. Perhitungan availability di
rumuskan sebagai berikut:
Availability = $%%&
�$%%'($%%&�
Dimana:
MTTF: Uptime (Frekuensi terjadinya gangguan)
MTTR: Downtime (Durasi terjadinya gangguan)
Tabel 2. 8: Uptime dan Downtime dalam Periode Bulan dan Tahun
Uptime Downtime per- month
Downtime per- year
Uptime Downtime per- month
Downtime per- year
100% 99.999% 99.99% 99.9% 99.8% 99.7% 99.6% 99.5% 99.4%
0m 0.4m 4m 43m 1h 26m 2h 10m 2h 53m 3h 36m 4h 19m
0m 5m 52m 8h 46m 17h 31m 1d 2h 17m 1d 11h 2m 1d 19h 48m 2d 4h 34m
97.5% 97.4% 97.3% 97.2% 97.1% 97.0% 96.9% 96.8% 96.7%
18h 0m 18h 43m 19h 26m 20h 10m 20h 53m 21h 36m 22h 19m 23h 2m 23h 46m
9d 3h 0m 9d 11h 46m 9d 20h 31m 10d 5h 17m 10d 14h 2m 10d 22h 48m 11d 7h 34m 11d 16h 19m 12d 1h 5m
43
99.3% 99.2% 99.1% 99.0% 98.9% 98.8% 98.7% 98.6% 98.5% 98.4% 98.3% 98.2% 98.1% 98.0% 97.9% 97.8% 97.7% 97.6%
5h 2m 5h 46m 6h 29m 7h 12m 7h 55m 8h 38m 9h 22m 10h 5m 10h 48m 11h 31m 12h 14m 12h 58m 13h 41m 14h 24m 15h 7m 15h 50m 16h 34m 17h 17m
2d 13h 19m 2d 22h 5m 3d 6h 50m 3d 15h 36m 4d 0h 22m 4d 9h 7m 4d 17h 53m 5d 2h 38m 5d 11h 24m 5d 20h 10m 6d 4h 55m 6d 13h 41m 6d 22h 26m 7d 7h 12m 7d 15h 58m 8d 0h 43m 8d 9h 29m 8d 18h 14m
96.6% 96.5% 96.4% 96.3% 96.2% 96.1% 96.0% 95.9% 95.8% 95.7% 95.6% 95.5% 95.4% 95.3% 95.2% 95.1% 95.0%
1d 0h 29m 1d 1h 12m 1d 1h 55m 1d 2h 38m 1d 3h 22m 1d 4h 5m 1d 4h 48m 1d 5h 31m 1d 6h 14m 1d 6h 58m 1d 7h 41m 1d 8h 24m 1d 9h 7m 1d 9h 50m 1d 10h 34m 1d 11h 17m 1d 12h 0m
12d 9h 50m 12d 18h 36m 13d 3h 22m 13d 12h 7m 13d 20h 53m 14d 5h 38m 14d 14h 24m 14d 23h 10m 15d 7h 55m 15d 16h 41m 16d 1h 26m 16d 10h 12m 16d 18h 58m 17d 3h 43m 17d 12h 29m 17d 21h 14m 18d 6h 0m
Dari tabel diatas menunjukkan korespondensi antara sistem
availability dan downtime per-bulan dan per-tahun. Istilah “Five nines”
sama dengan 99.999 yang artinya sistem memiliki downtime selama 5.3
menit per-tahun. Biaya ketersediaan meningkat secara eksponensial dengan
setiap penambahan angka ‘9’.
44
6. Measuring Benefit (Pengukuran Keuntungan)
Sisi lain dari kasus bisnis adalah melihat manfaat yang diharapkan
dari proyek yang sudah dirancang. Untuk penjualan perangkat lunak
eksternal, diambil dari hasil penjualan yang diperkirakan.
Perkembangannya dapat dilihat dari tahun ke tahun, sebagai contoh:
Tabel 2. 9: Contoh Perhitungan Projected Revenue
Sales Region Year 1 Year 2 Year 3
North 2 sales @$50,000
each=$100,000
6 sales = $300,000 10 sales = $500,000
South 2 sales = $100,000 4 sales = $200,000 7 sales = $350,000
Total $200,000 $500,000 $850,000
Untuk perangkat lunak yang dikembangkan untuk penggunaan
internal, diperoleh dari penghematan biaya. Beberapa penghematan yang
diharapkan adalah:
- Mengurangi biaya tenaga kerja
- Mengurangi biaya kesalahan
- Mengurangi biaya pemakaian
Sebagai contoh, perhitungan dilakukan dengan penghematan 2 jam
per-hari. Maka dapat dilakukan perhitungan penghematan proyek dengan
mengambil nilai rata-rata setiap jam untuk teknisi yang akan menggunakan
perangkat lunak tersebut dan mengalikannya dengan jumlah dari staff
hours yang disimpan. Tabel dibawah adalah contoh dari perhitungan
45
projected saving, perhitungan dilakukan pada satu departemen di tahun
pertama, dan beberapa departemen di tahun kedua. Diasumsikan terdapat
240 hari produktif per tahun:
Tabel 2. 10: Contoh Perhitungan Projected Saving
Target Staff (Average
Rate=$20/h)
Year 1 Year 2
Department A-30 30 staff x 2h x 240days x $20/h=$288,000
$288,000
All other department-120
0 120 x 2 240 x $20 = $1,152,000
Total $288,000 $1,440,000
7. Measuring Return On Investment (Pengukuran Laba atas investasi)
Return On Investment adalah salah satu dari beberapa langkah yang
dapat digunakan dalam kasus bisnis untuk membandingkan peluang
investasi yang berbeda. Perhitungan ROI :
ROI = Net Benefits / Investment
Net Benefits = Benefits – Costs
Periode pengembalian modal untuk setiap proyek adalah lamanya
waktu yang diperlukan untuk memulihkan investasi, yaitu untuk menekan
titik impas. Yang menjadi target adalah titik impas atau Breakeven Point
dimana net benefit sama dengan net costs. Gambar dibawah menunjukkan
secara grafis bagaimana titik impas dan periode pengembalian modal dapat
terlihat.
46
Gambar 2.5: Breakeven Point dan Payback Periode
(Laird & Brennan, 2006)
8. Measuring Risk (Pengukuran Resiko yang Berkaitan dengan
Ancaman)
Manajemen risiko mencakup identifikasi, penilaian, perencanaan, dan
pemantau pemicu risiko dan rencana mitigasi yang terkait dengan proyek
perangkat lunak.
1. Identifikasi
Ada beberapa jenis risiko yang dapat dikaitkan dengan proyek-proyek
pengembangan perangkat lunak. Diantaranya bisnis, kontrak, biaya,
penjadwalan, teknis, dan risiko kepuasan pelanggan. Risiko jika tidak
diatasi, dapat memperngaruhi keberhasilan proyek. Barry Boehm
memaparkan 10 (sepuluh) jenis risiko teratas terhadap proyek perangkat
lunak, diantaranya: (Laird & Brennan, 2006)
47
Tabel 2. 11: Sepuluh Jenis Risiko Teratas menurut Boehm
1. Personel Shortfalls
2. Unrealistics schedules and budgets
3. Developing the wrong software function
4. Developing the wrong user interface
5. Gold-plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished tasks
8. Shortfalls in externally furnished components
9. Real-time performance shortfalls
10. Straining computer science capabilities
2. Penilaian
Setiap risiko yang diidentifikasi harus dikaji untuk memahami
kemungkinan yang akan terjadi, dan apa tindakan ynag mungkin untuk
mengurangi kemungkinan terjadinya atau dampak luasnya. Untuk setiap
risiko yang diidentifikasi, biaya yang terkait dengan risiko dan terjadinya
probabilitas harus diperkirakan sehingga tim proyek dapat membuat pilihan
tentang apa dan bagaima cara untuk menerima, menghindari, atau
mengurangi masing-masing risiko.
3. Risiko Perencanaan
Pada tahap ini tim memiliki pandangan yang jelas tentang potensi risiko
dan menetapkan strategi untuk menghadapi risiko. Biaya yang berkaitan
48
dengan aksi perencanaan dapat dirangkum dan dimasukkan ke dalam total
biaya proyek.
Ada sejumlah cara untuk rencana resiko yang dapat diukur. Cara
pertama dengan melihat resiko kualitatif dalam bentuk probabilitas,
dampak, dan kemampuan untuk mengurangi dan menetapkan kategori
resiko (rendah, sedang atau tinggi). Setelah biaya langsung ditetapkan,
faktor resiko akan diterapkan dan ditambahkan ke total biaya proyek.
Sebagai contoh, berikut tabelnya:
Tabel 2. 12: Contoh Perhitungan Risiko Kualitatif
Risk Item Probability of Occurrence
Impact Risk Assessment
Loss of jey resource
20% High Medium
More than 25% requirements growth after design starts
40% High High
Development environment
unavailability>10%
10% Moderate Low
New technology delivered to project late
10% High Medium
Overall qualitative risk
Medium(=20%risk factor)
Total risk cost $500K*20%=$100,000
49
Cara kedua yaitu secara khusus mengukur setiap risiko dari segi
estimasi biaya kejadian, probabilitas, dan estimasi biaya mitigasi. Berikut
adalah contoh perhitungannya:
50
Tabel 2. 13: Kualifikasi Risiko
Risk Item Cost Of Occurrence Probability Of
Occurrence
Cost of risk Acceptance
Mitigation Action
Cost of Mitigation
Probability After
Mitigation
Total Cost
Lost of key resource
1month delay in overall development=20days x 30staff x ($640per staff day)=$384,000
20% $384,000 x 20%=$76,800
Train backup in this area
10days x 2staff = 12,800
0% $21,800
Required hardware delivered late
1 week delay in overall development=$96,000
30% $96,000 x 30%=$28,800
Place delivery penalty in subcontract
None 5% $4,800
Contractual throughput measure not achieved
Penalty clause in contract invoked=$500,000
25% $125,000 Instrument code for early measurement and correction
$20,000 5% $20,000+($500,000 x 5%)=$45,000
Total $230,600 $32,800 $62,600
4. Pemantauan Risiko
Risiko yang berhubungan dengan perubahan proyek dari waktu ke waktu.
Beberapa proyek mengalami perubahan dan bahkan sampai mengeluarkan
biaya di luar dugaan. Yang perlu dicatat adalah perancanaan risiko harus
ditinjau dan diperbarui secara berkala.
9. Measuring Cost and Effort (pengukuran biaya berdasarkan usaha)
Untuk pengukuran biaya berdasarkan usaha perangkat lunak,
penelitian ini menggunakan teori dari Riyanarto Sarno dan timnya dalm
makara yang berjudul “Pengembangan Metode Analogy Untuk Estimasi
Biaya Rancang Bangun Perangkat Lunak”. (Sarno, Buliali, & Maimunah,
2002)
Sebelum menentukan estimasi biaya, terlebih dahulu harus
mengestimasi besarnya usaha, karena usaha merupakan komponen biaya
utama yang berpengaruh pada hampir semua objek biaya. Sebelum
menentukan teknik estimasi biaya pada suatu proyek pengembangan
perangkat lunak, dilakukan tahapan berikut :
1. Penentuan nilai 3D Function Point (FP)
Mengidentifikasi fungsi-fungsi sebagai parameter proyek yang disesuaikan
dengan permintaan pemakaian antara lain : output, input, files, inquiries,
interfaces. Setelah masing-masing dikelompokkan dan dihitung, diberi
bobot sesuai dengan tingkat kompleksitasnya. Nilai total seluruh fungsi
disebut nilai Unadjasted Function Points (UFP). Kemudian
mengidentifikasi karakteristik aplikasi. Nilai FP dihitung dengan
megkalikan nilai UFP dan nilai faktor teknis kompleksitas (Adjusted
Factor / AF). Selanjutnya nilai FP yang telah diketahui dapat dikonversi ke
jumlah Source Line of Code (SLOC) yang ekivalen. Konversi dapat
dilakukan dengan menggunakan table ekivalensi bahasa pemrograman.
Tabel 2. 14: Tabel LOC Berdasarkan Bahasa Pemrograman
Bahasa
SLOC per FP
C++ default 53
Cobol default 107
Delphi 5 17
HTML 14
Visual Basic 6 24
SQL default 13
Java 2 default 46
2. Kalkulasi penggunaan kembali perangkat lunak yang ada dan komponen-
komponen serta komersial pustaka. Dalam menentukan similaritas
digunakan metode Nearest Neighbour Algorithm. Metode ini merupakan
algoritma umum yang didasarkan pada pengukuran jarak tiap-tiap
parameter.
3. Estimasi usaha atau effort (E) dengan menggunakan metode analogi yang
telah dimodifikasi. Mengestimasi effort proyek baru dapat dilakukan
dengan mencari proyek serupa sebagai acuan, untuk itu dapat digunakan
persamaan
Y = ax1 + bx2 + cx3
Dimana:
Y adalah nilai estimasi effort dan x1, x2, x3, ...., xn adalah parameter-
parameter proyek, misalnya: input, output, inquiry, file.
4. Penentuan waktu yang diperlukan (td)
Setelah nilai usaha didapatkan, waktu yang diperlukan dapat dihitung
dengan persamaan :
td = SM * (E)0.33
Dimana :
td : Waktu yang diperlukan (months)
E : Effort atau Usaha
SM : Schedule Multiple yang dapat dilihat nilainya pada tabel dibawah ini.
Tabel 2. 15: Table Faktor untuk konversi
Project Type Schedule Multiple
COCOMO II default 3.67
Embedded Development
4.00
E-Commerce Development
3.19
Web Development 3.10
Military Development 3.80
5. Penentuan biaya proyek
Biaya proyek dapat dihitung dengan persamaan :
Biaya produksi = BFS + BFD + BMB + BT +BM +BD
Estimasi biaya = biaya produksi * (1 + pajak)
Dimana
BFS : biaya studi kelayakan
BFD : biaya desain fungsi
BMB : biaya pemrograman
BT : biaya training
BM : biaya pemeliharaan
BD : biaya dokumentasi
� Biaya studi kelayakan (BFS)
Beberapa komponen yang mempengaruhi biaya aktifitas studi kelayakan
antara lain:
� Waktu untuk studi kelayakan (tFeas)
tFeas = td / 4
� Usaha atau effort untuk studi kelayakan (EFeas)
EFeas = MPFeas * td / 4
MPFeas : jumlah orang untuk studi kelayakan
� Biaya tenaga kerja untuk studi kelayakan (CFS)
CFS = EFeas * UR
UR : Upah Regional
� Biaya listrik untuk studi kelayakan (CLFs) dapat diperoleh dengan
persamaan:
CLFs = EFeas * L Rp
Dimana
LKomp : ongkos listrik per unit komputer lengkap
LRp : ongkos listrik per unit komputer per bulan
� Biaya konsumsi untuk studi kelayakan (CKFs)
CKFs = EFeas * KRp
Dimana
KRp : biaya konsumsi per orang per bulan
� Biaya overhead untuk studi kelayakan (BOFs)
BOFs = CGfs + CDfs + CTfs + CAfs
CGfs = EFeas * GRp
CDfs = EFeas * DRp
CTfs = EFeas * TRp
CAfs = EFeas * ARp
Dimana
CGfs: biaya gedung dan listrik
CDfs: biaya depresiasi mesin
CTfs: biaya telpon
CAfs: biaya asuransi
GRp: biaya sewa gedung dan ongkos listrik per orang per bulan
DRp: biaya depresiasi mesin per bulan
TRp: biaya telpon per orang per bulan
ARp: biaya asuransi per orang per bulan
Jadi, biaya total studi kelayakan adalah:
BFS = CFS + CLFs + CKFs + BOFs
� Biaya desain fungsi (BFD)
Beberapa komponen yang mempengaruhi biaya aktifitas desain fungsi
antara lain:
• Waktu yang diperlukan untuk desain fungsi (tFD)
tFD = td / 3
• Effort yang diperlukan untuk desain fungsi (EFD) sebanding dengan
estimasi effort: sesuai dengan SLOC.
• Jumlah orang yang diperlukan untuk desain fungsi (MPFD)
MPFD =EFD / tFD
• Biaya tenaga kerja untuk desain fungsi (CFD)
CFD = EFD * UR
• Biaya listrik untuk desain fungsi (CLFD)
• Biaya konsumsi untuk desain fungsi (CKFD)
• Biaya overhead untuk desain fungsi (BOFD)
Jadi, biaya total desain fungsi adalah:
BFD = CFD + CLFD + CKFD + BOFD
� Biaya pemrograman & implementasi (BMB)
Beberapa komponen yang mempengaruhi biaya aktifitas pemrograman
antara lain:
• Jumlah orang yang diperlukan untuk pemrograman (MP)
MP = E / td
• Biaya tenaga kerja untuk pemrograman (CMB)
CMB = UR * E
• Biaya listrik untuk pemrograman (CLMB)
• Biaya konsumsi untuk pemrograman (CKMB)
• Biaya overhead untuk pemrograman (BOMB)
Jadi, biaya total pemrograman adalah:
BMB = CMB + CLMB + CKMB +BOMB
� Biaya training (BT)
Beberapa komponen yang mempengaruhi biaya aktifitas training antara
lain:
• Effort yang diperlukan untuk training (ET) diasumsikan sama dengan
effort untuk pemrograman: ET =E
• Waktu yang diperlukan untuk training (tT)
• Jumlah orang yang diperlukan untuk training (MPT): MPT = ET / tT
• Biaya tenaga kerja untuk training (CT) dapat diperoleh dengan
menggunakan persamaan CMB dengan penyesuaian nilai ET dan tT
• Biaya listrik untuk training (CLT)
• Biaya konsumsi untuk training (CKT)
• Biaya overhead untuk training (BOT)
Jadi, biaya total training adalah:
BT = CT + CLT + CKT + BOT
� Biaya pemeliharaan (BM)
Beberapa komponen yang mempengaruhi biaya aktifitas pemeliharaan
antara lain:
• Effort yang diperlukan untuk pemeliharaan (EM) diasumsikan sama
dengan 15% dari effort untuk pemrograman sebab effort untuk
pemeliharaan mempunyai range antara 12 sampai 17 persen dari effort
pengembangan.
EM = 0.15 * E
• Waktu yang diperlukan untuk pemeliharaan (tM)
tM = td
• Jumlah orang yang diperlukan untuk pemeliharaan (MPM)
MPM = EM / tM
• Biaya tenaga kerja untuk pemeliharaan (CM) dapat diperoleh dengan
persamaan BMB dengan penyesuaian nilai EM dan tM.
• Biaya listrik untuk pemeliharaan (CLM)
• Biaya konsumsi untuk pemeliharaan (CKM)
• Biaya overhead untuk pemeliharaan (BOM)
Jadi, biaya total pemeliharaan adalah:
BM = CM + CLM + CKM + BOM
� Biaya dokumentasi (BD)
Jumlah halaman dokumentasi dari suatu proyek dapat diprediksi dengan
menggunakan effort pengembangan sebagai input. Persamaan yang
digunakan untuk mendapatkan jumlah halaman dokumentasi (Pages)
tersebut adalah:
Pages = ∑�) ! * +, �
Dimana:
A, B, C : konstanta penentuan jumlah halaman
i : macam dikumen yang harus dibuat
DocRp : biaya pembuatan dokumentasi per halaman
Jadi, biaya dokumentasi proyek adalah:
BD = DocRp * Pages
2.5Unified Modeling Language (UML)
Unified Modeling Language (UML) yang digunakan dalam penelitian ini
diambil dari teori Scott W.Ambler,diantaranya:(Ambler, 2005)
1. Use Case Diagram
Use case diagrammenunjukkan hubungan antara aktor dengan use case
pada sebuah sistem.Dibawah ini merupakan contoh dari use case diagram:
Gambar 2. 6: Contoh Use Case Diagram(Ambler, 2005)
Use case menekankan pada aktifitas apa yang bisa dilakukan oleh aktor.
Diluar use case terdapat aktor yang digambarkan dengan istilah “stick man”.
Selain aktor, terdapat sebuah communication line dan system boundaries untuk
menggambarkan use case diagram secara utuh. Communication line
menghubungkan aktor dan use case untuk menunjukkan bahwa aktor tersebut
berpartisipasi di dalam use case. System boundaries digunakan untuk
menandakan pemisahan antara eksternal sistem (aktor) dan internal sistem (use
case), seperti pada contoh dibawah ini:
Gambar 2. 7: Contoh Use Case Diagram dengan Communication Line dan System Boundaries(Ambler, 2005)
2. Activity Diagram
Activity diagram merupakan diagram yang menunjukkan aliran proses
yang dilakukan oleh sistem. Inisial “start” pada activity diagram digambarkan
dengan lingkarang berwarna hitam yang artinya proses akan memulai eksekusi
dan inisial “stop” digambarkan dengan titik hitam yang dikelilingi lingkaran
hitam yang artinya proses telah selesai dieksekusi. Berikut ini adalah contoh
activity diagram:
Gambar 2.8: Contoh Activity Diagram(Ambler, 2005)
3. Conceptual Class Diagram
Conceptual class diagram merupakan dasar dari perancangan sequence
diagram dan class diagram. Conceptual class diagram menentukan kelas-kelas
apa saja yang dibutuhkan dan hubungan antar kelas.
Gambar 2.9: Contoh Conceptual Class Diagram(Ambler, 2005)
4. Sequence Diagram
Sequence diagram merupakan gambaran komunikasi yang dinamis antar
bagian-bagian dari sistem. Dengan menggunakan sequence diagram,
pengembang bisa menjelaskan urutan interaksi apa yang akan dipanggil ketika
sebuah use case dieksekusi. Berikut adalah contoh sequence diagram:
Gambar 2.10: Contoh Sequence Diagram(Ambler, 2005)
5. Attribute Conceptual Class
Attribute conceptual class adalah proses menetapkan attribute yang dimiliki oleh kelas tersebut. Berikut adalah contoh attribute conceptual class:
Gambar 2.11: Contoh Attribute Conceptual Class (Ambler, 2005)
6. Class Diagram
Class diagram merupakan diagram yang menggambarkan hubungan antar
kelas yang berisi attribute dan operation pada masing-masing kelas. Class dalam
UML digambarkan sebagai persegi panjang dibagi menjadi tiga bagian. Bagian
paling atas berisi nama class, bagian tengah berisi attribute yang dimiliki oleh
kelas tersebut, dan bagian akhir berisi operation yang menunjukkan behaviour
dari kelas. Berikut adalah contoh dari class diagram:
Gambar 2.12: Contoh Class Diagram(Ambler, 2005)
2.6 Perancangan Antarmuka Pengguna
Untuk merancang antar muka yang baik digunakan pedoman delapan aturan
emas menurut Shneiderman diantaranya:(Shneiderman, 2005)
1. Konsisten
Konsisten dilakukan pada urutan tindakan, perintah dan istilah yang
digunakan pada prompt, menu, serta layar bantuan.
2. Memungkinkan pengguna untuk menggunakan shortcut
Ada kebutuhan dari pengguna yang sudah ahli untuk meningkatkan
kecepatan interaksi, sehingga diperlukan singkatan, tombol fungsi, perintah
tersembunyi, dan fasilitas makro.
3. Memberikan umpan balik yang informatif
Untuk setiap tindakan operator, sebaiknya disertakan suatu sistem
umpan balik. Untuk tindakan yang sering dilakukan dan tidak terlalu penting,
dapat diberikan umpan balik yang sederhana. Tetapi ketika tindakan merupakan
hal yang penting, maka umpan balik sebaiknya lebih substansial. Misalnya
muncul suatu suara ketika menekan tombol pada waktu input data atau muncul
pesan kesalahannya.
4. Merancang dialog untuk menghasilkan suatu penutupan
Urutan tindakan sebaiknya diorganisir dalam suatu kelompok dengan
bagian awal, tengah, dan akhir. Umpan balik yang informatif akan memberikan
indikasi bahwa cara yang dilakukan sudah benar dan dapat mempersiapkan
kelompok tindakan berikutnya.
5. Memeberikan penanganan kesalahan
Sedapat mungkin sistem dirancang sehingga pengguna tidak dapat
melakukan kesalahan fatal. Jika kesalahan terjadi, sistem dapat mendeteksi
kesalahan dengan cepat dan memberikan mekanisme yang sederhana dan
mudah dipahami untuk penanganan kesalahan.
6. Mudah kembali ke tindakan sebelumnya
Hal ini dapat mengurangi kekhawatiran pengguna karena pengguna
mengetahui kesalahan yang dilakukan dapat dibatalkan, sehingga pengguna
tidak takut untuk mengeksplorasi pilihan-pilihan lain yang belum biasa
digunakan.
7. Mendukung tempat pengendali internal
Pengguna ingin menjadi pengotrol sistem dan sistem akan merespon
tindakan yang dilakukan pengguna daripadapengguna merasa bahwa sistem
mengotrol pengguna. Sebaiknya sistem dirancang sedemikian rupa sehingga
pengguna menjadi inisiator daripada responden.
8. Mengurangi beban ingatan jangka pendek
Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana
atau banyak tampilan halaman yang sebaiknya disatukan, serta diberikan cukup
waktu pelatihan untuk kode dan urutan tindakan.