22

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.

23

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

24

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.

25

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)

26

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 bentuk-

bentuk 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.

27

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 non-

programmer.

• 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.

28

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 :

29

• 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)

30

• 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.

31

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.

32

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 langkah-

langkah 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.

33

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.

34

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.

35

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

36

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.

37

• 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.

38

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.

39

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.

40

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.

41

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

42

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

43

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

44

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

45

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

46

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

47

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 :

48

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.

49

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.

50

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.

51

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 fungsi-

fungsi yang tidak fungsional yang biasa digunakan untuk mempermudah pekerjaan

seorang programmer.

52

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

53

Nilai-nilai pada technical factor tersebut dikalikan dengan bobot nilai masin-

masing, 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 masing-

masing, kemudian dijumlah untuk mendapatkan total enviromental factor (EF), yang

kemudian digunakan untuk mendapatkan Enviromental Complexity Factor (ECF).

54

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.

55

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.

56

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.

57

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 sendiri-

sendiri (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

58

Java sebagai salah satu bahasa pemograman termudah, bahkan untuk fungsi-

fungsi 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).

59

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 reverse-

engineer.

• 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.