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 atributatribut 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
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.
Total
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? Apakah aplikasi didesain dan dikembangkan untuk memudahkan pengguna?
10. Reusability
11.Conversion Ease
/
Installation
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
QSM SLOC/FP Language
Avg
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, perminggu, 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 1-4 5-10 11-20 21-50 >50
Tipe Prosedur Prosedur sederhana Prosedur yang terstruktur dengan baik dan stabil Prosedur yang lebih kompleks Prosedur yang kompleks dan kristis Rentan kesalahan, sangat mengganggu, prosedur tidak dapat diuji.
Tingkat Resiko Rendah Rendah Menengah Tinggi 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
bermasalah, dan mengestimasi pengujian usaha.
kode
yang
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 100% 99.999% 99.99% 99.9% 99.8% 99.7% 99.6% 99.5% 99.4%
Downtime per- month 0m 0.4m 4m 43m 1h 26m 2h 10m 2h 53m 3h 36m 4h 19m
Downtime per- year 0m 5m 52m 8h 46m 17h 31m 1d 2h 17m 1d 11h 2m 1d 19h 48m 2d 4h 34m
Uptime 97.5% 97.4% 97.3% 97.2% 97.1% 97.0% 96.9% 96.8% 96.7%
Downtime per- month 18h 0m 18h 43m 19h 26m 20h 10m 20h 53m 21h 36m 22h 19m 23h 2m 23h 46m
Downtime peryear 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
6 sales = $300,000
10 sales = $500,000
each=$100,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) Department A-30 All other department-120 Total
Year 1
30 staff x 2h x 240days x $20/h=$288,000 0 $288,000
Year 2
$288,000 120 x 2 240 x $20 = $1,152,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 Loss of jey resource More than 25% requirements growth after design starts Development environment unavailability>10 % New technology delivered to project late Overall qualitative risk Total risk cost
Probability of Occurrence 20%
Impact High
Risk Assessment Medium
40%
High
High
10%
Moderate
Low
10%
High
Medium
Medium(=20 %risk factor) $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 in 20%
Lost of key 1month delay resource overall development=20days x 30staff x ($640per staff day)=$384,000 Required 1 week delay in 30% hardware overall delivered development=$96,000 late Contractual Penalty clause in 25% throughput contract measure invoked=$500,000 not achieved Total
Cost of risk Acceptance
Mitigation Action
Cost of Probability Total Cost Mitigation After Mitigation $384,000 x Train backup 10days x 0% $21,800 20%=$76,800 in this area 2staff = 12,800
$96,000 x Place None 30%=$28,800 delivery penalty in subcontract $125,000 Instrument $20,000 code for early measurement and correction $230,600 $32,800
5%
$4,800
5%
$20,000+($500, 000 x 5%)=$45,000
$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 komponenkomponen 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 parameterparameter 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 * LRp 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.
