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.