6

BAB 2

LANDASAN TEORI

2.1 Proses Perencanaan

2.1.1 Pengertian Rencana

Menurut Humphrey (2002, pp59-99), rencana proyek mendefinisikan pekerjaan

dan bagaimana pekerjaan tersebut akan dilakukan. Rencana proyek memberikan definisi

dari setiap tugas utama, perkiraan dari waktu dan sumber yang diperlukan dan kerangka

kerja untuk meninjau ulang manajemen dan kontrol. Rencana proyek adalah juga suatu

alat belajar yang berguna. Apabila didokumentasikan dengan benar, rencana proyek

adalah suatu alat untuk membandingkan dengan kinerja sebenarnya. Perbandingan ini

membuat perencana untuk melihat kesalahan mereka dan untuk memperbaiki ketepatan

perkiraan mereka.

Dalam organisasi pengembang software yang matang, rencana khususnya

digunakan sebagai:

• Dasar untuk menyetujui biaya dan jadwal untuk sebuah pekerjaan.

• Struktur perencana untuk melakukan pekerjaan

• Kerangka kerja untuk mendapatkan sumber yang dibutuhkan

• Sebuah catatan dari apa yang pertama kali dilakukan

7

Pada singkatnya, rencana adalah langkah penting utama dalam membuat sebuah

proyek karena tanpa rencana yang baik, tidak mungkin dapat dilakukan pengaturan

proyek software yang efektif.

2.1.2 Isi dari Rencana Proyek Software

Isi dari rencana pengembangan software dapat beraneka ragam, namun setiap

rencana pengembangan software memiliki kandungan beberapa hal, antara lain:

• Ukuran pekerjaan: seberapa besar pekerjaannya, berapa lama waktu yang

dibutuhkan untuk mengerjakannya.

• Struktur pekerjaan: bagaimana pekerjaan akan dilakukan dan bagaimana

cara melakukannya.

• Status pekerjaan: bagaimana mengetahui status/tahapan dari pekerjaan

yang sedang berlangsung, apakah perkerjaan tersebut dapat diselesaikan

sesuai jadwal atau tidak.

• Penaksiran: penilaian tentang rencana yang telah disusun, apakah rencana

tersebut mengandung kesalahan dan bagaimana menghindari kesalahan

dalam perencanaan dimasa yang akan datang untuk hasil yang lebih baik

di lain waktu.

2.1.3 Merencanakan Sebuah Proyek Software

Adapun langkah-langkah yang dapat digunakan untuk membangun sebuah

proses estimasi yang efektif dan stabil adalah sebagai berikut:

8

• Mulai dengan pernyataan kebutuhan (requirement) yang eksplisit yang

harus dikerjakan dan memastikan pernyataan-pertanyaan kebutuhan

tersebut telah sesuai dengan keinginan customer.

• Untuk proyek dengan skala besar, setiap pekerjaan harus dipecah menjadi

pekerjaan-pekerjaan yang lebih kecil, sehingga memudahkan dalam

membuat perencanaan dan perkiraan dari setiap pekerjaan.

• Perkiraan dapat dibuat berdasarkan pengalaman pekerjaan yang sejenis di

masa lampau.

• Setiap perkiraan harus dicatat dan disimpan, untuk kemudian

dibandingkan dengan hasil sebenarnya, sehingga dapat diketahui

keakuratan perkiraan tersebut.

• Dalam perencanaan digunakan dua macam alat yaitu PERT dan cost

model, PERT adalah suatu sistem penjadwalan jalur kritis untuk

menganalisa pekerjaan yang terdiri dari tugas-tugas ganda yang saling

terkait satu sama lain. PERT menganalisa semua data proyek dan

mengidentifikasikan pengaturan dari tugas sehingga dapat dihasilkan

jadwal pengerjaan yang paling cepat. Sedangkan cost models, seperti

COCOMO dan PriceS, memproduksi proyeksi rencana terstandarisasi

berdasarkan pada data historis yang sudah ada.

9

Gambar 2.1 Kerangka Kerja Perencaan Proyek

2.2 Menghitung Ukuran Software

Menurut Humphrey (2002, pp90-91), untuk menghitung ukuran sebuah software,

terdapat 2 cara yang dapat dilakukan yaitu menghitung baris source code secara logik

dan secara fisik.

Perhitungan baris secara logik adalah menghitung jumlah statement pada listing

program yang diakhiri dengan titik koma, titik dua dan titik harus dihitung.

Sedangkan perhitungan baris secara fisik adalah perhitungan baris dengan

mengabaikan komentar dan baris kosong atau menghitungnya secara terpisah. Baris

10

yang mempunyai komentar dan source code sekaligus dihitung sebagai baris kode dan

baris komentar.

Dalam menghitung baris fisik, semua baris kode sumber dalam suatu unit

program harus dihitung. Namun seringkali diinginkan untuk menghitung elemen-elemen

program. Sebagai contoh, pemanggilan prosedur yang baru dikembangkan, maka

diperlukan pula jumlah baris yang dimiliki oleh setiap prosedur tersebut.

Dalam menghitung LOC fisik, definisi data serta baris eksekusi seperti if, then,

else serta rumus matematika juga tidak dihitung.

Tabel dibawah ini menunjukkan keakuratan dari setiap LOC counter dengan

skala 1 sampai 4 dimana 1 menunjukkan sangat akurat dan 4 paling tidak akurat.

Tabel 2.1 Skala Keakuratan Perhitungan LOC

Skala keakuratan Jenis LOC counter

1 Count logik dengan bantuan tool.

2 Count logik tanpa bantuan tool.

3 Count fisik dengan bantuan tool.

4 Count fisik tanpa bantuan tool.

Dari tabel diatas dapat disimpulkan bahwa, LOC counter logik lebih akurat

dibandingkan dengan LOC counter fisik.

Selain perhitungan ukuran baris, terdapat juga perhitungan dengan menghitung

jumlah function point dalam software. Jumlah function point diperoleh dari perhitungan

ukuran langsung informasi utama software dan penaksiran kompleksitas software

(Pressman, 2001, p89). Informasi utama tersebut mencakup jumlah file internal,

eksternal, input, output, dan inquiry. Lain halnya dengan pengukuran berdasarkan LOC,

11

pengukuran berdasarkan function point pada awalnya memang dirancang untuk

diaplikasikan pada sistem informasi bisnis sehingga tidak sesuai untuk sistem

engineering atau embedded system.

Jadi pada dasarnya, perhitungan berdasarkan function point merupakan suatu

cara untuk mengukur ukuran fungsionalitas secara langsung yang dihasilkan oleh suatu

aplikasi karena diturunkan dengan menggunakan hubungan pada ukuran langsung

informasi utama software dengan penaksiran kompleksitasnya.

2.3 Teori Fuzzy

2.3.1 Fuzzy Logic

Menurut http://en.wikipedia.org/wiki/Fuzzy_logic, fuzzy logic adalah perluasan

dari boolean logic yang berhubungan dengan konsep kebenaran sebagian. Dalam logika

klasik dikatakan bahwa semuanya dapat dinyatakan dalam istilah binary (0 atau 1, hitam

atau putih, ya atau tidak), fuzzy logic menggantikan nilai kebenaran boolean dengan

derajat kebenaran.

Fuzzy logic memperbolehkan untuk rangkaian nilai antara dan meliputi nilai 0

dan 1, warna abu-abu antara hitam dan putih, dan sebagainya. Fuzzy logic diperkenalkan

pertama kali pada tahun 1965 oleh Prof. Lofti Zadeh di University of Califonia,

Berkeley.

12

2.3.2 Fuzzy Set

Menurut http://en.wikipedia.org/wiki/Fuzzy_set, fuzzy set adalah perluasan dari

teori set klasik dan digunakan dalam fuzzy logic. Dalam set teori klasik, anggota dari

elemen yang berhubungan dengan set dinyatakan dalam istilah binary sesuai dengan

kondisi nyata, yaitu suatu elemen adalah milik suatu set atau tidak milik set tersebut.

Sedangkan pada teori fuzzy set memperbolehkan penaksiran yang berangsur-angsur dari

