BAB 2 LANDASAN TEORI
2.1 2.1.1
Proses Perencanaan 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
6
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 2.3.1
Teori Fuzzy 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 Berkeley.
Califonia,
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: a=
(∑ Υ )(∑ X 2 ) − (∑ X )(∑ XY ) 2 n ∑ X 2 − (∑ X )
Sedangkan untuk menghitung koefisien regresi b digunakan rumus berikut: b=
n ∑ XY − (∑ X )(∑ Y ) 2 n ∑ X 2 − (∑ X )
Model persamaan regresi : Yˆ = a + bX
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 2.5.1
Mengestimasi Ukuran Software 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
Input
*4
Output
*5
Inquiry
*4
Logical File
* 10
Interface
*7
Total
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
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
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
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) =
1.06
Complexity Multiplier Function Point = Complexity Multiplier *
143
Unadjusted Function Point
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
Average
High
High
>5
Tabel 2.6 Matriks Kompleksitas Eksternal Input
Jumlah file yang
Jumlah Field yang diakses
diakses
<5
5 sampai 15
> 15
0 atau 1
Low
Low
Average
2
Low
Average
High
average
High
High
>2
Tabel 2.7 Matriks Kompleksitas External Output dan External Inquiry
Jumlah Tipe file
Jumlah Field <6
6 sampai 19
> 19
0 atau 1
Low
Low
Average
2 atau 3
Low
Average
High
Average
High
High
>3
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
High
High
6 atau lebih Average
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
ILF
EIF
EI
EO
EQ
Low
7
5
3
4
3
Average
10
7
4
5
4
High
15
10
6
7
6
Kompleksitas
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. 0, se x < a ⎧ ⎪( x − a ) /(m − a ), se x ∈ [a, m] ⎪⎪ 1, se x ∈ [m, n] μ N~ ( x ) = ⎨ ⎪ (b − x) /(b − n), se x ∈ [n, b] ⎪ 0, se x > b ⎪⎩
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
m2+1 sampai
1 sampai m1-1
m1 sampai m2
< n1
Low
Low
Average
High
n1 - n2
Low
Average
High
Very High
Average
High
High
Very High
> n2
k-1
k atau lebih
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: ⎛u⎞ ⎛u⎞ ⎛u⎞ p n (u ) = f o + ⎜ ⎟Δf o + ⎜ ⎟Δ2 f o + .. + ⎜ ⎟Δn f o ⎝n⎠ ⎝2⎠ ⎝1⎠
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 : u=
x − xo h
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:
⎛u⎞ ⎛u⎞ p 2 (u ) = f o + ⎜ ⎟Δf o + ⎜ ⎟Δ2 f o ⎝1⎠ ⎝2⎠
Tahap Keempat
Dalam FFPA, untuk mendapatkan angka pada function point pd dari angka trapezoidal fuzzy, dimana µÑ(x) < 1, mengerjakan proses defuzzifikasi sebagai berikut:
29
p d = μ N~ ( x). pi + μ N~ ( x). pi +1
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.
2.5.3
•
Sulit di otomatisasi dan dihitung.
•
Mengabaikan kualitas output.
•
Berorientasi pada aplikasi transaksi data tradisional.
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 2.6.1
Estimasi Usaha (Effort) 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:
2.8 2.8.1
•
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.
Metodologi Pengembangan Sistem Berorientasi Objek 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 2.9.1
Internet 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 halamanhalaman 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 tugastugas. 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.
