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