keanggotaan elemen dalam hubungannya dengan suatu set. Fuzzy set dengan set klasik

X dinyatakan sebagai berikut:

Fungsi keanggotaan µA (x) mengukur tingkatan dari keanggotaan elemen x ke

dalam set fundamental X. Nilai 0 berarti bahwa anggota tidak berada dalam set yang

diberikan, 1 menjelaskan anggota yang jelas termasuk. Nilai-nilai antara 0 dan 1

mencirikan anggota fuzzy.

Gambar 2.2 Fuzzy Set dan Crisp Set

13

2.3.3 Defuzzifikasi

Menurut http://en.wikipedia.org/wiki/Defuzzification, defuzzifikasi adalah proses

yang memberikan hasil yang dapat diukur dalam fuzzy logic. Secara khusus, sebuah

sistem fuzzy mempunyai beberapa aturan yang akan mengubah sejumlah variabel

menjadi hasil fuzzy, oleh karena itu hasilnya akan disebut fuzzy set. Suatu teknik

defuzzifikasi yang berguna harus pertama kali menambahkan hasil dari aturan-aturan

bersama. Jenis fungsi keanggotaan fuzzy set yang paling sering adalah berbentuk

segitiga. Jika segitiga ini dipotong dengan garis lurus horizontal antara atas dan bawah,

dan bagian atasnya dibuang, maka sisa dari bagian tersebut akan berbentuk trapezoid.

Tahap pertama dalam defuzzifikasi adalah memotong bagian dari grafik untuk

membentuk trapezoid. Dalam semua teknik umum, semua trapezoid ini akan kemudian

dilapis keatas satu dengan lainnya menghasilkan sebuah bentuk geometris. Lalu centroid

dari bentuk ini, yang dinamakan fuzzy centroid dihitung. Koordinat x dari centroid ini

adalah nilai yang telah difuzzifikasi.

2.4 Teknik Analisis Regresi

Teknik analisis regresi digunakan dalam mengolah data yang telah dikumpulkan

melalui kuesioner untuk menghasilkan sebuah model persamaan regresi yang akan

digunakan untuk melakukan estimasi usaha dan biaya.

14

2.4.1 Model Persamaan Regresi

Dalam teknik analisis regresi, tedapat dua variabel, yaitu X dan Y dimana X

disebut sebagai variabel independen dan variabel terkontrol karena nilai X dapat

ditentukan sendiri. Sedangkan Y disebut sebagai variabel dependen karena

ketergantungannya pada variabel X (Kreyszig, 1999, p1145).

Untuk menghitung koefisien regresi a digunakan rumus sebagai berikut:

( )( ) ( )( )( )22

2

XXnXYXXa

∑−∑∑∑−∑Υ∑

=

Sedangkan untuk menghitung koefisien regresi b digunakan rumus berikut:

( )( )( )22 XXn

YXXYnb∑−∑

∑∑−∑=

Model persamaan regresi :

bXaY +=ˆ

Dimana :

n = Jumlah sampel

X = Skor variabel X

Y = Skor variabel Y

2.4.2 Model Biaya Berdasarkan Regresi

Menurut Kemerer (1997, pp231-232), dalam mengembangkan suatu model biaya

yang berbasis regresi dibutuhkan pengumpulan data khususnya untuk hubungan dari

kenaikan antara ukuran software dan usaha yang dibutuhkan untuk mengerjakannya.

15

Data diambil dari proyek yang sudah ada sehingga dapat diturunkan suatu persamaan

regresi untuk menjelaskan deviasi dari biaya proyek sebenarnya dengan biaya yang

diprediksikan oleh persamaan regresi.

Pendekatan yang sering digunakan dalam model biaya berdasarkan regresi

adalah dengan menurunkan suatu persamaan linear dimana terdapat perbandingan lurus

antar ukuran software dengan usaha yang dibutuhkan, sehingga semakin besar ukuran

suatu software maka semakin besar pula usaha yang dibutuhkan untuk membuat

software tersebut.

Hal yang juga perlu diperhatikan dalam model biaya berbasiskan regresi adalah

untuk mengidentifikasi faktor penyebab perbedaan antara usaha yang diprediksi dan

usaha sebenarnya. Penyebab perbedaannya dapat disebabkan oleh stabilitas dari

requirement, keakraban tim dengan aplikasi, serta keterlibatan pengguna pada masa

pengembangan.

2.5 Mengestimasi Ukuran Software

2.5.1 Hubungan Sumber-Ukuran (Size-Resource Relationship)

Menurut Humphrey (2002, pp99-100), ukuran adalah alat untuk memprediksi

sumber-sumber yang akurat yang dibutuhkan untuk mengembangkan sebuah produk.

Hubungan antara ukuran dengan sumber-sumber yang dibutuhkan telah mengantar

kepada pengembangan beberapa cost model seperti COCOMO, PriceS dan SLIM.

Model ini juga membutuhkan sebuah estimasi ukuran sebagai input. Sebelum

menggunakan sebuah cost model terlebih dahulu harus dilakukan proses estimasi ukuran

produk. Oleh karena itu keakuratan dari cost model juga terbatas pada akurasi dari

16

estimasi ukuran. Jadi walaupun menggunakan cost model yang akurat, estimasi ukuran

yang akurat juga sangat dibutuhkan.

2.5.2 Metode Estimasi Function Point Analysis

Function Point Analysis adalah suatu metode estimasi yang didasarkan pada

perhitungan jumlah Function Point, yaitu jumlah fungsi-fungsi yang dimiliki oleh suatu

program, seperti yang dikemukakan oleh Albrecht pada tahun 1979.

2.5.2.1 Albrecht Function Point Analysis

Salah satu metode estimasi yang paling populer adalah metode function point

analysis. Metode ini menggunakan faktor standar untuk menilai kepentingan relatif dari

functional requirement yang bermacam-macam. Diciptakan pertama kali oleh Albrecht

di IBM pada tahun 1979. Albrecht mengidentifikasikan 5 fungsi utama yang sering ada

dalam pengembangan software komersial dan mengkategorikannya sesuai dengan

kompleksitas pengembangan relatifnya. Kelima fungsi tersebut adalah sebagai berikut:

• Masukan (input)

Input adalah layar atau form dimana melaluinya pengguna aplikasi atau

program lainnya menambahkan data baru atau memperbarui data yang

sudah ada.

• Keluaran (output)

Output adalah layar atau laporan yang dihasilkan oleh aplikasi untuk

keperluan pengguna atau untuk program lain.

17

• Permintaan (inquiry) : Inquiry adalah layar yang memperbolehkan

pengguna untuk mencari tahu lebih lanjut dari sebuah aplikasi dan untuk

meminta bantuan atau informasi, seperti layar Help.

• File Data (data file)

Data file adalah koleksi logikal dari catatan yang telah dimodifikasi atau

diperbarui oleh aplikasi.

• Antar Muka (interface)

Interface adalah file-file yang dishare dengan aplikasi lain dan meliputi

incoming atau outgoing tape file, database yang di-share, dan daftar

parameter.

Tabel berikut ini adalah bentuk tabel berisi kategori function-point.

Tabel 2.2 Kategori Function Point

Jumlah Tipe Fungsi Bobot Total

Input * 4

Output * 5

Inquiry * 4

Logical File * 10

Interface * 7

Unadjusted Total

Untuk menghitung total dari function point, nilai dari setiap fungsi harus diisi

dan dikalikan dengan bobotnya lalu dijumlahkan. Sebagai contoh, sebuah aplikasi

menghasilkan 8 input, 12 output, 4 inquiry, 2 logical file dan 1 interface. Maka total

18

unadjusted function point yang didapat adalah 135. Untuk lebih jelasnya, perhitungan

dapat dilihat pada tabel dibawah ini.

Tabel 2.3 Contoh Kategori Function Point

Setelah menghitung total unadjusted function-point, maka untuk mendapatkan

adjusted function-point dibutuhkan tabel faktor yang mempengaruhi function-point.

Tabel ini menggunakan nilai faktor pengaruh dari skala 0 sampai 5, dimana 0

