BAB 2 BAB 2 LANDASAN TEORI

BAB 2
BAB 2 LANDASAN TEORI
2.1 Proyek Software
2.1.1 Pengertian Proyek Software
Definisi dari proyek adalah sebuah asumsi perencanaan secara luas bagaimana
kita menyelesaikan suatu pekerjaan sebelum kita memulainya. Perencanaan adalah
pemikiran secara matang terhadap sesuatu sebelum kita melakukannya dan biasanya
pada suatu proyek yang belum jelas, ini bisa bekerja dengan baik selama hasil
perencanaan yang diterima bersifat sementara dan spekulatif.
Menurut Amri Shodiq dalam artikel-nya yang dimuat oleh ilmukomputer.com,
Proyek software adalah manajemen proyek yang berfokus hanya pada merancang dan
mengembangkan software. Untuk itu sebuah proyek software perlu di kelola. Manajemen
itu berupa persiapan pekerjaan, pelaksanaan rencana, mengendalikan proyek tersebut dan
terakhir menutup proyek dengan sebuah kesimpulan, yaitu sukses.
2.1.2 Karakteristik Proyek Software
Pada umumnya karakteristik dari suatu software merupakan faktor-faktor yang
akan digunakan untuk menentukan kualitas dari software tersebut. Pengertian kualitas
dari suatu software juga banyak sekali berdasarkan pendapat para pakar.
22
Menurut Steve McConnell's suatu kualitas dari suatu software terbagi menjadi 2
yaitu karakteristik kualitas internal dan karakteristik kualitas eksternal. Karakteristik
kualitas eksternal merupakan bagian dari software yang langsung berhubungan dengan
user, dan sebaliknya dengan yang internal.
Pengertian lain menurut Dr. Tom DeMarco mengatakan bahwa kualitas suatu
produk adalah ketika produk itu berfungsi seberapa banyak untuk mengubah dunia untuk
menjadi lebih baik, dengan kata lain dapat dikatakan sebagaimana kepuasan user lebih
penting daripada semua kualitas yang lain. Beberapa karakteristik dari software yaitu :
•
Understandability, dimiliki oleh suatu software jika tujuan dari produk
tersebut telah jelas. Semua perancangan dan dokumentasi user haruslah jelas
sehingga mudah untuk dimengerti. Tentunya juga sudah seharusnya secara
subjektif sesuai dengan user-nya. Sebagai contoh, produk software yang
digunakan bagi perancang software tidaklah perlu untuk dimengerti oleh
kaum awam.
•
Completeness, merupakan karakteristik software dimana setiap bagian
software telah dikembangkan secara maksmimum. Ini berarti bahwa program
menggunakan bagian-bagian dari sumber data lain, paket software harus
mengandung referensi ke sumber data dan semua parameter yang dibutuhkan
haruslah dikirimkan. Semua input data yang dibutuhkan haruslah ada.
•
Conciseness, merupakan karakteristik software dimana tidak ada bagian
software yang mengandung sesuatu yang tidak dibutuhkan atau berlebihan.
Karakteristik ini sangatlah penting ketika kapasitas dari penyimpanan yang
ada terbatas, dan ini penting untuk mengurangi jumlah baris program. Dapat
23
dikembangkan dengan menggunakan fungsi-fungsi yang dapat digunakan
berulang kali. Ini juga berlaku pada dokumentasi.
•
Portability, merupakan karekteristik software dimana software tersebut dapat
dioperasikan pada berbagai konfigurasi komputer. sebagai gambaran
portabilitas dapat dimaksudkan bahwa software dapat dioperasikan pada
sistem operasi yang berbeda seperti MAC, Linux dan lainnya.
•
Consistency, merupakan karakteristik suatu software dimana software itu
menggunakan simbol-simbol, notasi-notasi, dan terminologi yang sudah
umum digunakan.
•
Testability, merupakan karakteristik suatu software dimana software itu di beri
fasilitas dalam mendukung evalusi kemampuan dari software tersebut.
Karakteristik seperti ini harus ada selama pembuatan software agar produk
mudah dalam melakukan pengujian. Suatu perancangan yang complex
biasanya memiliki tingkat testability yang rendah.
•
Usability, merupakan karakteristik suatu software dimana software itu mudah
untuk digunakan.
•
Reliability, merupakan karakteristik suatu software dimana software dapat
menyediakan fungsi-fungsi yang dibutuhkan secara memuaskan. Ini butuh
diterapkan dalam jangka waktu yang lama untuk merealisasikannya.
•
Efficiency, merupakan karakteristik suatu software dimana software tersebut
dapat mencapai tujuannya tanpa menghabiskan resource yang tersedia.
Resource yang dimaksud disini adalah utilisasi memory dan kecepatan
processor.
24
2.1.3 Life Cycle Proyek Software
Dalam mengerjakan sebuah proyek, perencanaan awal sangatlah penting, dan
biasanya prinsip dasar dari perencanaan proyek ini adalah membuat perencanaan pada
outline terlebih dahulu dan kemudian menjadikannya lebih terperinci, dan sekaligus
menentukan pendekatan-pendekatan dalam tiap-tiap aktifitasnya.
Bisa digambarkan life cycle dari proyek software adalah seperti gambar berikut:
Gambar 2.1 : Life Cycle Proyek Software
(Sumber : http://conxxion.com/assets/sys_life_cyle.gif)
25
2.2 Unified Modelling Language (UML)
2.2.1 Sejarah UML
UML (dulu bernama OMT – Object Modelling Technique) adalah sebuah bahasa
yang telah menjadi standar dalam industri untuk memvisualisasi, menspesifikasi,
merancang dan mendokumentasi sistem piranti lunak (Booch et al, 1999, p14). UML
menawarkan sebuah standar yang dicetuskan oleh IBM untuk merancang model sebuah
sistem. Seperti bahasa-bahasa lainnya, UML juga memiliki notasi. Notasi UML
merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti
lunak. Setiap bentuk memiliki makna tertentu dan UML menjelaskan bagaimana bentukbentuk tersebut didefinisikan. Notasi UML terutama diturunkan dari tiga notasi yang
telah ada sebelumnya yaitu Grady Booch OOD (Object Oriented Design), Jim Rumbaugh
OMT (Object Modelling Technique) dan Ivan Jacobson (Object Oriented Software
Engineering).
Dimulai pada bukan Oktober 1994, Booch, Rumbaugh dan Jacobson yang
merupakan tiga tokoh dimana metodenya banyak digunakan, mempelopori usaha untuk
penyatuan pendesainan berorientasi objek (Booch et al, 1999, pXIX). Pada tahun 1995
dirilislah UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut lalu dikoordinasikan
oleh Object Management Group (OMG). Sejak itulah UML menjadi standar bahasa
pemodelan untuk aplikasi berorientasi objek.
26
2.2.2 Faktor Pendorong dibuatnya UML
Membangun model untuk suatu sistem piranti lunak sangat bergantung pada
konstruksinya atau kemudahan dalam memperbaikinya. Oleh karena itu, membuat model
sangat penting sebagai mana pentingnya memiliki cetak biru untuk bangunan yang besar.
Model yang bagus sangat penting untuk menghasilkan komunikasi yang baik antar
anggota tim dan untuk meyakinkan sempurnanya arsitektur sistem yang dibangun.
Jika ingin membangun suatu model dari suatu sistem yang kompleks, tidak
mungkin kita dapat memahaminya secara keseluruhan. Dengan meningkatnya
kompleksitas sistem, visualisasi dan pemodelan menjadi sangat penting. UML dibuat
untuk merespon kebutuhan tersebut.
2.2.3 Tujuan UML
Melihat dari faktor sejarah dan pendorong terbentuknya UML ini, dapat ditarik
suatu kesimpulan mengenai tujuan dibentuknya UML yang terangkum sebagai berikut :
•
Memberikan gambar model konseptual piranti lunak dari suatu bahasa
pemograman yang tekstual sehingga dapat dimengerti oleh orang yang nonprogrammer.
•
Membangun model yang tepat, tidak ambigu, dan lengkap yang dapat
membantu dalam tahap-tahap dari analisis, perancangan dan implementasi.
•
Dapat memodelkan beberapa jenis bahasa pemograman dan membantu
memetakan kembali model tersebut ke suatu bahasa pemograman yang lain.
•
Membantu dalam dokumentasi perancangan piranti lunak.
27
2.2.4 Beberapa bagian dari UML
A. Class Diagram
Class Diagram menunjukkan entitas yang ada pada sistem dan bagaimana entitas
tersebut saling berhubungan (Booch et al, 1999, p107). Entitas tersebut memiliki atribut
dan perilaku tertentu. Class Diagram memperlihatkan hubungan antar class dan
penjelasan detail tiap-tiap class di dalam logical view dari suatu sistem. Selama proses
analisis, class diagram memperlihatkan aturan-aturan dan tanggung jawab entitas yang
menentukan perilaku sistem. Selama tahap desain, class diagram berperan dalam
menangkap struktur dari semua kelas yang membentuk arsitektur sistem yang dibuat.
Class diagram direpresentasikan dalam bentuk kotak yang terbagi atas tiga bagian yaitu
nama class, atribut, dan perilaku (behaviour), seperti gambar dibawah ini :
Gambar 2.2 : Contoh Class Diagram
Terdapat
juga
hubungan
(relationship)
diantara
class
diagram,
yang
menggambarkan logical connections pada class dan objek. Berikut ini beberapa
relationship yang sering digunakan :
28
•
Association, merupakan hubungan struktural yang menggambarkan hubungan
antara objek.
Gambar 2.3: Contoh association pada Class Diagram
(sumber : http://en.wikipedia.org/wiki/Image:UML_role_example.gif)
•
Aggregation, merupakan bagian khusus dari suatu asosiasi yang menyatakan
“whole-part” (bagian dari).
Gambar 2.4 : Contoh aggregation pada Class Diagram
(sumber : http://en.wikipedia.org/wiki/Image:KP-UML-Aggregation-20060420.svg)
•
Composition, merupakan hubungan asosiasi yang kuat dan lebih spesifik dari
aggregation.
Gambar 2.5 : Contoh composition pada Class Diagram
(sumber : http://upload.wikimedia.org/wikipedia/en/9/9f/AggregationAndComposition.svg)
29
•
Generalization, biasa dikenal juga dengan istilah inheritance yaitu hubungan
yang menyatakan bahwa salah satu dari dua class merupakan turunan yang
lebih khusus dari class induk-nya.
Gambar 2.6 : Contoh generalization pada Class Diagram
(sumber : http://en.wikipedia.org/wiki/Image:KP-UML-Generalization-20060325.svg)
B. Use Case Diagram
Use Case Diagram menggambarkan sekumpulan use case dan aktor serta
hubungannya (Booch et al, 1999, p234). Yang ditekankan adalah “apa” yang dilakukan
terhadap sistem dan bukan “bagaimana”. Sebuah use case menggambarkan interaksi
antara aktor dengan sistem. Dibawah ini dijelaskan bagian use case diagram :
a. Aktor
Aktor adalah segala sesuatu yang melakukan tatap muka dengan sistem, seperti
orang, piranti lunak, piranti keras, atau jaringan (Schneider dan Winters, 1997, p12).
Tiap-tiap aktor menunjukkan perannya masing-masing. Contohnya, seorang aktor
dapat memberikan input ke dalam dan menerima informasi dari aplikasi piranti lunak.
30
Notasi aktor dengan nama aktor tersebut dibawahnya:
Pengguna
b. Use Case
Use Case menggambarkan segala sesuatu yang aktor ingin lakukan terhadap sistem.
Use Case harus merupakan “apa” yang dikerjakan piranti, bukan “bagaimana”
aplikasi piranti lunak mengerjakannya. Suatu sistem yang kompleks memiliki banyak
use case, sehingga perlu diorganisasi.
Notasi use case :
Untuk menghubungkan antara aktor dengan use case digunakan simbol garis yang
disebut sebagai relationship.
Dengan adanya sebuah use case diagram maka akan membantu dalam menyusun
kebutuhan sebuah sistem dan mengkomunikasikannya dengan klien.
31
C. Sequence Diagram
Sequence diagram menggambarkan sekumpulan objek dan interaksinya, termasuk
message yang dikirim terhadap urutan waktu (Booch et al, 1999, p245). Sequence
diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkahlangkah yang dilakukan sebagai tanggapan dari sebuah event untuk menghasilkan
keluaran tertentu.
Diawali dari apa yang memicu aktivitas tersebut, proses dan perubahan apa saja
yang terjadi secara internal dan keluaran yang dihasilkan. Masing-masing objek memiliki
lifeline vertikal sedangkan message digambarkan secara horizontal.
2.3 Estimasi Biaya Proyek Software
Menurut Sommerville (1996, pp590-591), ada tiga parameter yang dilibatkan
dalam software yaitu :
1. Hardware, software, dan maintenance
2. Biaya perjalanan dan pelatihan
3. 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.
32
Sedangkan biaya usaha bukan hanya biaya 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.3.1 Metode Estimasi Biaya
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.
33
3. Analogy, 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 staff
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.
7. Bottom-up, dimana tugas-tugas terkecil dari suatu proyek diidentifikasi
terlebih dahulu dan kemudian estimasi usaaha tiap-tiap tugas tersebut
digabungkan untuk mendapatkan estimasi usaha secara keseluruhan proyek.
Dari 7 teknik yang dipaparkan oleh Barry Boehm, penulis hanya menggunakan
teknik Algorithmic models untuk melakukan estimasi effort pengembangan sebuah projek
software.
34
2.3.2 Metric Software
Metric software digunakan untuk tujuan strategis, digunakan manajer proyek dan
tim software untuk mengadaptasi aliran kerja proyek dan aktifitas teknis.
Metric proyek mempunyai tujuan ganda yaitu untuk meminimalkan jadwal
pengembangan dengan melakukan penyesuaian yang diperlukan untuk menghindari
penundaan serta mengurangi masalah dan resiko potensial. Kedua, metrik proyek dipakai
untuk memperkirakan kualitas produk pada basis yang berlaku dan bila dibutuhkan,
memodifikasi pendekatan teknis untuk meningkatkan kualitas.
2.3.2.1 Source Lines of Code (SLOC)
SLOC adalah software metric yang digunakan untuk memperkirakan besar suatu
aplikasi software dengan menghitung jumlah baris pada text dari source code program.
SLOC biasanya digunakan untuk memprediksikan effort yang dibutukan untuk
mengembangkan sebuah aplikasi.
Pada
awalnya
orang
menggunakan
SLOC,
karena
kebanyakan
orang
menggunakan bahasa pemograman seperti FORTRAN dan assembler yang merupakan
kelompok line-oriented languages.
SLOC pada kenyataannya kurang efektif untuk membandingkan penulisan
program dengan bahasa yang berbeda-beda terkecuali adanya penyesuaian faktor-faktor
yang digunakan untuk menormalisasikan bahasa-bahasa tersebut. Berbagai macam
computer languages menyeimbangkan keringkasan dan kejelasan dalam cara yang
berbeda-beda. Contohnya adalah penggunaan assembly languages membutuhkan ratusan
35
jumlah baris yang lebih banyak dalam melakukan sebuah pekerjaan yang sama seperti
pada APL. Contoh lainnya adalah pembandingan program “Hello Word” yang ditulis
dalam C dan dalam COBOL yang ditulis terlalu kompleks.
Ada beberapa kekurangan yang dimiliki oleh SLOC, diantaranya adalah
kurangnya kemampuan dalam keakuratan penghitungan, hasil estimasi yang didapatkan
jauh dibawah yang sesungguhnya, dan sulit digunakan untuk program yang
menggunakan GUI, dan lainnya.
2.3.2.2 Function Point
Salah satu metode estimasi yang paling populer adalah metode function point
analysis yang merupakan salah satu metode yang berlandaskan pada teknik algorithnic
models yang telah dijelaskan pada bagian 2.31. 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 mengategorikannya sesuai dengan kompleksitas pengembangan relatifnya.
Kelima fungsi tersebut adalah sebagai berikut :
•
Input, adalah layar atau form dimana melaluinya pengguna aplikasi ataupun
program lain dapat menambahkan data baru atau memperbaharui data yang
sudah ada.
•
Output, adalah layar atau laporan yang dihasilkan oleh aplikasi untuk
keperluan pengguna atau untuk program lain.
36
•
Inquiry, adalah layar yang memperbolehkan pengguna untuk mencari lebih
lanjut dari sebuah aplikasi dan untuk meminta bantuan atau informasi, seperti
layar Help.
•
Data File, adalah koleksi logikal dari catatan yang telah dimodifikasi atau
diperbarui oleh aplikasi.
•
Interface, adalah file-file yang dishare dengan aplikasi lain dan meliputi
incoming atau outgoing tape file, database yang dishare, dan daftar
parameter.
Total unadjusted function point didapat dari menghitung jumlah 5 fungsi diatas
dikali dengan bobot masing-masing fungsi sesuai dengan tabel di bawah ini.
Tabel 2.1 : Bobot Masing-Masing Fungsi Pada Function Point
Tipe Fungsi
Bobot
Inputs
4
Outputs
5
Inquiry
4
Logical File
10
Interface
7
Setelah menghitung total unadjusted function-point, maka untuk mendapatkan
adjusted function-point dibutuhkan nilai masing-masing faktor yang mempengaruhi
function-point.
37
Tabel 2.2 : Faktor-faktor yang Mempengaruhi Function Point
Faktor
Data communications
Distributed functions
Performance objectives
Heavily used configuration
Transaction rate
On-line data entry
End-user efficiency
On-line update
Complex processing
Reusability
Installation ease
Operational ease
Multiple sites
Facilitate change
Faktor-faktor yang mempengaruhi function-point menggunakan nilai pengaruh
dari skala 0 sampai 5, dimana 0 berarti sangat sederhana dan 5 yang berarti sangat
kompleks atau rumit.
Kemudian untuk mendapatkan nilai dari function point kita harus menghitung
terlebih dahulu nilai dari Complexity Multiplier atau value adjustment factor yang
kemduian di kalikan dengan unadjusted function-point.
38
Constructice Cost Model
Cocomo (Cocomo 81) dirumuskan berdasarkan model yang didapat oleh Boehm
pada tahu 1970 yang melakukan penelitian pada 63 proyek dimana hanya 7 diantaranya
yang merupakan sistem bisnis.
Model Cocomo didasarkan pada persamaan :
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
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.
39
Tabel 2.3 : 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.
40
2.3.2.3 OO-Metric
Chidamber dan Kemerer mendefinisikan 6 metric baru bagi software yang
dikembangkan dengan metode object oriented. Dimana perhitungan metric ini
beranggapan bahwa method-method pada setiap class yang ada bukan merupakan
constructor, destructor, setter, dan getter pada sebuah class.
Gambar 2.7 Contoh Class Diagram sebuah Aplikasi
41
Weighted Method per Class (WMC)
WMC adalah jumlah method yang diimplementasi dalam class atau total
kompleksitas dari method-methodnya. Jumlah method yang ada dan kompleksitas dari
method-method yang digunakan bisa digunakan untuk memprediksikan berapa waktu dan
usaha yang dibutuhkan untuk mengembangkan dan memelihara sebuah class. Semakin
banyak jumlah method dalam sebuah class, semakin besar dampak potensial terhadap
class turunannya; class turunannya mewarisi semua method yang didefinisikan pada class
induknya. Class dengan jumlah method yang besar biasanya untuk aplikasi yang spesifik,
dan jarang bisa untuk digunakan kembali. WMC sangat baik untuk menjadi indikator
untuk implementation dan test effort.
Mengacu pada figure 4 diatas, WMC yang didapatkan dengan menghitung jumlah
method pada tiap class adalah sebagai berikut :
Tabel 2.4 : Nilai WMC pada Class Diagram (Gambar 2.7)
Nama Class
WMC
Class1
1
Class2
1
Class3
1
Class4
3
Class5
1
Class6
2
42
Depth of The Inheritance Tree (DIT)
DIT adalah kedalaman dari hirarki class, dimana mendefinisikan panjang
maksimum dari node hingga mencapai root dari tree. Makin dalam sebuah class dalam
hirarkinya akan semakin baik kompleksitas desain-nya, dan membuat class tersebut lebih
kompleks untuk diprediksi sifatnya. Semakin besar DIT maka akan semakin reuse tetapi
juga memunculkan kesulitan dalam understandabilty dan testability.
Mengacu pada figure 4 diatas, DIT yang didapatkan dengan menghitung
kedalaman hirarki pada tiap class-nya adalah sebagai berikut :
Tabel 2.5 : Nilai DIT pada Class Diagram (Gambar 2.7)
Nama Class
DIT
Class1
1
Class2
1
Class3
1
Class4
1
Class5
2
Class6
2
43
Number Of Children (NOC)
NOC adalah jumlah class yang diturunkan secara langsung dalam sebuah hirarki
class. Semakin baik NOC maka semakin reuse dan semakin besar kemungkinan dari
kesalahan abstraksi pada class induknya dan mungkin juga sebagai penyalahgunaan dari
pengertian subclasses. NOC juga bisa dijadikan sebagai indikator dari reusability dan
testing effort.
Mengacu pada figure 4 diatas, NOC yang didapatkan dengan menghitung jumlah
class turunan secara langsung dari sebuah class adalah sebagai berikut :
Tabel 2.6 : Nilai NOC pada Class Diagram (Gambar 2.7)
Nama Class
NOC
Class1
0
Class2
0
Class3
0
Class4
2
Class5
0
Class6
0
44
Response for a Class (RFC)
RFC adalah jumlah dari method yang dapat digunakan dalam merespon suatu
pesan terhadap sebuah class. Termasuk didalamnya semua method yang dapat diakses
dalam hirarki class. Dimana metric ini melihat kombinasi dari kompleksitas sebuah class
melalui jumlah method dan banyaknya komunikasi dengan class-class lain. Jika semakin
besar jumlah method yang dapat di gunakan untuk meresponse sebuah pesan, maka
testing dan debugging dari class akan menjadi lebih complex dikarenakan semakin
besarnya level dalam memahami bagian oleh tester. Semakin besar jumlah method yang
bisa digunakan oleh sebuah class, maka akan semakin besar kompleksitas dari sebuah
class. RFC bisa dijadikan indikator untuk mengukur design complexity dan testabilty.
Mengacu pada figure 4 diatas, RFC yang didapatkan dengan menghitung jumlah
method yang digunakan dalam sebuah class adalah sebagai berikut :
Tabel 2.7 : Nilai RFC pada Class Diagram (Gambar 2.7)
Nama Class
RFC
Class1
1
Class2
1
Class3
1
Class4
3
Class5
4
Class6
5
45
Coupling between Object Classes (CBO)
CBO adalah jumlah hubungan dari suatu class dengan class lainnya yang bukan
merupakan class turunannya. Coupling yang terlalu banyak antara objek class dapat
merusak perancangan modular dan mengurangi reuse. Semakin independent class
tersebut semakin mudah untuk digunakan kembali pada aplikasi lain. Semakin besar
coupling maka akan semakin sensitif untuk merubah bagian lain pada perancangan,
sehingga proses maintanance akan menjadi semakin sulit. Pengukuruan coupling ini
sangat baik untuk menggambarkan seberapa besar kompleksitas dalam melakukan testing
pada setiap bagian dari desain. CBO dapat mengevaluasi dalam implementasi
perancangan dan reusablity.
Mengacu pada figure 4 diatas, CBO yang didapatkan dari jumlah hubungan suatu
class dengan class laiinnya yang bukan merupakan class turunannya adalah sebagai
berikut :
Tabel 2.8 : Nilai CBO pada Class Diagram (Gambar 2.7)
Nama Class
CBO
Class1
1
Class2
2
Class3
0
Class4
0
Class5
0
Class6
0
46
Lack of Cohesion in Methods (LCOM)
LCOM adalah salah satu metric yang dapat digunakan untuk mengevaluasi sistem
software yang berorientasi objek. LCOM sangat baik digunakan untuk menghitung
kohesi pada sistem. Rendahnya kohesi dapat meningkatkan kompleksitas, sehingga
secara tidak langsung juga meningkatkan kemungkinan terjadinya error selama proses
pengembangan. Sedangkan, semakin tinggi kohesi mengindikasikan semakin baik
subdivision dari class. LCOM adalah indikator langsung untuk menunjukkan
kompleksitas design dan reusability.
Mengacu pada contoh class diagram diatas, dimana untuk class4 method
operation4a() menggunakan 2 attribut, operation4b() menggunakan 2 attribut, dan
operatiob4c() menggunakan 1 attribut, sehingga LCOM untuk setiap class pada figure 4
diatas, adalah sebagai berikut :
47
Tabel 2.9 : Nilai LCOM pada Class Diagram (Gambar 2.7)
Nama Class
LCOM
Class1
0
Class2
0
Class3
0
Class4
2
Class5
0
Class6
1
2.3.2.4 Use Case Point
Untuk mengetahui kebutuhan fungsional suatu proyek software , model use case
seringkali digunakan. Pemodelan use case adalah suatu teknik yang telah digunakan
sebagian besar industri untuk menggambarkan dan mengetahui kebutuhan fungsional dari
sebuah sistem software. Use case points adalah suatu metode baru untuk meng-estimasi
pengembangan software. Semenjak use case dikembangkan sebagai suatu bagian biasa
dari penggabungan kebutuhan dan analisis, dan semenjak use case dapat mengetahui dan
secara akurat merepresentasikan kebutuhan user, masuk akal untuk mendasarkan suatu
tugas yang lebih sulit dari estimasi ukuran dan sumber kebutuhan padanya, sebagai
perbandingan pada teknik-teknik yang lain seperti function point, LOC, dll. Keuntungan
lain dari penggunaan use case sebagai dasar estimasi bahwa use case dapat diamati dari 2
arah dengan kemampuan untuk menelusuri kebutuhan modern dari bagian-bagian
manajemen.
48
Bente Anda membandingkan metode use case point dengan estimasi expert yang
dibuat dari pengalaman pengembang software. Metode Use case point memberikan
sebuah estimasi yang hampir mendekati estimasi sebenarnya yang dihasilkan dari
pengalaman pengembang software. Metode estimasi itu memberikan tingkat kepuasan
yang besar dari besarnya relatif error yang ada bersama kendala estimasi.
Hasil dari pembelajaran ini menunjukkan bahwa metode use case point dapat
dengan sukses digunakan untuk meng-estimasi effort dari suatu pengembangan software.
Penjelasan mengengai use case point akan lebih dijelaskan secara detail pada bagian 2.4.
2.4 Estimasi Use Case Point
Estimasi awal terhadap effort suatu sistem yang berdasarkan pada use case dapat
dilakukan ketika sudah dapat memahami permasalahan-permasalahan yang ada, ukuran
sistem, dan arsitektur pada tahapan dimana estimasi akan dibuat. Metode use case point
adalah pengukuran software dan metode estimasi yang berdasarkan pada hitungan use
case yang disebut use case point.
49
2.4.1 Klasifikasi Aktor dan Use Case
Use case point dapat dihitung dari analisis use case pada sistem. langkah pertama
adalah menentukan terlebih dahulu aktor sebagai simple, average, atau complex.
Tabel 2.10 Tipe, Bobot, dan Deskripsi Aktor pada Use Case Point
Actor
Weight
Description
Simple
1
Didefinisikan dengan API
Medium
2
Interactive atau Berinteraksi Melalui Protokol,
Seperti TCP/IP
Complex
3
Berinteraksi dengan GUI atau Web Page
Total Unadjusted Actor Weights (UAW) didapat dari menghitung berapa banyak
aktor dari masing-masing jenis ( tingkat kompleksitas ),dikali dengan total faktor berat
masing-masing sesuai dengan tabel.
Masing-masing use case di bagi juga menjadi simple, average, dan complex.
Tergantung dari jumlah transaksi yang dilakukan dalam deskripsi use case. Transaksi
merupakan kumpulan dari aktifitas, dimana berada seutuhnya, atau tidak sama sekali.
Penghitungan jumlah transaksi dapat dilakukan dengan menghitung langkah-langkah use
case. Pada metode ini Karner tidak mengajukan penghitungan terhadap included use case
dan extended use case, tetapi sebabnya belum bisa dijelaskan.
50
Tabel 2.11 Tipe, Bobot, dan Deskripsi Use Case pada Use Case Point
Use Case
Weight
Description
Simple
5
Menggunakan <= 3 transaksi
Medium
10
Menggunakan 4 sampai 7 transaki
Complex
15
Menggunakan > 7 transaksi
Total Unadjusted Use Case Weights (UUCW) didapat dari menghitung berapa
banyak use case dari masing-masing jenis ( tingkat kompleksitas ),dikali dengan total
faktor berat masing-masing sesuai dengan tabel.
Kemudian jumlahkan UAW dan UUCW untuk mendapatkan Unadjusted Use
Case Point (UUCP).
2.4.2 Faktor-Faktor pada Use Case
Pada metode use case point ini juga terdapat teknikal faktor yang mengacu pada
faktor-faktor Technical Complexity Adjustment yang terdapat pada metode Function
Point Analysis, dan faktor-faktor enviromental yang digunakan untuk menghitung fungsifungsi yang tidak fungsional yang biasa digunakan untuk mempermudah pekerjaan
seorang programmer.
51
Faktor-faktor tersebut memiliki bobot nilai, dan nilai-nilai akan diberikan pada
setiap faktor, tergantung dari seberapa besar pengaruh dari faktor tersebut. 0 berarti tidak
mempengaruhi, 3 berarti rata-rata, dan 5 berarti memberikan pengaruh yang besar.
Faktor-faktor tambahan akan dikalikan dengan unadjusted use case points untuk
menghasilkan adjusted use case points, dan akhirnya digunakan untuk menentukan
ukuran dari software.
Tabel 2.12 Technical Factor
Technical Factor
Weight
Distributed System
2
Performance
1
End User Efficiency
1
Complex Internal Processing
1
Code must be reusable
1
Easy to Install
0.5
Easy to Use
0,5
Portable
2
Easy to change
1
Multi-threaded application
1
Special security features
1
Direct access to other systems
1
Special user training facilities are required
1
52
Nilai-nilai pada technical factor tersebut dikalikan dengan bobot nilai masinmasing, kemudian dijumlah untuk mendapatkan total technical factor (TF), yang
kemudian digunakan untuk mendapatkan Techinal Complexity Factor (TCF).
Tabel 2.13 Enviromental Factor
Enviromental Factor
Weight
Familiarity with UML
1.5
Application Experience
0.5
Object Oriented Experience
1
Lead Analyst Capbility
0.5
Team Motivation
1
Stable Requirements
2
Project team is part-time
-1
Difficult Programming Language
-1
Nilai-nilai pada enviromental factor tersebut dikalikan dengan bobot nilai masingmasing, kemudian dijumlah untuk mendapatkan total enviromental factor (EF), yang
kemudian digunakan untuk mendapatkan Enviromental Complexity Factor (ECF).
53
Sehingga akhirnya kita bisa mendapatkan nilai dari Adjusted Use Case Point
(UCP) yang didapatkan melalui perkalian UUCP, TCF, dan ECF.
2.4.3 Estimasi Bedasarkan Use Case Point
Untuk merubah nilai UCP yang didapatkan menjadi nilai effort yaitu staff hours,
maka nilai UCP harus dikalikan dengan nilai staff-hour per use case point, Karner
mengemukakan nilai 20 staff hours untuk setiap use case point untuk estimasi akhir
sebuah proyek. Pengalaman langsung telah menunjukkan bahwa nilai staff-hour dapat
berkisar dari 15 sampai 30 jam untuk setiap use case point, dimana nilai ini akan
mengubah secara langsung use case point ke dalam waktu perkiraan yang mungkin masih
belum memiliki kepastian.
54
2.5 Java
2.5.1 Sejarah Perkembangan Java
Bahasa pemograman Java pertama kali lahir dari The Green Project, yang berjalan
selama 18 bulan, dari awal tahun 1991 hingga musim panas 1992. Proyek tersebut belum
menggunakan versi yang dinamakan Oak. Proyek ini dimotori oleh Patrih Naughton,
Mike Sheridan, James Gosling dan Bill Joy, beserta sembilan programmer lainnya dari
Sun Microsystems. Salah satu hasil proyek ini adalah maskot Duke yang di buat oleh Joe
Palrang.
Pertemuan proyek berlangsung di sebuah gedung perkantoran Sand Hill Road di
Menlo Park. Sekitar musim panas 1992 proyek ini ditutup dengan menghasilkan sebuah
program Java Oak pertama, yang ditujukan sebagai pengendali sebuah peralatan dengan
teknologi layar sentuh (touch screen), seperti pada PDA sekarang ini. Teknologi baru ini
dinamai “*7” (Star Seven).
Setelah era Star Seven selesai, sebuah anak perusahaan TV kabel tertarik
ditambah beberapa orang dari proyek The Green Project. Mereka memusatkan
kegiatannya pada sebuah ruangan kantor di 100 Hamilton Avenue, Palo Alto.
Perusahaan ini bertambah maju, jumlah karyawan meningkat dalam waktu singkat
dari 13 menjadi 70 orang. Pada rentang waktu ini juga ditetapkan pemakaian internet
sebagai medium yang menjembatani kerja dan ide di antara mereka. Pada awal tahun
1990-an, internet masih merupakan rintisan, yang dipakai hanya di kalangan akademis
dan militer.
55
Mereka menjadikan browser Mosaic sebagai landasan awal untuk membuat
browser Java pertama yang dinamai Web Runner, terinspirasi dari film 1980-an, Blade
Runner. Pada perkembangan rilis pertama, Web Runner berganti nama menjadi Hot Java.
Pada sekitar bulan Maret 1995, untuk pertama kali kode sumber Java versi 1.0a2
dibuka. Kesuksesan mereka diikuti dengan pemberitaan pertama kali pada surat kabar
San Jose Mercury News pada tanggal 23 Mei 1995.
Sayang terjadi perpecahan di antara mereka suatu hari pada pukul 04.00 di sebuah
ruangan hotel Sheraton Palace. Tiga dari pimpinan proyek, Eric Schmidt dan George
Paolini dari Sun Microsystems bersama Marc Andreessen, membentuk Netscape.
Nama Oak, diambil dari pohon oak yang tumbuh di depan jendela ruangan kerja
“bapak java”, James Gosling. Nama Oak ini tidak dipakai untuk versi release Java karena
sebuah perangkat lunak sudah terdaftar dengan merek dagang tersebut, sehingga diambil
nama penggantinya menjadi “Java”. Nama ini diambil dari kopi murni yang digiling
langsung dari biji (kopi tubruk) kesukaan Gosling.
56
2.5.2 Kelebihan Java
Beberapa kelebihan dari menggunakan bahasa pemograman java adalah sebagai
berikut :
•
Multiplatform. Kelebihan utama dari Java ialah dapat dijalankan di beberapa
platform/sistem operasi komputer, sesuai dengan prinsip “tulis sekali, jalankan
di mana saja”. Dengan kelebihan ini pemogram cukup menulis sebuah
program Java dan dikompilasi (diubah, dari bahasa yang dimengerti manusia
menjadi bahasa mesin / bytecode) sekali lalu hasilnya dapat dijalan diatas
beberapa platform tanpa perubahan. Kelebihan ini memungkinkan sebuah
program berbasis java dikerjakan diatas operating system Linux tetapi
dijalankan dengan baik di atas Microsoft Windows. Platform yang didukung
sampai saat ini adalah Microsoft Windows, Linux, Mac OS dan Sun Solaris.
Penyebabnya adalah setiap sistem operasi menggunakan programnya sendirisendiri (yang dapat didapatkan dari situs Java) untuk meninterpretasikan
bytecode tersebut.
•
OOP (Object Oriented Programming – Pemograman Berorientasi Objek)
yang artinya semua aspek yang terdapat di Java adalah Objek. Java
merupakan salah satu bahasa pemograman berbasis objek secara murni.
Semua tipe data diturunkan dari kelas dasar yang disebut Object. Hal ini
sangat
memudahkan
pemrogram
untuk
mendesain,
membuat,
mengembangkan dan mengalokasi kesalahan sebuah program dengan basis
Java secara cepat, tepat, mudah dan teroganisir. Kelebihan ini menjadikan
57
Java sebagai salah satu bahasa pemograman termudah, bahkan untuk fungsifungsi yang advance seperti komunikasi antara komputer sekalipun.
•
Perpustakaan Kelas Yang Lengkap, Java terkenal dengan kelengkapan
library / perpustakaan (kumpulan program yang disertakan dalam
pemrograman java) yang sangat memudahkan dalam penggunaan oleh para
pemrogram untuk membangun aplikasinya. Kelengkapan perpustakaan ini
ditambah dengan keberadaan komunitas Java yang besar yang terus-menerus
membuat
perpustakaan-perpustakaan
baru
untuk
melingkupi
seluruh
kebutuhan pembangunan aplikasi.
•
Bergaya C++, memiliki sintaks seperti bahasa pemrograman C++ sehingga
menarik banyak programmer C++ untuk pindah ke Java. Saat ini pengguna
Java sangat banyak, sebagian besar adalah programmer C++ yang pindah ke
Java. Universitas-universitas di Amerika juga mulai berpindah dengan
mengajarkan Java kepada murid-murid yang baru karena lebih mudah
dipahami oleh murid dan dapat berguna juga bagi mereka yang bukan
mengambil jurusan komputer.
•
Pengumpulan sampah otomatis, memiliki fasilitas pengaturan penggunaan
memori sehingga para pemogram tidak perlu melakukan pengaturan memori
secara langsung (seperti halnya dalam bahasa C++ yang dipakai secara luas).
58
2.5.3 Kekurangan Java
Selain kelebihan-kelebihan java yang telah dtuliskan diatas, juga terdapat
kekurangan dalam menggunakan bahasa pemograman java adalah sebagai berikut :
•
Tulis sekali, perbaiki di mana saja, Masih ada beberapa hal yang tidak
kompatibel antara platform satu dengan platform lain. Untuk J2SE, misalnya
SWT-AWT bridge yang sampai sekarang tidak berfungsi pada Mac OS X.
•
Mudah didekompilasi, Dekompilasi adalah proses membalikkan dari kode
jadi menjadi kode sumber. Ini dimungkinkan karena kode dari Java
merupakan bytecode yang menyimpan banyak atribut bahasa tingkat tinggi,
seperti nama-nama kelas, metode, dan tipe data. Hal yang sama juga terjadi
pada Microsoft .Net Platform. Dengan demikian, algoritma yang digunakan
program akan lebih sulit desembunyikan dan mudah dibajak / di reverseengineer.
•
Penggunaan memori yang banyak, Penggunaan memori untuk program
berbasis Java jauh lebih besar daripada bahasa tingkat tinggi generasi
sebelumnya seperti C/C++ dan Pascal (lebih spesifik lagi, Delphi dan Object
Pascal). Biasanya ini bukan merupakan masalah bagi pihak yang
menggunakan teknologi terbaru (karena trend memori terpasang makin
murah), tetapi menjadi masalah bagi mereka yang masih harus berkutat
dengan mesin komputer berumur lebih dari 4 tahun.
59