bab 2 landasan teori 2.1 proses perencanaan 2.1.1...
TRANSCRIPT
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.