berarti sangat sederhana sampai 5 yang berarti sangat kompleks atau rumit.

Berikut ini adalah contoh tabel yang berisi faktor-faktor yang mempengaruhi

function point.

Tabel 2.4 Contoh Faktor yang Mempengaruhi Function Point

Faktor Tingkat Pengaruh

Data communications 2

Distributed functions 0

Performance objectives 3

Heavily used configuration 3

Transaction rate 4

On-line data entry 4

Jumlah Tipe Fungsi Bobot Total

8 Inputs 8* 4 32

12 Outputs 12* 5 60

4 Inquiry 4* 4 16

2 Logical File 2* 10 20

1 Interface 1* 7 7

Unadjusted Total 135

19

End-user efficiency 3

On-line update 2

Complex processing 3

Reusability 2

Installation ease 3

Operational ease 4

Multiple sites 5

Facilitate change 3

Sum of Influence Factors 41

0.65 + 0.01 * (Sum of Influence Factors) =

Complexity Multiplier

1.06

Function Point = Complexity Multiplier *

Unadjusted Function Point

143

Nilai total dari influence factor dari tabel diatas akan digunakan untuk

menghitung nilai adjusted function point. Nilai 1.06 yang didapat dari perkalian 0.65 +

0.01 * Total influence factor disebut dengan complexity multiplier atau value adjutment

factor. Nilai ini kemudian akan dikalikan dengan unadjusted total function point yaitu

135 menghasilkan nilai total adjusted function point sebesar 143.

Dalam penghitungan function point yang asli, Albrecht tidak memberikan

definisi yang jelas bagaimana mengelompokkan suatu jumlah dari External User Types

termasuk dalam tingkat kompleksitas low, average atau high. Aturan pengelompokkan

ini kemudian didefinisikan oleh The International FP User Group (IFPUG) dengan

aturan di bawah ini.

20

Tabel 2.5 Matriks Kompleksitas Logical Internal File dan External Interface File

Jumlah Field Jumlah Record

< 20 20 sampai 50 > 50

1 Low Low Average

2 sampai 5 Low Average High

> 5 Average High High

Tabel 2.6 Matriks Kompleksitas Eksternal Input

Jumlah Field yang diakses Jumlah file yang

diakses < 5 5 sampai 15 > 15

0 atau 1 Low Low Average

2 Low Average High

> 2 average High High

Tabel 2.7 Matriks Kompleksitas External Output dan External Inquiry

Jumlah Field Jumlah Tipe file

< 6 6 sampai 19 > 19

0 atau 1 Low Low Average

2 atau 3 Low Average High

> 3 Average High High

Function Point Analysis saat ini turut memperhitungkan tidak hanya fitur dan

kompleksitas yang dimiliki oleh sistem tetapi juga lingkungan dimana sistem akan

beroperasi.

21

2.5.2.2 Pengukuran Function Point

Menurut Belchior (1999, pp5-6), selama proses pengukuran, sebuah fungsi (data

atau transaksional) melalui berbagai transformasi implisit, dengan tujuan akhir

mendapatkan representasi kompleksitas fungsional relatifnya yang dinyatakan dalam

function point. Sebelum dinyatakan dalam point, kompleksitas dari sebuah fungsi

dicirikan oleh satu dari tingkat kompleksitas fungsional low, average dan high. Atribusi

dari tingkat kompleksitas ini ke fungsi mengikuti matriks kompleksitas fungsional untuk

setiap fungsi. Tabel berikut ini merepresentasikan matriks kompleksitas dari ILF,

dimana tingkat kompleksitas low, average dan high berhubungan dengan 7, 10 dan 15

function points. Menurut Kemerer (1997, p168), nilai weighting factor dapat disesuaikan

dengan jangkauan ± 25 %, tergantung pada penaksiran kompleksitas software oleh

pembuat estimasi.

Tabel 2.8 Matriks Kompleksitas ILF

DET RET

1 - 19 20 - 50 51 atau lebih

1 Low Low Average

2 - 5 Low Average High

6 atau lebih Average High High

Sedangkan Tabel 2.9 merepresentasikan nilai dalam function point untuk tingkat

kompleksitas low, average dan high untuk setiap fungsi FPA.

22

Tabel 2.9 Tabel Weighting Factor untuk setiap tingkat Kompleksitas

Tingkat

KompleksitasILF EIF EI EO EQ

Low 7 5 3 4 3

Average 10 7 4 5 4

High 15 10 6 7 6

Ada setidaknya 2 situasi yang jelas dalam FPA yang tidak memberikan secara

jelas proses pengukuran function point seperti yang dapat dilihat dalam data pada Tabel

2.8, yaitu:

Situasi 1 (S1): ILF dengan 1 RET dan 19 DET (fungsi f1) diklasifikasikan sebagai

kompleksitas low, yang memberikan 7 function point. Dengan kriteria yang sama ILF

dengan 1 RET dan 50 DET (f2) juga diklasifikasikan sebagai kompleksitas low (7

function point). Bagaimanapun dengan penambahan hanya satu DET sehingga

menghasilkan 51 DET, ILF (f3) akan dianggap sebagai kompleksitas average,

memberikan 10 function point dalam proses penghitungan. Oleh karena itu FPA

menganggap f1 dan f2 sebagai fungsionalitas identikal serta f2 dan f3 sebagai

fungsionalitas yang berbeda. Dalam kasus dimana mereka di anggap didalam proyek

yang sama, maka pengukuran hasil akhir tidak akan menghasilkan suatu nilai function

point yang cukup akurat.

Situasi 2 (S2): ILF dengan 6 RET dan 20 DET mempunyai jumlah function point

yang sama dengan ILF dengan 6 RET dan 70 DET. Dalam kasus tertentu, jumlah barang

yang direferensikan yang menentukan batas bawah dari jarak kompleksitas high, dapat

23

mengantar kepada kesulitan pengukuran presisi yang diamati dari situasi diatas,

khususnya dalam system yang mereferensikan DET dalam jumlah besar.

2.5.2.3 Fuzzy Function Point Analysis

Menurut Belchior (1999, pp6-10), ide utama dari perluasan FPA menjadi FFPA

melalui teori fuzzy set adalah untuk memperluas semantik FPA tradisional dengan

menggunakan konsep dan formalisasi matematika dari teori yang sudah ada. Model

fuzzy juga bertujuan untuk menyediakan pendekatan yang lebih tepat kepada proses

penghitungan function point dengan memperluas FPA menjadi FFPA dan pada saat yang

sama juga menjamin validitas dari perhitungan akhir function point tradisional. Tipe-tipe

dari fungsi data (ILF dan EIF) dan fungsi transaksional (EI, EO, dan EQ) dengan

matriks kompleksitas fungsionalnya dapat dipetakan untuk menuliskan X semesta yang

berhubungan dengan DET yang bersangkutan. Semua matriks ini menggunakan tingkat

yang sama yaitu low, average, dan high untuk menyatakan tingkat kompleksitasnya.

Angka-angka fuzzy trapezoid dapat dinyatakan dengan Ñ (a, m, n, b), yang fungsi

keanggotaannya dapat dinyatakan dengan rumus sebagai berikut.

( )

⎪⎪⎪

⎩

⎪⎪⎪

⎨

⎧

>∈−−

∈∈−−

<

=

bxsebnxsenbxb

nmxsemaxseamax

axse

xN

,0],[),/()(

],[,1],[),/()(

,0

~μ

Nilai a dan b mengidentifikasikan batas bawah dan atas dari trapezoid dengan

basis yang lebih besar, dimana µÃ(x) = 0. Nilai m dan n adalah batas bawah dan atas dari

24

trapezoid dengan basis yang lebih kecil, dimana µÃ(x) = 1 seperti yang terlihat pada

gambar 2.3.

Gambar 2.3 Angka Fuzzy Berbentuk Trapesium

FFPA terdiri dari 4 tahap berikut:

1. Proses fuzzifikasi dari kompleksitas fungsional dari matriks kompleksitas

FPA dengan menghasilkan angka fuzzy berbentuk trapesium.

2. Proses perluasan matriks kompleksitas FPA dengan menghasilkan

kompleksitas fungsional baru.

3. Penentuan nilai function point untuk kompleksitas fungsional baru tersebut.

4. Proses defuzzifikasi dari kompleksitas fungsional dari nilai function point

FFPA.

Tahap Pertama

Dalam tahap ini, angka-angka fuzzy dari bentuk trapesium Ñ (a, m, n, b)

dihasilkan untuk setiap tingkat kompleksitas Ti (low, average,high) yang dimiliki oleh

matriks kompleksitas fungsi data dan fungsi transaksional. Nilai mi beranggapan bahwa

batas bawah dari kompleksitas fungsional i harus dipertimbangkan. Nilai ni dihitung dari

rata-rata nilai mi dan mi+1, dimana hasilnya harus dibulatkan. Nilai-nilai untuk ni-1 dan

mi+1 didistribusikan ke ai dan bi.

25

Tahap Kedua

Tahap ini dianggap digunakan untuk meminimalisasikan masalah yang

disebutkan dalam S2, yang menjadi lebih kritikal karena angka RET dan angka FTR

bertambah dalam fungsi data dan dalam fungsi transaksional.

Dalam konteks ini interval baru dari kompleksitas high ditambahkan pada fungsi

data dan transaksional yang dipanggil untuk mendekati interval dari kompleksitas

average. Untuk alasan yang sama, sebuah interval yang baru dari kompleksitas very high

ditambahkan untuk sisa dari fungsinya.

Nilai dari ni-1 untuk dimana nilai mi dihitung adalah titik dimana fungsi

keanggotaan akan mulai kehilangan karakteristik kompleksitas high dan secara

konsekuen mulai mendapatkan karakteristik kompleksitas very high.

Baris terakhir dari matriks kompleksitas setiap fungsi adalah titik awal untuk

pembuatan angka fuzzy baru. Sesuai dengan yang telah dibuat dalam FPCPM tahun

1999, bahwa fungsi yang berada pada dua sel dari matriks terakhir adalah kompleksitas

high. Untuk menjaga nilai yang telah digunakan oleh FPCPM tersebut, diputuskan

bahwa angka yang mengindikasikan batas bawah dari kolom ketiga dari matriks

merepresentasikan nilai n dari fuzzy set dari fungsi kompleksitas high.

Nilai mi untuk angka fuzzy dari kompleksitas high akan dianggap sebagai k,

menghasilkan kompleksitas fungsional baru dalam hubungannya dengan lainnya yang

telah ada. Nilai yang berhubungan dengan k harus dihitung untuk setiap 5 tipe fungsi

yang dimiliki FPA. Dalam mendapatkan nilai k, sebagai contoh, Tabel 2.9 diperluas ke

dalam tabel seperti berikut ini.

26

Tabel 2.10 Tabel Matriks Kompleksitas Fungsional yang diperluas

Distinct Field

Distinct Record 1 sampai m1-1 m1 sampai m2

m2+1 sampai

k-1 k atau lebih

< n1 Low Low Average High

n1 - n2 Low Average High Very High

> n2 Average High High Very High

Mengambil nilai k seperti yang telah dihitung diatas dan berdasarkan data dari

tabel 2.10, fungsi keanggotaan dari angka fuzzy berbentuk trapesium diperlihatkan dalam

tiga gambar berikut (gambar 2.4, gambar 2.5, gambar 2.6) untuk setiap tiga garis dari

matriks kompleksitas dari tipe input sesuai dengan model yang digambarkan.

Gambar 2.4 Fungsi Keanggotaan Angka-Angka Fuzzy untuk ILF dengan 1 RET

Gambar 2.5 Fungsi Keanggotaan Angka-Angka Fuzzy untuk ILF dengan 2 sampai 5 RET

27

Gambar 2.6 Fungsi Keanggotaan Angka-Angka Fuzzy untuk ILF dengan 6 atau lebih RET

Dari dasar historis function point sistem yang terbatas, nilai yang lebih tepat

untuk k dapat diperoleh pada dimana organisasi dari pengembangan software berfokus.

Tahap Ketiga

Dalam FPA, function point pi diatribusikan kepada setiap tingkat kompleksitas

fungsional Ti (low, average dan high) sesuai dengan matriks kompleksitas dalam

pertimbangan. Pada FFPA, poin-poin ini berhubungan langsung dengan angka fuzzy dari

tingkat kompleksitas fungsional dimana µÑ(x) = 1.

Nilai dari function point untuk tingkat kompleksitas fungsional baru dari

kompleksitas very high dihitung dengan ekstrapolasi dari nilai yang sudah didefinisikan

untuk istilah low, medium, dan high untuk setiap fungsi.

Secara khusus, fungsi perkiraan dari formula Newton (Belchior, 1999, p9)

adalah:

on

ooon fnufufufup Δ⎟⎠⎞

⎜⎝⎛++Δ⎟

⎠⎞

⎜⎝⎛+Δ⎟

⎠⎞

⎜⎝⎛+= ..

21)( 2

Dimana u adalah nilai yang berhubungan dengan absis x dalam interpolar dan

Δ adalah operator dari selisih progresif. Dalam hal ini, nilai untuk absis 1, 2, 3 dan 4

28

diatribusikan ke dalam tingkat kompleksitas low, medium, high dan very high. Nilai u

diperoleh dengan persamaan berikut :

hxx

u o−=

Dimana h adalah langkah perbedaan antara nilai dari dua nilai subsequent dari x.

Nilai u adalah 3 untuk semua fungsi data dan fungsi transaksional, karena h = 1, x = 4

(very high) e x0 = 1 (low).

Istilah Δ fi e Δ n[f(x)] dari fungsi perkiraan dihitung sebagai berikut:

Δ fi = fi+1 - fi

Δ n[f(x)] = Δ n-1[f(x + h) – Δ n-1[f(x)]

Dimana n = 2,3, dan seterusnya.

Dengan menggunakan definisi di atas, nilai yang diperoleh untuk angka fuzzy

dari fungsi kompleksitas very high dapat diestimasi.

Nilai dari function point untuk tingkat kompleksitas very high dari ILF didapat

dengan menggantikan tingkat kompleksitas diatas dalam fungsi perkiraan:

ooo fufufup 22 21

)( Δ⎟⎠⎞

⎜⎝⎛+Δ⎟

⎠⎞

⎜⎝⎛+=

Tahap Keempat

Dalam FFPA, untuk mendapatkan angka pada function point pd dari angka

trapezoidal fuzzy, dimana µÑ(x) < 1, mengerjakan proses defuzzifikasi sebagai berikut:

29

1~~ ).().( ++= iNiNd pxpxp μμ

2.5.2.4 Keunggulan metode Function Point Analysis

Menurut Longstreet (http://www.softwaremetrics.com/files/Fundamentals%

20of%20Function%20Point%20Analysis.pdf, 1995) ada 4 keuntungan utama dari

penggunaan FPA untuk memperkirakan ukuran software, yaitu:

• Function Point (FP) dapat digunakan untuk memperkirakan ukuran

software secara akurat.

• Meskipun digunakan oleh orang berbeda dan dalam waktu berbeda akan

tetap menghasilkan hasil yang sama dengan margin kesalahan yang

masuk akal.

• Function point dapat mudah dimengerti oleh pengguna non teknis,

sehingga memudahkan dalam mengkomunikasikannya.

• Function point dapat digunakan untuk membandingkan apakah suatu alat

bantu, bahasa pemrograman atau lingkungan lebih produktif dari yang

lain.

Sedangkan menurut Sencer (http://yunus.hun.edu.tr/%7Esencer/index.html),

terdapat beberapa keuntungan tambahan yang didapat dengan menggunakan analisis

function point yaitu:

• Tidak bergantung pada bahasa pemrograman.

• Data awal yang diperlukan telah tersedia pada tahap awal proyek.

30

2.5.2.5 Keterbatasan Function Point Analysis

Menurut Kemerer (1997, p194), walaupun memiliki beberapa keuntungan,

namun metode Function Point Analysis juga memiliki keterbatasan, yakni pada

umumnya Function Point Analysis hanya bekerja pada aplikasi bisnis, bukan pada jenis

aplikasi lain seperti aplikasi teknik atau bersifat ilmiah.

Sedangkan menurut Sencer, function point analysis memiliki kelemahan, antara

lain:

• Bersifat subyektif, hasil perhitungan seseorang dengan hasil perhitungan

orang yang lain belum tentu sama.

• Sulit di otomatisasi dan dihitung.

• Mengabaikan kualitas output.

• Berorientasi pada aplikasi transaksi data tradisional.

2.5.3 Mengubah Function Point (FP) Menjadi Line Of Code (LOC)

Jumlah function point yang didapatkan dari hasil analisa function point dengan

menggunakan metode Function Point Analysis maupun dengan Fuzzy Function Point

Analysis perlu terlebih dahulu diubah menjadi LOC (Line of Codes) dengan

menggunakan sebuah konstanta yang didapat dari bahasa pemrograman umum yang

digunakan. Tabel yang diperoleh dari http://www.theadvisors.com/langcomparison.htm,

yang mengandung 484 bahasa pemograman.

31

2.6 Estimasi Usaha (Effort)

2.6.1 Teknik-Teknik Estimasi Usaha

Barry Boehm telah mengidentifikasi beberapa teknik umum yang digunakan

untuk melakukan estimasi dalam proyek pengembangan software (Kemerer, 1997, p61),

antara lain:

1. Algorithmic models, dimana prediksi usaha dilakukan berdasarkan

karakteristik dari sistem yang direncanakan dan lingkungan dimana sistem

tersebut akan bekerja.

2. Expert Judgement, dimana estimasi usaha dilakukan berdasarkan

pengalaman dari seorang ahli yang sudah sangat familiar dengan software

yang akan dibuat.

3. Analogi, estimasi usaha dihitung berdasarkan proyek yang telah diselesaikan

pada masa lalu dan serupa dengan proyek yang akan dikerjakan. Usaha

aktual dari proyek tersebut dijadikan dasar perhitungan untuk mengestimasi

usaha pada proyek yang baru.

4. Parkinson, dimana mengidentikasi usaha dari staf yang tersedia untuk

melakukan proyek sebagai “estimasi”.

5. Price to win, dimana estimasi dilakukan dengan memperkirakan “usaha”

terendah untuk memenangkan kontrak.

6. Top-down, dimana keseluruhan estimasi diformulasikan untuk keseluruhan

proyek dan kemudian dipecah-pecah menjadi usaha yang diperlukan untuk

tiap-tiap tugas.

32

7. Bottom-up, dimana tugas-tugas terkecil dari suatu proyek diidentifikasi

terlebih dahulu dan kemudian estimasi usaha tiap-tiap tugas tersebut

digabungkan untuk mendapatkan estimasi usaha secara keseluruhan proyek.

2.6.2 Model Estimasi Empiris

Model estimasi untuk piranti lunak komputer menggunakan rumus yang

diturunkan secara empiris untuk mengestimasi usaha sebagai sebuah fungsi LOC atau

FP.

Data empiris yang mendukung sebagian besar model-model estimasi diturunkan

dari contoh-contoh proyek yang terbatas. Berdasarkan pendapat Pressman (2001, p132),

data yang diprediksi dengan menggunakan model empiris harus dibandingkan dengan

hasil aktual dan kesesuaian hasil harus dicapai. Jika kesesuaian belum tercapai, maka

koefisien dan eksponen model harus dikomputasi ulang menggunakan data lokal.

2.6.2.1 Struktur Model Estimasi

Model estimasi pada umumnya diturunkan dengan menggunakan analisis regresi

terhadap data-data yang dikumpulkan dari proyek-proyek piranti lunak yang pernah

diselesaikan.

Struktur model estimasi tersebut membentuk persamaan berikut (Pressman,

2001, p132) :

E = A + B x (ev)c

Dimana:

33

A = konstanta turunan

B = konstanta turunan

C = konstanta turunan

E = effort dalam satuan Person-Month

ev = variabel estimasi dalam satuan LOC atau FP

Salah satu model berorientasi FP yang digunakan adalah Model Albrecht dan

Gaffney yang memiliki persamaan berikut:

E = -13.39 + 0.0545 x FP

2.6.2.2 Constructive Cost Model

Cocomo (Cocomo 81) dirumuskan berdasarkan model yang didapat oleh Boehm

pada tahun 1970 yang melakukan penelitian pada 63 proyek dimana hanya 7 diantaranya

yang merupakan sistem bisnis.

Model Cocomo didasarkan pada persamaan:

Effort = a x sizeb

Development Time = c x Ed

P = E / D

Dimana effort diukur dalam satuan person-month yang terdiri dari 152 jam kerja.

Sedang ukuran (size) diukur dalam satuan kdsi (thousand of delivered code instruction).

Development time adalah waktu yang dibutuhkan untuk pengembangan software,

dinyatakan dalam satuan bulan (month). P adalah jumlah orang yang dibutuhkan untuk

mengerjakan proyek tersebut. Sedangkan a, b, c dan d adalah konstanta yang ditentukan

34

tipe dari proyek software yang akan dibuat, apakah termasuk dalam kategori Organic

mode, Embedded mode atau Semi-detached mode yang nilainya dapat dilihat pada tabel

berikut.

Tabel 2.11 Konstanta Cocomo Model

Jenis Proyek a b c d

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Organic adalah tipe umum yang digunakan ketika sebuah software kecil

dikembangkan oleh sebuah tim kecil.

Embedded digunakan ketika produk yang dikembangkan sangat dibatasi oleh

batasan-batasan dan perubahan kecil terhadap sistem akan sangat mahal.

Semi-detached adalah kombinasi antara organic dan embedded.

Basic Cocomo ini baik untuk perkiraan yang cepat, awal dan kasar dari biaya

pembuatan software, namun keakurasiannya sangat terbatas karena kurangnya faktor

untuk menghitung perbedaan pada batasan hardware, kualitas personal dan pengalaman,

teknik dan penggunaan alat-alat modern, dan atribut proyek lainnya yang dikenal

mempunyai pengaruh yang kuat pada biaya pembuatan software.

2.7 Estimasi Biaya

Menurut Sommerville (1996, pp590-591), ada tiga parameter yang dilibatkan

dalam menghitung total biaya pengembangan proyek software, yaitu:

• Hardware, software, dan maintenance

35

• Biaya perjalanan dan pelatihan

• Biaya usaha ( biaya untuk membayar pembuat software)

Untuk kebanyakan proyek, biaya yang paling dominan adalah biaya usaha.

Walaupun komputer dan biaya perjalanan merupakan hal yang signifikan dalam

mengembangkan proyek, namun ini biasanya relatif rendah untuk kebanyakan proyek.

Sedangkan biaya usaha bukan hanya biaya gaji pembuat software saja melainkan

dihitung juga sebagai biaya keseluruhan dalam menjalankan organisasi dan membaginya

dengan jumlah staf produktif. Oleh karena itu, biaya berikut juga merupakan bagian dari

biaya total usaha:

• Biaya penyediaan dan penerangan kantor.

• Biaya staf tambahan seperti akuntan, sekretaris, dan lain-lain.

• Biaya komunikasi dan networking.

• Biaya fasilitas seperti perpustakaan, rekreasi, dan lain-lain.

• Biaya pegawai lain seperti pensiun, asuransi kesehatan, dan lain-lain.

2.8 Metodologi Pengembangan Sistem Berorientasi Objek

2.8.1 Pengertian

Menurut Mathiassen, pengembangan sistem berorientasi objek adalah suatu cara

untuk mengembangkan software dengan membangun objek atau modul yang dapat di

ubah, diganti dan di reuse dengan mudah. Metode berorientasi objek juga

memungkinkan kita untuk membuat serangkaian objek yang dapat bekerja bersama

36

untuk menghasilkan suatu software yang lebih baik dalam memodelkan problem domain

daripada metode tradisional.

2.8.2 Aktifitas-aktifitas dalam Pengembangan Sistem Berorientasi Objek

Terdapat empat aktifitas utama dalam pengembangan sistem berorientasi objek

yaitu problem domain analysis, application domain analysis, architectural design dan

component design. Keempat aktifitas tersebut bersifat iteratif dan saling berhubungan

satu sama lain. Berikut gambar yang menjelaskan aktifitas yang ada dalam

pengembangan sistem berorientasi objek.

Gambar 2.7 Aktifitas dalam Pengembangan Sistem Berorientasi Objek

37

2.8.3 Unified Process Berdasarkan Analisa dan Desain Berorientasi Objek

Unified process digunakan untuk menggambarkan satu cara untuk

mengorganisasikan proyek berorientasi objek yang berdasarkan use case, bersifat iteratif

dan inkremental serta berfokus pada analisis, desain dan programming. Pendekatan

unified ini terutama diarahkan oleh application domain analysis yaitu oleh use case.

Berikut ini gambar yang menjelaskan suatu pendekatan berorientasi objek yang

iteratif serta fase-fasenya yang bersifat inkremental.

Gambar 2.8 Pendekatan Incremental Unified Process

38

2.8.4 Aktifitas-aktifitas Pengembangan Sistem Berdasarkan Pendekatan Rational

Unified Process

Suatu pendekatan lain yang digunakan untuk menggambarkan aktifitas- aktifitas

pengembangan sistem adalah melalui rational unified process. Rational unified process

merupakan sebuah proses pengembangan software iteratif yang diciptakan oleh

perusahaan Rational Software dan merupakan bagian dari IBM. Rational unified process

mencakup sejumlah aktifitas antara lain business modelling, requirements, analysis &

design, implementation, test, deployment, configuration&change management, project

management dan environment.

2.8.4.1 Fase-fase Pengembangan Berdasarkan Rational Unified Process

Dalam rational unified process, siklus hidup produk software dipecah-pecah

menjadi siklus pengembangan individual. Siklus ini kemudian dipecah-pecah lagi

menjadi komponen utamanya yang disebut sebagai fase. Terdapat empat fase dalam

rational unified process, yakni inception phase, elaboration phase, construction phase

dan transition phase. Fase-fase ini bersifat iteratif.

1. Inception Phase

Dalam fase ini, kasus bisnis yang meliputi konteks bisnis, faktor sukses, dan ramalan

keuangan juga diperhitungkan. Untuk melengkapi kasus bisnis, suatu model dasar use

case, rencana proyek, penaksiran awal resiko, dan deskripsi proyek dihasilkan. Setelah

ini diselesaikan, proyek akan diperiksa dengan kriteria berikut ini:

Persetujuan stakeholder pada definisi lingkup dan perkiraan biaya atau jadwal.

Pengertian requirements seperti yang dibuktikan oleh kesesuaian use case utama.

39

Kredibilitas dari perkiraan biaya atau jadwal, prioritas, resiko dan proses

pengembangan.

Kedalaman dan keluasan dari prototipe arsitektural yang dikembangkan.

Pengeluaran sebenarnya terhadap pengeluaran terencana.

2. Elaboration Phase

Fase elaborasi adalah fase dimana proyek dimulai untuk dibentuk. Dalam fase ini,

problem domain analysis dibuat dan arsitektur proyek mendapatkan bentuk dasarnya.

Fase ini harus memenuhi kriteria sebagai berikut:

Sebuah model use case dimana use case dan aktor telah diidentifikasi dan

kebanyakan dari deskripsi use case dikembangkan. Use case harus 80% selesai.

Deskripsi dari arsitektur software dalam sistem proses pengembangan software.

Prototipe arsitektur yang dapat dieksekusi.

Kasus bisnis dan daftar resiko yang dapat diperbaiki.

Rencana pengembangan untuk proyek keseluruhan.

3. Construction Phase

Dalam fase ini, fokus utama terletak pada pengembangan dari komponen dan fitur-fitur

lain dari sistem yang sedang dikembangkan. Ini adalah fase dimana bagian terbesar dari

coding. Fase ini menghasilkan keluaran eksternal software pertama.

4. Transition Phase

Dalam fase transisi, produk telah berpindah dari pengembangan oleh perusahaan

menjadi ke pengguna. Aktifitas dari fase ini meliputi: training pengguna dan admin.

Beta testing dari sistem dijalankan untuk memvalidasi terhadap ekspektasi pengguna.

Produk juga diperiksa terhadap level kualitas pada fase insepsi.

40

Berikut ini gambar yang menunjukkan aktifitas-aktifitas beserta fasenya dalam

rational unified process.

Gambar 2.2.9 Aktifitas-Aktifitas Pengembangan Dalam RUP

2.9 Internet

2.9.1 Definisi

Internet merupakan jaringan komputer yang sangat besar yang terdiri dari

jaringan-jaringan kecil yang saling terhubung satu sama lain di seluruh dunia. Pada

tahun 1950, beberapa peneliti komunikasi menyadari bahwa adanya kebutuhan untuk

dapat berkomunikasi antara bermacam-macam komputer dan jaringan komputer. Hal ini

mengarah kepada penelitian dari decentralized network, queuing theory dan packet

switching. Pembuatan berkelanjutan dari ARPANET di United States pada gilirannya

memberikan suatu gelombang pengembangan teknik yang menjadi dasar dari

pengembangan Internet.

41

TCP/IP pertama hadir pada sekitar tahun 1984 ketika United State Science

Foundation membangun suatu tulang punggung jaringan universitas yang kemudian

menjadi NFSNet. Ini kemudian diikuti dengan pembukaan jaringan ke masyarakat

umum pada tahun 1995.

Pada bulan Agustus tahun 1991, CERN di Swiss mempublikasikan proyek World

Wide Web, dua tahun setelah Tim Berners-Lee telah membuat HTML, HTTP dan web

page pertama di Swiss.

Pada tahun 1993, web browser pertama hadir dengan nama Mosaic versi 1.0.

Hingga pada tahun 1996 Internet menjadi sangat terkenal di masyarakat dengan sebutan

World Wide Web.

2.9.2 World Wide Web

World Wide Web atau disebut juga Web, WWW adalah ruang informasi di

Internet tempat dokumen hypermedia disimpan dan dapat diambil melalui skema alamat

yang unik. Hypermedia sendiri merupakan suatu multimedia yang terdiri dari teks,

audio, grafik dan video. WWW diciptakan pertama kali oleh Tim Berners-Lee pada

tahun 1989.

2.9.3 Aplikasi Web

Menurut http://en.wikipedia.org/wiki/Web_application, dalam software

engineering, aplikasi web adalah sebuah aplikasi yang dikirimkan ke pengguna dari

sebuah web server melalui sebuah network seperti World Wide Web, atau intranet.

42

Aplikasi web menjadi semakin populer karena semakin umumnya web browser sebagai

client, yang seringkali disebut thin client. Kemampuan untuk memperbaharui dan

menjaga aplikasi web tanpa mendistribusikan dan meng-install software pada ribuan

klien komputer adalah alasan utama kepopulerannya. Aplikasi web digunakan untuk

mengimplementasikan webmail, penjualan online, lelang online, dan sebagainya.

Aplikasi dan sistem yang berbasis web memberikan suatu array yang kompleks

dan fungsionalitas kepada penggunanya yang luas. Sedangkan web engineering adalah

suatu proses yang digunakan untuk membuat aplikasi web yang berkualitas.

2.9.4 Istilah dalam Web

Banyak istilah yang secara umum dikaitkan dengan Internet yang sebenarnya

berkaitan dengan web, yaitu:

1. Web site

Mengacu pada sebuah komputer yang dikaitkan dengan Intenet yang

berisi hypermedia yang dapat diakses dari komputer lain di jaringan melalui

suatu hypertext link.

2. Hypertext link

Mengacu pada suatu penunjuk yang terdiri dari teks atau grafik yang

digunakan untuk mengakses hypertext yang disimpan di website. Biasanya

digarisbawahi dan ditampilkan dengan warna biru. Jika kursor diarahkan

pada hypertext, bentuk kursor akan berubah menjadi gambar tangan dengan

jari yang menunjuk.

3. Web page

43

Mengacu pada suatu file hypermedia yang disimpan dalam suatu

website yang diidentifikasi oleh suatu alamat yang unik.

4. Home page

Merupakan halaman pertama dari suatu situs web, dimana halaman-

halaman lain di situs tersebut dapat dicapai dari homepage.

5. Universal Resource Locator (URL)

Merupakan alamat dari suatu halaman web, biasa diucapkan dengan

“earl” dan mempunyai format sebagai berikut:

Protocol ://domain name/path

6. Protocol

Protokol merupakan suatu set standar yang mengatur komunikasi

data. HTTP adalah protokol untuk hypertext, dan merupakan singkatan dari

Hyper Text Transport Protocol. Nama protokol dituliskan dalam huruf kecil,

dan diikuti oleh titik dua (:) dan dua garis miring (//).

7. Domain name

Merupakan alamat situs web dimana suatu halaman web disimpan.

Nama itu memiliki titik yang disebut dot. Tiga huruf terakhir dari domain

name menyatakan jenis web site; edu (pendidikan), com (komersial), dan gov

(pemerintahan) adalah yang paling sering dipakai.

8. Web Browser

Merupakan suatu sistem perangkat lunak yang memungkinkan

seseorang mengambil hypermedia dengan mengetikkan parameter pencarian

atau mengklik suatu grafik. Browser sering disebut juga search engine.

44

2.10 Interaksi Manusia dan Komputer (IMK)

2.10.1 Definisi

IMK adalah ilmu yang berhubungan dengan perancangan, evaluasi dan

implementasi sistem komputer interaktif untuk digunakan oleh manusia, serta studi

fenomena-fenomena besar yang berhubungan dengannya.

2.10.2 Tujuan Rekayasa IMK

Sistem yang efektif akan menghasilkan rasa keberhasilan, kompetensi,

penguasaan dan kejelasan dalam komunitas pemakai. Tujuan dari rekayasa sistem IMK

adalah untuk menghasilkan sistem dengan:

1. Fungsionalitas yang semestinya

Sistem dengan fungsionalitas yang kurang memadai akan

mengecewakan pemakai dan sering ditolak atau tidak digunakan. Sedangkan

sistem yang berlebihan akan menyebabkan kesulitan dalam implementasi,

pemeliharaan dan penggunaan.

2. Kehandalan, ketersediaan, keamanan dan integritas data

• Kehandalan (reliability): berfungsi seperti yang diinginkan.

• Ketersediaan (availability): tersedia ketika hendak digunakan.

• Keamanan (security): terlindung dari akses yang tidak diinginkan dan

kerusakan yang tidak disengaja.

• Integritas data (data integrity): keutuhan data terjamin.

45

3. Standarisasi, integrasi, konsistensi dan portabilitas

• Standarisasi: keseragaman sifat-sifat antar muka pemakai pada aplikasi

yang berbeda, misalnya dengan menggunakan standar industri yang ada.

• Integrasi: keterpaduan antara paket aplikasi dan software tools.

• Konsistensi: keseragaman dalam suatu program aplikasi.

• Portabilitas: dimungkinkannya data dikonversi pada berbagai hardware

dan software.

4. Penjadwalan dan anggaran

Perencanaan yang hati-hati dan manajemen yang berani diperlukan

karena proyek harus sesuai dengan jadwal dan anggaran.

2.10.3 Delapan Aturan Emas Perancangan Interface

Menurut Shneiderman (1998, pp74-76), terdapat delapan aturan dalam

merancang sebuah interface agar efektif dan efisien bagi pengguna. Aturan-aturan

tersebut antara lain:

1. Konsistensi

Jika terdapat aksi berurutan pada situasi yang sama atau dalam

penggunaan warna, layout maupun font harus konsisten.

2. Memungkinkan frequent user untuk menggunakan shortcut.

46

Adanya hotkey, special key, atau hidden command sehingga bagi

pengguna yang sering mengakses sistem dapat dengan cepat mendapatkan

apa yang diinginkannya dan meningkatkan kecepatan interaksi.

3. Adanya umpan balik yang informatif

Untuk setiap aksi dari pengguna haruslah ada umpan balik dari sistem

yang dapat membuat pengguna yakin bahwa apa yang ia inginkan dapat

tercapai.

4. Ada dialog untuk keadaan akhir

Dengan adanya dialog ini maka akan memberikan kepuasan bagi

operator serta menghilangkan kebingungan, sehingga mereka siap untuk aksi

berikutnya.

5. Berikan pencegahan dan penanganan kesalahan yang sederhana.

Sebisa mungkin buat rancangan agar user tak melakukan kesalahan

yang fatal dan apabila user tersebut melakukan kesalahan, maka sistem harus

mendeteksi kesalahan tersebut dan memberikan instruksi yang sederhana,

konstruktif, dan spesifik untuk koreksi.

6. Berikan pembalikan aksi yang mudah

Aksi yang dilakukan user haruslah dapat diulang (undo) sehingga

memudahkan dalam memperbaiki kesalahan yang disadarinya.

47

7. Mendukung internal locus of control

Pengguna yang sudah mahir sangat ingin agar mereka mempunyai

kewenangan tinggi atas sistem dan sistem dapat dengan cepat merespons

keinginan mereka, tapi terkadang ada aksi dari sistem yang diluar dugaan

misalnya, aktifitas data entry yang lama dan membosankan serta kesulitan

dalam mencari informasi. Karena itu harus dibuat bahwa pengguna adalah

initiator dari aksi, bukan responder dari aksi.

8. Mengurangi beban ingatan jangka pendek

Karena keterbatasan ingatan manusia maka tampilan yang disajikan

haruslah sesederhana mungkin, tampilan halaman yang banyak (multiple

page display) haruslah dikombinasikan dan frekuensi perpindahan window

diminimalisir.

2.11 .Net

2.11.1 Definisi

Menurut http://en.wikipedia.org/wiki/Microsoft_.NET, kerangka kerja .Net

diciptakan pertama kali oleh Microsoft dimana merupakan sebuah platform

pengembangan software yang berfokus pada Rapid Application Development (RAD),

platform yang independen, dan network yang transparan. .Net adalah suatu strategis

inisiatif Microsoft untuk pengembangan desktop dan server. .Net meliputi banyak

teknologi yang didesain untuk memfasilitasi perkembangan aplikasi internet dan

intranet yang sangat cepat.

48

.Net telah memberikan fungsionalitas dan peralatan baru kepada Application

Programming Interface (API). Inovasi ini memungkinkan programmer untuk

mengembangkan aplikasi untuk Windows dan web seperti juga komponen dan web

services. .Net memberikan suatu API yang reflektif dan object-oriented. .Net didesain

untuk membuat banyak bahasa tingkat tinggi menjadi lebih umum agar dapat

dikompilasi.

Microsoft mendeskripsikan platform tersebut sebagai sebuah lingkungan untuk

membangun, menggunakan dan menjalankan web services dan aplikasi lain. Platform ini

terdiri dari tiga bagian utama, yaitu Common Language Runtime, Framework Classes

dan ASP.NET.

2.11.2 ASP.NET

Menurut http://en.wikipedia.org/wiki/ASP.NET, ASP.NET adalah suatu

rangkaian dari teknologi pengembangan web yang dipasarkan oleh Microsoft. ASP.NET

dapat digunakan untuk membuat situs web, web application dan XML web service yang

dinamis. ASP.NET merupakan bagian dari platform Microsoft .NET dan merupakan

penerus dari teknologi Active Server Pages (ASP).

Walaupun ASP.NET mengambil namanya dari ASP, namun keduanya sangat

berbeda. Microsoft telah membangun ASP.NET berdasarkan Common Language

Runtime (CLR) yang dibagi kepada semua aplikasi Microsoft.NET. Programmer dapat

menulis coding ASP.NET menggunakan bahasa pemrograman apapun yang didukung

oleh framework .NET.

49

ASP.NET juga lebih cepat karena seluruh situs web di kompilasi dahulu ke satu

atau beberapa file DLL pada web server dan situs web dapat bekerja lebih cepat jika

dibandingkan dengan teknologi scripting terdahulu.

ASP.NET juga berusaha untuk menyederhanakan transisi developer dari

pengembangan aplikasi Windows ke pengembangan web dengan memperbolehkan

mereka untuk membuat halaman yang terdiri dari kontrol yang sama dengan user

interface pada Window.

2.11.3 Keuntungan dari ASP.NET

Berikut ini adalah beberapa keuntungan dari penggunaan ASP.NET:

• Coding yang terkompilasi berarti aplikasi dapat berjalan lebih cepat dengan

kesalahan-kesalahan yang dapat diidentifikasi pada tahap pengembangan.

• User-defined control mengijinkan penggunaan template, seperti Menu.

• Metafora yang sama dengan aplikasi Windows membuat transisi antara

keduanya menjadi lebih langsung.

• Serangkaian kontrol dan class library yang banyak dapat menghasilkan

pembuatan aplikasi sangat cepat.

• ASP.NET meningkatkan penggunaan kemampuan multi bahasa dari CLR

.NET, yang memperbolehkan CLR untuk dikodekan dalam VB.NET, C#, J#,

dan sebagainya.

• Kemampuan untuk menyembunyikan seluruh halaman atau hanya sebagian

untuk meningkatkan performa.

50

• Session state dalam ASP.NET dapat disimpan dalam database SQL Server

atau dalam proses yang berjalan terpisah pada mesin yang sama dengan web

server atau pada mesin yang lain. Dengan cara ini, nilai session tidak hilang

ketika IIS di-reset atau pekerja ASP.NET didaur ulang.

2.12 Unified Modeling Language (UML)

2.12.1 Definisi

Menurut http://en.wikipedia.org/wiki/Unified_Modeling_Language, Unified

Modeling Language (UML) adalah sebuah pemodelan objek dan bahasa spesifikasi yang

digunakan dalam software engineering. UML tidak terbatas pada pemodelan software,

sebagai notasi grafikal UML dapat digunakan untuk pemodelan hardware, dan sering

digunakan untuk pemodelan proses bisnis, pemodelan sistem dan penggambaran struktur

organisasi.

UML didesain agar dapat digunakan untuk menspesifikasi, memvisualisasi,

membangun, dan mendokumentasikan artifak dari sistem objek-oriented intesif yang

berada dalam pengembangan.

2.12.2 Aspek Pemodelan yang Berbeda

Ada tiga aspek yang terkenal dari sistem yang dimodelkan dalam UML, yaitu:

1. Functional Model

Menunjukkan kasus dari fungsionalitas sistem dari pandangan pengguna. Model

ini meliputi use case diagram.

51

2. Object Model

Menunjukkan kasus struktur dan substruktur dari sistem yang menggunakan

objek, atribut, operasi dan asosiasi. Model ini meliputi class diagram.

3. Dynamic Model

Menunjukkan kasus kelakuan internal dari sistem. Ini meliputi sequence

diagram, activity diagram, dan state machine diagram.

2.12.3 Konsep UML

UML menggunakan konsep-konsep sebagai berikut:

• Untuk struktur: actor, attribute, class, components, interface, object,

package.

• Untuk behaviour: activity, event, message, method, operation, state, use

case.

• Untuk relationships: aggregation, association, composition, depends,

generalization atau inheritance.

• Konsep lainnya: stereotype, multiplicity, role.

2.12.4 Tipe-tipe Diagram UML

Dalam UML ada 13 tipe diagram. Beikut ini adalah kategori diagram secara

hirarkis:

• Diagram struktur (menekankan apa saja yang harus ada pada sistem): class,

component, object, composite structure, deployment, dan package diagram.

52

• Behaviour diagram (menekankan apa yang harus terjadi dalam sistem):

activity, use case dan state machine diagram.

• Interaction diagram: sequence, communication, interaction overview, dan

timing diagram.

2.12.4.1 Class Diagram

Class diagram mendeskripsikan struktur sistem dengan menunjukkan class,

object, dan relationship diantaranya. Setiap kelas digambarkan dengan kotak dengan

nama dari class tersebut didalamnya. Sebuah class dapat menampilkan propertinya yang

merupakan atribut dari class dalam kotak sehabis nama beserta tipe, nilai awal serta

properti lainnya. Setelah properti, class juga dapat menampilkan method yang

merupakan operasi dari class tersebut beserta return type dan parameternya.

UML mempunyai relationship berikut ini yang ditunjukkan pada class diagram:

1. Generalization

Generalization yang disebut juga inheritance atau is-a relationship

direpresentasikan dengan bentuk segitiga pada akhir superclass dari pohon garis yang

menghubungkan antara satu atau lebih subclass ke superclassnya. Objek manapun yang

juga merupakan instance dari sebuah subclass adalah juga instance dari superclass.

2. Association, Multiplicity, Directed Association, Reflexive Association

Association digambarkan diantara class tetapi menggambarkan hubungan antar

objek. Peran objek dalam suatu relationship dapat dispesifikasikan pada sebuah

association-end sama halnya juga dengan multiplicity (banyaknya objek yang

berpartisipasi pada asosiasi).

53

3. Aggregation, Composition

Aggregation dan Composition keduanya adalah subvariant dari has-a

relationship. Keduanya merupakan bentuk khusus dari asosiasi.

Aggregation tejadi ketika sebuah class dibentuk sebagai sebuah penampung class

lainnya tanpa dependensi kuat terhadap siklus hidupnya yang menghubungkan antar

class tersebut.

Sedangkan Composition adalah suatu siklus hidup yang kuat antara objek dalam

class penampung dan objek dari class yang ditampung. Composition direpresentasikan

dengan bentuk permata (diamond) hitam pada garis yang menghubungkan class

penampung dan class yang ditampung.

2.12.4.2 Use Case Diagram

Use case menggambarkan interaksi antara sistem dan eksternal sistem dan

pengguna. Dengan kata lain, use case menggambarkan siapa yang akan menggunakan

sistem dan dalam cara apa pengguna berharap untuk berinteraksi dengan sistem.

Use case mendeskripsikan fungsi sistem dari sudut pandang pengguna luar dan

dalam istilah yang dimengerti oleh mereka. Use case juga merupakan hasil dari

pendekomposisian lingkup fungsionalitas sistem menjadi pernyataan-pernyataan yang

lebih kecil dari fungsionalitas sistem.

Pembuatan use case merupakan suatu teknik yang sangat baik untuk lebih

mengerti dan mendokumentasikan kebutuhan dari sistem. Use case diinisiasi oleh

pengguna luar atau sistem yang dinamakan aktor.

54

Aktor menginisiasi aktivitas sistem dengan tujuan untuk menyelesaikan tugas-

tugas. Aktor mempunyai simbol berupa bentuk orang dan use case berupa lingkaran

dengan nama use case didalamnya.

2.12.4.3 Sequence Diagram

Sequence diagram menggambarkan bagaimana objek berinteraksi antara satu

sama lainnya menggunakan pesan dalam pengeksekusian suatu use case atau operasi.

Sequence diagram mengilustrasikan bagaimana pesan dikirim dan diterima diantara

objek dan dalam sequence yang mana.

Sequence diagram merupakan salah satu tipe dari Interaction diagram dimana

objek diatur dari kiri ke kanan melewati diagram dan aktor yang menginisiasi interaksi

berada disebelah kiri.

Sebuah garis vertikal putus-putus disebut lifetime ditempelkan ke setiap objek

atau aktor. Activation box adalah suatu kotak lifeline yang menunjukkan bahwa objek

sedang mengerjakan suatu komputasi dalam periode waktu tertentu. Pesan digambarkan

dengan sebuah panah antara activation box dari pengirim dan penerima.

55

2.12.4.4 Deployment Diagram

Deployment diagram adalah diagram yang menggambarkan arsitektur fisik dari

hardware dan software yang ada pada sistem. Deployment diagram juga melukiskan

komponen-komponen software, prosesor dan alat-alat lain yang digunakan dalam

arsitektur sistem tersebut.

Deployment diagram terdiri dari node, komponen dan hubungan diantaranya.