 12
Definisi perangkat lunak menurut Pressman adalah: (Pressman, 2010)
Instruksi (program komputer) yang ketika dijalankan
akan menyediakan
fitur, fungsi dan hasil yang diinginkan
Struktur data yang mengaktifkan program untuk memanipulasi informasi,
dan
Deskripsi informasi dari kedua point diatas yang menggambarkan operasi
dan penggunaan program.
Karakteristik perangkat lunak yang membedakan dengan perangkat
keras menurut Pressman diantaranya: (Pressman, 2010)
“Software is developed or engineered;
it is not manufactured in the
classical sense”.Yang dimaksud adalahperangkat lunak merupakan
suatu
produk yang lebih menekankan pada kegiatan rekayasa (engineering)
dibandingkan kegiatan manufacturing.
Software doesn’t “wear out”. Artinya adalahperangkat lunak bukanlah
produk yang dapat usang atau rusak untuk kemudian dibuang, seperti
|
 13
halnya pada produk perangkat keras. Yang mungkin terjadi adalah
produkperangkat lunak tersebut tidak dapat memenuhi kebutuhan
penggunanya disebabkan berkembangnya kebutuhan-kebutuhan baru.
Sehingga perlu dilakukan perubahan
pada perangkat lunak tersebut.
Berikut ini terdapat 2 (dua) kurva yang menjelaskan hubungan antara
tingkat kerusakan dan waktu pada masing-masing perangkat baik itu
perangkat keras maupun perangkat lunak.
Kurva yang menggambarkan siklus hidup perangkat keras atau
biasa disebut dengan “bathtub curve” ditunjukkan pada gambar dibawah
ini:
(Pressman, 2010)
Gambar diatas menjelaskan tingkat kerusakan/kegagalan yang
terjadi pada perangkat keras. Mengindikasikan kegagalan yang relatif
|
 14
tinggi pada masa awal terciptanya perangkat keras tersebut, tingkat
terendah terjadi pada keadaan dimana dilakukan perubahan dan perbaikan
pada perangkat keras untuk memenuhi kebutuhan penggunanya dan seiring
dengan berjalannya waktu tingkat kegagalan mengalami peningkatan yang
relatif tinggi yang disebabkan oleh terjadinya kerusakan-kerusakan,
penyalahgunaan, faktor lingkungan yang berpengaruh pada kestabilan
penggunaan perangkat keras.
Berikut ini adalah kurva yang menjelaskan siklus hidup perangkat
lunak, terdapat 2 (dua) kurva diantaranya “Idealized curve” dan “Actual
curve”:
(Pressman, 2010)
Dari gambar diatas, Idealized curve
menjelaskan bahwa tingginya
tingkat kerusakan yang terjadi disebabkan oleh kecacatan yang belum
|
 15
ditemukan pada masa awal terciptanya perangkat lunak tersebut. Namun
masalah itu bisa diselesaikan dan diperbaiki untuk memenuhi kebutuhan
penggunanya, dan tingkat kegagalan menurun secara berkala seperti yang
ditunjukkan pada gambar. Kondisi ini menjelaskan bahwa perangkat lunak
tidak akan pernah usang atau rusak melainkan hanya mengalami penurunan
kualitas.
Pada actual curve
dijelaskan bahwa selama masa hidupnya
perangkat lunak mengalami perubahan-perubahan demi memenuhi
kebutuhan penggunanya, selama perubahan itu terjadi maka akan
ditemukan kesalahan-kesalahan yang tidak diinginkan, hal ini
menyebabakan kurva mengalami peningkatan untuk tingkat kerusakan
yang terjadi selama perubahan dan penemuan error
tersebut seperti
ditunjukkan pada gambar kurva aktual diatas. Sebelum kurva kembali ke
keadaan awal, terjadi permintaan perubahan lain, hal ini menyebabkan
kurva kembali meningkat. Dalam kasus ini perangkat lunak hanya
mengalami penurunan kualitas yang disebabkan oleh perubahan.
Although the industry is moving toward component-based construction,
most software continues to be custom built. Artinya adalahsebagian besar
perangkat lunak tidak dibangun dari perangkat lunak
yang sudah ada.
Pembangunan aplikasi baru kebanyakan dimulai dari awal, dari tahap
analisis sampai tahap pengujian. Namun demikian, kini paradigma baru
mulai dikembangkan, yaitu konsep reuseabilityatau penggunaan kembali.
|
|
16
Dengan konsep ini suatu aplikasi baru dapat dikembangkan dari aplikasi
yang sudah ada yang menerapkan konsep reusability tersebut.
Object Oriented Programming
adalah paradigma pemrograman yang
memandang perangkat lunak sebagai kumpulan objek yang saling berinteraksi di
dalam suatu sistem. (Aziz) Beberapa objek berinteraksi dengan saling memberikan
informasi satu terhadap yang lainnya. Masing-masing objek harus berisikan
informasi mengenai dirinya sendiri (encapsulation) dan objek yang dapat dikaitkan
(inheritance). (Febrian)
Dalam OOP, Class
merupakan sekumpulan objek yang memiliki atribut-
atribut dan method. Class
merupakan deskripsi dari satu atau lebih objek yang
memiliki kesamaan atribut, layanan, metode, hubungan, dan semantik, termasuk
deskripsi cara membuat objek baru dalam class. Ada juga yang disebut dengan
superclass, sebuah class
induk yang nantinya mempunyai class-class
yang terdiri
dari class dan subclass. (Lethbridge & Laganiere, 2005)
Objek dalam OOP adalah sebuah benda atau unit atau sifat kerja yang
memiliki atribut-atribut. Objek adalah sebuah abstraksi dari sesuatu pada domain
masalah, menggambarkan kemampuan untuk menyimpan informasi mengenai hal
tersebut, berinteraksi dengan hal tersebut atau keduanya.(Lethbridge & Laganiere,
2005)
Abstraksi prosedural dalam OOP disebut dengan operasi, yang menjelaskan
tipe dari perilaku dan terdiri dari fungsi-fungsi. (Lethbridge & Laganiere, 2005)
|
|
17
Selain yang disebutkan di atas, istilah lainnya yaitu encapsulation/
pengkapsulan, yang merupakan pembatasan ruang lingkup program terhadap data
yang diproses agar data terlindungi oleh prosedur atau objek lain, kecuali prosedur
yang berada di objek itu sendiri. (Lethbridge & Laganiere, 2005)
Polymorphism
adalah konsep yang menyatakan bahwa sesuatu yang sama
dapat mempunyai bentuk dan perilaku yang berbeda, bahwa operasi yang sama
mungkin memiliki perbedaan dalam class yang berbeda. (Lethbridge & Laganiere,
2005)
Pada OOP, terdapat juga istilah yang disebut dengan inheritance
(pewarisan), yaitu kepemilikan yang bersifat implicit
dari fitur subclass
yang
didefinisikan dalam superclass. Fitur tersebut mencakup variabel dan method.
(Lethbridge & Laganiere, 2005)
Menurut Pressman (Pressman, 2010) sistem aplikasi berbasis web(WebApps)
berbeda dengan sistem dan aplikasi lain karena hal-hal dibawah ini:
1.
Network intensiveness
Sifat dasar dari WebApps adalah sistem ini ditujukan untuk berada di jaringan
dan memenuhi kebutuhan komunitas yang berbeda.
2.
Concurrency
Pengguna dapat mengakses WebApps dalam satu waktu secara bersamaan.
|
|
18
3.
Unpredictable load
Banyaknya pengguna yang mengakses WebApps tidak bisa diprediksi dari hari
ke hari.
4.
Performance
Jika pengguna WebApps harus menunggu respon dari sistem, maka pengguna
dapat memilih untuk meninggalkan halaman tersebut dan pindah ke tempat lain.
5.
Availability
Ketersediaan WebApps
untuk dapat diakses secara terus menerus dalam
24/7/365.
6.
Data driven
Sebagian besar dari fungsi WebApps adalah untuk menyajikan informasi dalam
bentuk teks, grafik, audio, dan video.
7.
Content sensitive
Kualitas dan estetika dari content merupakan penentu utama bagaimana kualitas
WebApps.
8.
Continuous evolution
WebApps selalu berkembang secara terus menerus.
9.
Immediacy
Kebutuhan yang mendesak untuk mendapatkan perangkat lunak yang dapat
digunakan oleh pengguna akhir dapat dengan cepat diselesaikan oleh sistem
WebApps dalam beberapa hari atau minggu.
|
|
19
10. Security
Tingkat keamanan yang sulit untuk WebApps. Karena berada di jaringan, sulit
untuk menjamin content aplikasi yang sensitive dari pengguna akhir yang tidak
baik. Sulit untuk membatasi populasi pengguna yang ingin mengakses aplikasi.
11. Aesthetic
Segi keindahan tampilan untuk menarik minat pengguna. Ketika WebApps
didesain untuk pengguna, tampilan yang baiklah yang banyak digunakan oleh
pengguna WebApps.
Sistem dan aplikasi berbasis web (WebApps)
memiliki beberapa kelebihan,
antara lain:(Darie, Brinzarea, Filip, & Bucica, 2006)
1.
Web application
mudah dan murah untuk pengiriman (deliver).
Dengan web
application, perusahaan bisa mengurangi biaya pada bagian IT untuk instalasi
perangkat lunak setiap komputer pengguna di perusahaan karena komputer
pengguna hanya cukup memiliki browser dan koneksi internet/intranet.
2.
Web application mudah dan murah untuk ditingkatkan (upgrade). Karena biaya
upgrade setiap komputer pengguna di perusahaan cenderung mahal dan harganya
hampir seperti membeli perangkat lunak baru maka dengan web application
cukup hanya upgrade
server saja dan semua pengguna di perusahaan dapat
menikmati aplikasi baru.
3.
Web application memiliki persyaratan yang fleksibel untuk penggunanya. Cukup
hanya menginstalasi web application
pada server perusahaan maka semua
|
|
20
komputer pengguna, baik yang menggunakan Windows, Mac, atau Linux, dapat
menggunakan tanpa ada kendala pada perbedaan platform.
4.
Web application
memudahkan untuk menyimpan data secara terpusat. Ketika
berada pada lokasi yang berbeda dan ingin mengakses data yang sama pada
setiap komputer yang digunakan, cukup dengan server saja. Dengan cara ini, bisa
meminimalkan biaya operasi untuk sinkronisasi data dan menurunkan risiko
keamanan yang ada.
Menurut Pressman (Pressman, 2010) dalam konteks rekayasa perangkat
lunak, ukuran merupakan indikasi yang bernilai kuantitatif yang didapatkan
dari perhitungan luas, jumlah, dimensi, kapasitas atau ukuran dari atribut
sebuah produk atau proses. Pengukuran adalah aksi atau tindakan untuk
menentukan ukuran.
Prinsip dasar pengukuran menurut Roche
dalam buku “Software
Engineering a Practitioner’s Approach”(Pressman, 2010)menunjukkan
bahwa pengukuran dapat dikategorikan
berdasarkan lima kegiatan,
diantaranya:
1.
Formulation: menentukan cara perhitungan yang akan digunakan dalam
mengukur suatu perangkat lunak dan metrik yang sesuai untuk
diterapkan.
|
|
21
2.
Collection: mekanisme yang digunakan untuk mengakumulasi data yang
dibutuhkan untuk memperoleh perumusan metrik.
3.
Analysis: perhitungan metrik dan penerapan matematika.
4.
Interpretation: evaluasi metrik yang menghasilkan pemahaman mengenai
representasi kualitas.
5.
Feedback: rekomendasi yang diperoleh dari interpretasi metrik sebuah
produk yang ditransmisikan ke tim software.
Definisipengukuran menurut Pressman (Pressman, 2001)dibagi menjadi
2 cara, yaitu:
1.
Pengukuran langsung, dalam proses rekayasa perangkat lunak
berhubungan dengan biaya dan usaha, misalnya: perhitungan jumlah Line
Of Code(LOC), kecepatan eksekusi, ukuran memori dan kesalahan yang
ditemui dalam suatu periode waktu.
2.
Pengukuran
tidak langsung dari suatu produk berhubungan dengan
fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, dan lain
sebagainya. Pengukuran
secara langsung lebih mudah dilakukan, karena
hasil dapat diperoleh secara langsung, sedangkan pengukuran tidak
langsung lebih sulit dilakukan, karena melalui proses yang lebih
kompleks.
|
 22
Menurut Pressman (Pressman, 2010) metrik Function Point (FP) dapat
digunakan untuk mengukur fungsionalitas yang dikirim oleh sistem. Dengan
menggunakan data historis, metrik Function Point dapat digunakan untuk:
1.
Memperkirakan biaya atau upaya yang dibutuhkan dalam desain, kode
dan menguji perangkat lunak.
2.
Memprediksi jumlah kesalahan yang akan ditemui selama pengujian.
3.
Memperkirakan jumlah komponen dan/atau jumlah baris kode dalam
sistem.
Keuntungan menggunakan metode Function Point
menurut Galin
diantaranya: (Galin, 2004)
Estimasi dapat dipersiapkan pada tahap pra-proyek dan oleh karena itu
dapat mendukung manajemen dalam upaya persiapan proyek.
Function point tidak bergantung pada bahasa pemrograman, sehingga
keandalan metode ini relatif tinggi.
Kerugian menggunakan metode Function Point
menurut Galin
diantaranya: (Galin, 2004)
Untuk tingkat tertentu, hasil perhitungan Function Point bergantung pada
perhitungan Function Point dengan instruksi manual yang digunakan oleh
project manageruntuk mempersiapkan estimasi.
|
 23
Estimasi harus didasarkan pada spesifikasi sistem perangkat lunak secara
mendetail yang tidak selalu tersedia pada tahap pra-proyek.
Seluruh proses perhitungan memerlukan orang yang berpengalaman.
Banyaknya evaluasi yang dibutuhkan berdampak pada hasil yang
subjektif.
Perhitungan function point
dilakukan hanya didasarkan pada sistem
pemrosesan data. Pada kenyataannya aspek-aspek lain dari
pengembangan sistem perangkat lunak
juga ikut berpengaruh terhadap
pengembangan itu sendiri. Oleh karena itu metode function point tidak
dapat diterapkan secara universal atau masih membutuhkan dukungan
perhitungan faktor lain untuk memperkuat estimasi.
Pengukuran perangkat lunak dibawah ini berdasarkan teori dari Laird
dan Brennan dalam bukunya “Software Measurement and Estimation”,
diantaranya: (Laird & Brennan, 2006)
1.
Ukuran adalah salah satu atribut dasar dari perangkat lunak.
Beberapa pertanyaan mengenai informasi yang ingin diperoleh dari
pengukuran ukuran sebuah perangkat lunak diantaranya:
a.
Seberapa besar ukuran sebuah perangkat lunak ? Seberapa besar proyek
tersebut dibandingkan dengan proyek lainnya?
|
 24
b.
Berapa banyak usaha yang dibutuhkan untuk membangun perangkat
lunak?
c.
Bagaimana kualitas proyek tersebut dibandingkan dengan proyek
lainnya?
d.
Bagaimana produktifitas proyek tersebut dibandingkan dengan proyek
lainnya?
Ukuran adalah dasar untuk semua metrik. Untuk menjawab
pertanyaan tersebut harus mampu untuk mengukur ukuran dengan standar
yang memungkinkan dengan membandingkan suatu proyek dengan proyek
lainnya, dan menjadi sebuah tolak ukur.
Dalam analisis Function Point berdasarkan International Function
Point User Group (IFPUG)
terdiri dari langkah-langkah sebagai berikut:
Langkah pertama dalam meghitung sebuah ukuran dimulai dengan
menghitung UFP (Unadjusted Function Points). UFP (Unadjusted
Function Points) adalah akumulasi keseluruhan dari Complexity Ratings.
Component
Simple
Average
Complex
Inputs (I)
3
4
6
Outputs (O)
4
5
7
Data Files (F)
7
10
15
Interfaces (N)
5
7
10
Inquiries (Q)
3
4
6
|
 25
Untuk masing-masing komponen diatas diperoleh dari jumlah field
yang diinput pengguna (external input),
jumlah output yang dihasilkan
sistem untuk pengguna yang dapat berupa print out(external output),
jumlah query
yang menyediakan informasi ke user melalui pengambilan
data yang ditampilkan ke layar (external queries), jumlah logic penyimpan
data yang dapat berupa file atau database (internal logical files),
dan
jumlah informasi kontrol yang dirujuk oleh aplikasi, tapi dipelihara oleh
aplikasi lain. Kemudian dikategorikan berdasarkan 3 (tiga) tingkatan
kompleksitas (simple, average, complex) yangakan dikalikan dengan nilai
masing-masing dari tingkatan kompleksitas.(3)
UFP Data
Simple
Average
Complex
Total
EI (External Input)
__ x 3 = __
__ x 4 = __
__ x 6 = __
EO (External Output)
__ x 4 = __
__ x 5 = __
__ x 7 = __
ILF(Internal Logic Files)
__ x 7 = __
__ x 10 = __
__ x 15 = __
EIF (External Interface Files)
__ x 5 = __
__ x 7 = __
__ x 10 = __
EQ (External Queries)
__ x 3 = __
__ x 4 = __
__ x 6 = __
Proses pertama yang dilakukan untuk akumulasi data UFP adalah
dengan memasukkan nilai dari masing-masing kelima data UFP di atas.
Setelah masing-masing nilai dari External Input, External Output, Internal
Logic Files, External Interface Files,
dan External
Queries
dimasukkan
barulah akumulasi UFP di dapatkan.
|
     26
Langkah kedua dalam menghitung sebuah ukuran adalah dengan
menghitung akumulasi VAF (Value Adjusment Factor).
VAF (Value
Adjusment Factor) dihitung berdasarkan pada keseluruhan kompleksitas
sistem. Cara menghitung VAF (Value Adjusment Factor) dengan
menggunakan 14 (empat belas) GSC (General System Characteristics),
dimana nila masing-masing dari GSC berskala 0 (nol) sampai 5 (lima).
Skala 0 (nol) menunjukkan tidak adanya pengaruh dan skala 5 (lima)
menunjukkan adanya pengaruh yang luas terhadap keseluruhan proyek.
General System Characteristic
Brief Description
1. Data Communication
Berapa banyak fasilitas komunikasi
yang ada untuk membantu
pertukaran informasi dengan
penerapan system aplikasi?
2. Distributed Data / Processing
Bagaimana data di distribusikan
dan pengolahan fungsi ditangani?
3. Performance Objectives
Seberapa lama waktu yang
diperlukan dan performa secara
keseluruhan
4. Heavily Used Configuration
Bagaimana platform perangkat
keras yang digunakan saat ini
dimana aplikasi akan dieksekusi?
5. Transaction Rate
Tingkat transaksi yang tinggi?
6. Online Data Entry
Berapa persentase dari informasi
yang dimasukkan secara online?
7. End-User Efficiency
Apakah aplikasi yang dirancang
untuk pengguna efisien?
8. Online Update
Berapa banyak data di ubah secara
online?
9. Complex Processing
Apakah proses internal yang
|
    27
dilakukan kompleks?
10. Reusability
Apakah aplikasi didesain dan
dikembangkan untuk memudahkan
pengguna?
11.Conversion / Installation
Ease
Apakah konversi dan instalasi
dilakukan secara otomatis?
12. Operational Ease
Apakah operasi seperti backup,
startup,
dan
recovery
dilakukan
secara otomatis?
13. Multiple Site Use
Apakah spesifikasi aplikasi
didesain, dikembangkan dan
didukung untuk berb agai situs
dengan berbagai organisasi?
14. Facilitate Change
Apakah spesifikasi aplikasi
didesain, dikembangkan dan
didukung untuk memfasilitasi
perubahan dan kemudahan
penggunaan oleh user?
Akumulasi VAF ditentukan dari jumlah total seluruh skala GSC
(General Characteristics System) yang telah ditentukan oleh pengguna.
Langkah ketiga yang dilakukan untuk perhitungan ukuran adalah
dengan menghitung AFP (Adjusted Function Point). AFP (Adjusted
Function Point) adalah perhitungan dari perkalian VAF (Value Adjusment
Factor) dari UFP (Unadjusted function Point).
AFP = UFP * (0.65 + 0.01 * VAF)
Langkah keempat yang dilakukan untuk perhitungan ukuran
adalah dengan menentukan bahasa pemrograman yang digunakan pada
perangkat lunak. Dibawah ini adalah tabel untuk bahasa pemrograman
|
 28
yang ada
berdasarkan pada QSM (Quantitative Software Management):
(QSM Function Point Language Table, 2012)
Language
Avg
QSM SLOC/FP
Median
Low
High
ABAP (SAP)
18
18
16
20
Access *
36
38
15
47
Ada
154
-
104
205
Advantage
38
38
38
38
APS
86
83
20
184
ASP *
56
50
32
106
Assembler*
209
203
91
320
C*
148
107
22
704
C++*
59
53
20
178
C#*
58
59
51
66
Clipper*
40
39
26
53
COBOL*
80
78
8
400
ColdFusion
68
56
52
105
Cool:Gen/IEF*
38
35
10
180
Culprit
51
-
-
-
Datastage
67
79
16
85
Dbase III
-
-
-
-
Dbase IV
52
-
-
-
|
 29
Easytrieve+
33
34
25
41
Excel
47
46
31
63
Focus*
45
45
40
49
FORTRAN
90
118
35
-
FoxPro*
36
35
34
38
HTML
43
42
35
53
Ideal
66
52
34
203
Informix*
42
31
24
57
J2EE*
57
50
50
67
Java*
55
53
9
214
JavaScript*
54
55
45
63
JCL*
96
59
58
173
JSP
59
-
-
-
KML
50
50
49
50
Lotus Notes*
23
21
15
46
Maestro
30
30
30
30
Mantis
71
27
22
250
Mapper*
69
70
58
81
Natural*
51
53
34
60
.NET
60
60
60
60
Netron/CAP
296
323
105
399
Openroad
39
34
20
69
Oracle*
42
29
12
217
Oracle Dev 2K*
35
30
23
100
Pacbase*
42
43
26
52
PeopleSoft*
37
32
34
40
Perl
57
57
45
60
|
 30
PL/1*
58
57
27
92
PL/SQL*
47
39
16
78
Powerbuilder**
28
22
8
105
Powerhouse
63
25
79
REXX
50
-
-
-
RPG II/III
61
49
24
155
Sabretalk*
70
61
54
94
SAS*
50
35
32
102
Siebel Tools
13
13
5
20
Slogan*
81
80
66
100
Smalltalk**
28
19
17
55
SQL*
31
30
13
80
SQL Forms
11
11
10
15
Taskmate
45
47
37
51
Uniface
61
50
31
120
VB.Net
28
-
-
-
VBScript*
38
37
29
50
Visual Basic*
50
52
14
276
VPF
95
95
92
98
Web Scripts
44
15
9
114
Nilai bahasa pemrograman yang digunakan untuk perhitungan
SLOC di dapat dari nilai rata-rata yang berasal dari tabel QSM SLOC/FP
dengan formula sebagai berikut:
|
|
31
Physical Size = Language * AFP
2.
Measuring Effort (Pengukuran Usaha)
Usaha didefinisikan sebagai jumlah dari staff
per-hari, per-
minggu, per-bulan, bahkan per-tahun yang terkait dengan proyek.
Perhitungan usaha didapatkan dari perkalian staff
dan schedule, dimana
schedule
merupakan hasil dari perhitungan menggunakan nilai Function
Point yang telah diperoleh.
Untuk mengukur effort
diperlukan variabel yang terdiri dari
schedule dan staff. Menurut Jones, schedule dipengaruhi oleh nilai indeks
dari skala 0.32 sampai 0.4. Dimana untuk indeks 0.32 digunakan pada
proyek berskala kecil atau menengah, dan untuk indeks 0.4 digunakan pada
proyek berskala besar dengan nilai function point rata-rata lebih besar dari
1000FP. (Capers, 1998)
Schedule = FP
0.32-0.4
Staff = FP / 150
Effort = Staff * Schedule
3.
Measuring Complexity (Pengukuran Kompleksitas)
Terdapat banyak struktur metrik kompleksitas yang sudah
ditetapkan, dicoba, dan dikembangkan. Berikut ini merupakan beberapa
metrik yang dijelaskan dalam mengestimasi kompleksitas suatu perangkat
lunak:
|
|
32
a.
Ukuran sebagai dasar pengukuran kompleksitas
Perhitungan Line Of Code
(LOC) atau Function Point
yang
menjadi dasar perhitungan ukuran juga merupakan faktor utama dalam
memprediksi kecacatan. Perhitungan kecacatan dibutuhkan untuk
mengetahui kompleksitas suatu sistem. Dalam konteks ini terdapat 2 (dua)
jenis kesalahan, yaitu module-related faults dan instruction-related faults.
(Malayia & Denton, 2000) Untuk module-related faults, terdapat kesalahan
yang disebabkan dari kode modular yang diintegrasikan ke modul lain.
Karena itu, untuk modul yang terkait, jika sebuah modul dari ukuran
dilambangkan dengan ‘s’, kecacatan di lambangkan dengan D
m
(dalam
defects / LOC)
D
m
(s) = a/s
Dimana ‘s’ harus lebih besar dari pada 0 (nol) dan ‘a’ adalah nilai
konstan. Dalam kasus ini, faktor menurun sedangkan ukuran modul
meningkat.
Untuk instruction-related faults
adalah jumlah baris kode yang
ditulis dengan 2 (dua) komponen. Komponen pertama, dilambangkan
dengan ‘b’ adalah peluang bahwa setiap baris kode
memiliki bug
didalamnya. Komponen kedua adalah peluang bahwa setiap modul
memiliki kesalahan dalam berinteraksi dengan baris kode yang lain dalam
modul tersebut. Oleh karena itu, untuk instruction-related faults
menggunakan perhitungan sebagai berikut:
|
 33
Di(s) = b + c * s
Dimana, ‘c’
adalah nilai yang berasal dari faktor interaksi secara
empiris. Dan oleh karena itu total dari defect density adalah
D(s) = a/s + b + c * s
Untuk ukuran modul optimal yang dilambangkan dengan ‘Smin’,
dan perhitungan minimal defect density menjadi:
Smin =
¥
‘Smin’
ditentukan oleh kemampuan dan keahlian programmer,
perhitungannya berkisar antara 200 hingga 400 LOC (Line Of Code)
tergantung dari bahasa yang digunakan.
4.
Cyclomatic Complexity
Cyclomatic complexity mengukur jumlah aliran kontrol dalam suatu
modul. Teori yang mendasari adalah semakin banyak jumlah path yang
melalui modul, semakin tinggi kompleksitasnya. Perhitungan jumlah
cyclomatic complexity
berdasarkan grafik, yang dilambangkan dengan
‘V(g)’, dengan menghitung jumlah path didalam program.
Modul didefinisikan sebagai satu set kode yang dieksekusi dengan
memiliki satu masukan dan satu keluaran. Cyclomatic
dapat dihitung
dengan dua cara yang memberikan hasil yang sama, baik dengan
menghitung jumlah node dan edge atau dengan menghitung jumlah binary
decision
dalam hal ini percabangan, formula perhitungannya sebagai
berikut:
|
 34
V(g) = e – n + 2.....(1)
V(g )= bd + 1.....(2)
Pada persamaan pertama dimana ‘g’ adalah grafik kontrol modul,
‘e’
adalah jumlah edge,
dan ‘n’
adalah jumlah node. Persamaan kedua
dimana ‘bd’ adalah jumlah dari binary decision dalam grafik kontrol. Jika
terdapat lebih dari satu percabangan di setiap node-nya, maka
perhitungannya menjadi: jumlah cabang-1.
Menurut Aivosto (Salste,2012) suatu cyclomatic complexity yang
tinggi menunjukkan prosedur yang kompleks, sulit untuk dipahami, diuji
dan dipelihara. Ada hubungan antara cyclomatic complexity
dan resiko
dalam prosedur. Hubungannya ditunjukkan dengan tabel dibawah ini:
Nilai CC
Tipe Prosedur
Tingkat Resiko
1-4
Prosedur sederhana
Rendah
5-10
Prosedur yang terstruktur dengan
baik dan stabil
Rendah
11-20
Prosedur yang lebih kompleks
Menengah
21-50
Prosedur yang kompleks dan
kristis
Tinggi
>50
Rentan kesalahan, sangat
mengganggu, prosedur tidak
dapat diuji.
Sangat tinggi
Aivosto menetapkan pada mulanya standar nilai maksimum untuk
cyclomatic complexity adalah 10. Namun stndar nilai lain seperti 15 atau 20
juga sudah disarankan. (Salste, 2012) Terlepas dari standar tersebut, jika
nilai cyclomatic
melebihi angka 20 maka harus dipertimbangkan bahwa
|
 35
hasil tersebut mengkhawatirkan untuk resiko terjadinya kecacatan. Salah
satu pandangan menurut Aivosto (Salste,2012) mengenai probabilitas
dalam memperbaiki kesalahan berdasarkan nilai cyclomatic complexity
diantaranya:
Nilai CC
Probabilitas
Perbaikan
1-10
5%
20-30
20%
>50
40%
Mendekati 100
60%
Menurut Laird dan Brennan cyclomatic complexity berguna untuk:
(Laird & Brennan, 2006)
Mengidentifikasikan bagian-bagian yang terlalu kompleks dari kode yang
membutuhkan rancnagan pemeriksaan secara rinci.
Mengidentifikasikan bagian-bagian tidak kompleks yang membutuhkan
inspeksi.
Mengestimasi usaha pemeliharaan, mengidentifikasi kode yang
bermasalah, dan mengestimasi pengujian usaha.
|
|
36
5.
Halstead’s Metric
Halstead Metik merupakan perhitungan yang didapat dari jumlah
“operator” dan “operan” yang terdapat dalam baris kode. Menghitung
jumlah “operator”
dan “operan”
yang terdapat dalam baris kode. Pada
tahun 1977, Halstead memperkenalkan metrik kompleksitas berdasarkan
jumlah dari operator dan operan dalam sebuah program. Operan ditandai
dengan nilai, seperti variabel dan konstanta. Operator ditandai dengan
koma, tanda kurung, operator aritmatika. Metrik Halstead didefinisikan
sebagai:
Length
: N = N1+N2
Vocabulary
: n = n1+n2
Volume
: V = N(log
2
(n))
Difficulty
: D = (n1/2) * (N2
/n2
)
Effort
: E = D * V
Dimana:
n
1
= jumlah operator yang berbeda dalam program
n
2
= jumlah operan yang berbeda dalam program
N1 = total jumlah kemunculan operator dalam program
N2 = total jumlah kemunculan operan dalam program
|
 37
6.
Information Flow Metric
Metrik Information Flow
mengukur aliran informasi yang masuk
dan keluar dari modul. Teori yang mendasari adalah bahwa jumlah aliran
informasi yang tinggi menunjukkan kurangnya atau bahkan tidak adanya
kohesi dalam perancangan, yang menyebabkan kompleksitas yang lebih
tinggi. Metrik Henry-Kafuramendefinisikan Information Flow Complexity
(IFC) dari sebuah modul dengan persamaan:
IFC = (fanin * fanout)²
Bobot IFC = panjang * (fanin*fanout)²
Dimana:
Fanin: Jumlah aliran lokal ke dalam modul ditambah jumlah struktur data
yang digunakan sebagai masukan.
Fanout: Jumlah aliran lokal ke luar dari modul ditambah jumlah struktur
data yang digunakan sebagai keluaran.
Length: Jumlah pernyataan dalam source di prosedur (termasuk komentar).
7.
System Complexity
Perhitungan kompleksitas seluruh sistem dalam hal pemeliharaan
dan/atau desain secara keseluruhan.
Maintainability Index
Pada tahun 1990, metrik yang disebut “Maintainability Index” merupakan
metrik gabungan antara LOC (Line Of Code), metrik Halstead, Cyclomatic
|
 38
Complexity
dan number of comment. Berikut ini adalah tabel kategori
pemeliharaan dengan skor masing-masing menurut Coleman dan timnya:
(Coleman, Ash, Lowther, & Oman, 1994)
Kategori
Pemeliharaan
Skor MI
MI Tinggi
85
=
MI Medium
65
=
< 85
MI Rendah
< 65
Perhitungan untuk maintainability index didefinisikan sebagai berikut:
MI = 171 – 5.2ln(aV) – 0.23aV(g’) – 16.2ln(aLOC) + 50sin[(2.4*perCM)
1/2
]
Dimana:
aV = nilai volume (V) per modul dari metrik Halstead
aV(g') = Cyclomatic Complexity per modul
aLOC = Line Of Code (LOC) per modul
perCM = number of comment yang bersifat opsional
The Agresti-Card-Glass System Complecity Metric
Tujuan metrik The Agresti-Card-Glass System adalah untuk menguji
seberapa tinggi pengaruh desain dan arsitektur. Perhitungan ini
menggunakan kompleksitas intramodul dan kompleksitas intermodul.
|
 39
Card, Agresti dan Glass mendefinisikan formula sebagai berikut: (Laird &
Brennan, 2006)
Ct = St + Dt
Dimana
Ct = total kompleksitas sistem
St = total kompleksitas struktural (intermodul)
Dt = total kompleksitas data model (intramodul)
St berdasarkan pada metrik Henry-Kafura (Henry & Kafura, 1981) tanpa
komponen fanin. Artinya:
Ã
Dimana
f(i)
= fanout modul i
(penyimpanan data internal yang ditulis tidak
dihitung)
Dt
adalah rata-rata dari semua pengukuran kompleksitas internal untuk
semua modul. Artinya, untuk setiap modul i:
:
;
:
;
Dan menjadi:
Dt =
Ã
|
 40
Relative System Complexity
(RSC) adalah normalisasi dari kompleksitas
sistem berdasarkan pada jumlah modul. RSC merupakan rata-rata
kompleksitas per modul. Berikut formula perhitungannya:
RSC = St/n + Dt/n
Dimana:
‘n’ adalah jumlah modul dalam sistem
4. Measuring Response Time (Pengukuran Waktu)
Pengukuran kecepatan reaksi (Measuring Response Time) adalah
jarak waktu antara permintaan pengguna dan kecepatan respon sistem.
Gambar diatas masih belum disempurnakan. Yang menjadi masalah
adalah apakah perhitungan dilakukan pada saat pengguna pertama kali
memulai permintaan atau saat pengguna meng-klik tombol “Submit”. Di
bawah ini merupakan gambar yang sudah disempurnakan:
|
 41
Gambar diatas menetapkan 2 (dua) potensi pada kecepatan reaksi,
keduanya dimulai pada saat pengguna menekan tombol “submit”,
sedangkan yang lainnya menyelesaikan proses pada saat sistem mulai
merespon dan yang lainnya menyelesaikan pada saat sistem selesai
merespon.
Perhatikan spesifikasi untuk kecepatan reaksi :
1.
Kecepatan reaksi harus
= 8 detik.
2.
Kecepatan reaksi diukur sejak pengguna menekan tombol “sumbit” ke
sistem dan memulai reaksi harus
=
8 detik.
3.
Kecepatan reaksi diukur sejak pengguna menekan tombol “sumbit” ke
sistem dan memulai reaksi harus:
a.
Maximum
= 30 detik
b.
Rata-rata
= 6 detik
|
 42
4.
Kecepatan reaksi diukur sejak pengguna menekan tombol “sumbit” ke
sistem dan memulai reaksi harus:
a.
95 percentile= 8 detik
b.
100 percentile = 30 detik
Untuk perhitungan response time diambil dari rata-rata kecepatan
reaksi per modul antara pengguna dengan sistem.
5.
Measuring Availability (Pengukuran ketersediaan)
Availability merupakan pengukuran yang diperoleh dari
probabilitas sistem yang akan terpenuhi. Perhitungan availability di
rumuskan sebagai berikut:
Availability =
Dimana:
MTTF: Uptime (Frekuensi terjadinya gangguan)
MTTR: Downtime (Durasi terjadinya gangguan)
Uptime
Downtime
per- month
Downtime
per- year
Uptime
Downtime
per- month
Downtime per-
year
100%
99.999%
99.99%
99.9%
99.8%
99.7%
99.6%
99.5%
99.4%
0m
0.4m
4m
43m
1h 26m
2h 10m
2h 53m
3h 36m
4h 19m
0m
5m
52m
8h 46m
17h 31m
1d 2h 17m
1d 11h 2m
1d 19h 48m
2d 4h 34m
97.5%
97.4%
97.3%
97.2%
97.1%
97.0%
96.9%
96.8%
96.7%
18h 0m
18h 43m
19h 26m
20h 10m
20h 53m
21h 36m
22h 19m
23h 2m
23h 46m
9d 3h 0m
9d 11h 46m
9d 20h 31m
10d 5h 17m
10d 14h 2m
10d 22h 48m
11d 7h 34m
11d 16h 19m
12d 1h 5m
|
 43
99.3%
99.2%
99.1%
99.0%
98.9%
98.8%
98.7%
98.6%
98.5%
98.4%
98.3%
98.2%
98.1%
98.0%
97.9%
97.8%
97.7%
97.6%
5h 2m
5h 46m
6h 29m
7h 12m
7h 55m
8h 38m
9h 22m
10h 5m
10h 48m
11h 31m
12h 14m
12h 58m
13h 41m
14h 24m
15h 7m
15h 50m
16h 34m
17h 17m
2d 13h 19m
2d 22h 5m
3d 6h 50m
3d 15h 36m
4d 0h 22m
4d 9h 7m
4d 17h 53m
5d 2h 38m
5d 11h 24m
5d 20h 10m
6d 4h 55m
6d 13h 41m
6d 22h 26m
7d 7h 12m
7d 15h 58m
8d 0h 43m
8d 9h 29m
8d 18h 14m
96.6%
96.5%
96.4%
96.3%
96.2%
96.1%
96.0%
95.9%
95.8%
95.7%
95.6%
95.5%
95.4%
95.3%
95.2%
95.1%
95.0%
1d 0h 29m
1d 1h 12m
1d 1h 55m
1d 2h 38m
1d 3h 22m
1d 4h 5m
1d 4h 48m
1d 5h 31m
1d 6h 14m
1d 6h 58m
1d 7h 41m
1d 8h 24m
1d 9h 7m
1d 9h 50m
1d 10h 34m
1d 11h 17m 1d
12h 0m
12d 9h 50m
12d 18h 36m
13d 3h 22m
13d 12h 7m
13d 20h 53m
14d 5h 38m
14d 14h 24m
14d 23h 10m
15d 7h 55m
15d 16h 41m
16d 1h 26m
16d 10h 12m
16d 18h 58m
17d 3h 43m
17d 12h 29m
17d 21h 14m
18d 6h 0m
Dari tabel diatas menunjukkan korespondensi antara sistem
availability
dan downtime per-bulan dan per-tahun. Istilah “Five nines”
sama dengan 99.999 yang artinya sistem memiliki downtime selama 5.3
menit per-tahun. Biaya ketersediaan meningkat secara eksponensial dengan
setiap penambahan angka ‘9’.
|
 44
6.
Measuring Benefit (Pengukuran Keuntungan)
Sisi lain dari kasus bisnis adalah melihat manfaat yang diharapkan
dari proyek yang sudah dirancang. Untuk penjualan perangkat lunak
eksternal, diambil dari hasil penjualan yang diperkirakan.
Perkembangannya dapat dilihat dari tahun ke tahun, sebagai contoh:
Sales Region
Year 1
Year 2
Year 3
North
2 sales @$50,000
each=$100,000
6 sales = $300,000
10 sales = $500,000
South
2 sales = $100,000
4 sales = $200,000
7 sales = $350,000
Total
$200,000
$500,000
$850,000
Untuk perangkat lunak yang dikembangkan untuk penggunaan
internal, diperoleh dari penghematan biaya. Beberapa penghematan yang
diharapkan adalah:
-
Mengurangi biaya tenaga kerja
-
Mengurangi biaya kesalahan
-
Mengurangi biaya pemakaian
Sebagai contoh, perhitungan dilakukan dengan penghematan 2 jam
per-hari. Maka dapat dilakukan perhitungan penghematan proyek dengan
mengambil nilai rata-rata setiap jam untuk teknisi yang akan menggunakan
perangkat lunak tersebut dan mengalikannya dengan jumlah dari staff
hours
yang disimpan. Tabel dibawah adalah contoh dari perhitungan
|
 45
projected saving, perhitungan dilakukan pada satu departemen di tahun
pertama, dan beberapa departemen di tahun kedua. Diasumsikan terdapat
240 hari produktif per tahun:
Target Staff
(Average
Rate=$20/h)
Year 1
Year 2
Department A-30
30 staff x 2h x 240days
x $20/h=$288,000
$288,000
All other
department-120
0
120 x 2 240 x $20 =
$1,152,000
Total
$288,000
$1,440,000
7.
Measuring Return On Investment (Pengukuran Laba atas investasi)
Return On Investment adalah salah satu dari beberapa langkah yang
dapat digunakan dalam kasus bisnis untuk membandingkan peluang
investasi yang berbeda. Perhitungan ROI :
ROI = Net Benefits / Investment
Net Benefits = Benefits – Costs
Periode pengembalian modal untuk setiap proyek adalah lamanya
waktu yang diperlukan untuk memulihkan investasi, yaitu untuk menekan
titik impas. Yang menjadi target adalah titik impas atau Breakeven Point
dimana net benefit sama dengan net costs. Gambar dibawah menunjukkan
secara grafis bagaimana titik impas dan periode pengembalian modal dapat
terlihat.
|
 46
(Laird & Brennan, 2006)
8.
Measuring Risk
(Pengukuran Resiko yang Berkaitan dengan
Ancaman)
Manajemen risiko mencakup identifikasi, penilaian, perencanaan, dan
pemantau pemicu risiko dan rencana mitigasi yang terkait dengan proyek
perangkat lunak.
1.
Identifikasi
Ada beberapa jenis risiko yang dapat dikaitkan dengan proyek-proyek
pengembangan perangkat lunak. Diantaranya bisnis, kontrak, biaya,
penjadwalan, teknis, dan risiko kepuasan pelanggan. Risiko jika tidak
diatasi, dapat memperngaruhi keberhasilan proyek. Barry Boehm
memaparkan 10 (sepuluh) jenis risiko teratas terhadap proyek perangkat
lunak, diantaranya: (Laird & Brennan, 2006)
|
 47
1. Personel Shortfalls
2. Unrealistics schedules and budgets
3. Developing the wrong software function
4. Developing the wrong user interface
5. Gold-plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished tasks
8. Shortfalls in externally furnished components
9. Real-time performance shortfalls
10. Straining computer science capabilities
2.
Penilaian
Setiap risiko yang diidentifikasi harus dikaji untuk memahami
kemungkinan yang akan terjadi, dan apa tindakan ynag mungkin untuk
mengurangi kemungkinan terjadinya atau dampak luasnya. Untuk setiap
risiko yang diidentifikasi, biaya yang terkait dengan risiko dan terjadinya
probabilitas harus diperkirakan sehingga tim proyek dapat membuat pilihan
tentang apa dan bagaima cara untuk menerima, menghindari, atau
mengurangi masing-masing risiko.
3.
Risiko Perencanaan
Pada tahap ini tim memiliki pandangan yang jelas tentang potensi risiko
dan menetapkan strategi untuk menghadapi risiko. Biaya yang berkaitan
|
     48
dengan aksi perencanaan dapat dirangkum dan dimasukkan ke dalam total
biaya proyek.
Ada sejumlah cara untuk rencana resiko yang dapat diukur. Cara
pertama dengan melihat resiko kualitatif dalam bentuk probabilitas,
dampak, dan kemampuan untuk mengurangi dan menetapkan kategori
resiko (rendah, sedang atau tinggi). Setelah biaya langsung ditetapkan,
faktor resiko akan diterapkan dan ditambahkan ke total biaya proyek.
Sebagai contoh, berikut tabelnya:
Risk Item
Probability of
Occurrence
Impact
Risk
Assessment
Loss of jey
resource
20%
High
Medium
More than 25%
requirements
growth after
design starts
40%
High
High
Development
environment
unavailability>10
%
10%
Moderate
Low
New technology
delivered to
project late
10%
High
Medium
Overall
qualitative risk
Medium(=20
%risk factor)
Total risk cost
$500K*20%=
$100,000
|
|
49
Cara kedua yaitu secara khusus mengukur setiap risiko dari
segi
estimasi biaya kejadian, probabilitas, dan estimasi biaya mitigasi. Berikut
adalah contoh perhitungannya:
|
 50
Risk Item
Cost Of Occurrence
Probability
Of
Occurrence
Cost of risk
Acceptance
Mitigation
Action
Cost of
Mitigation
Probability
After
Mitigation
Total Cost
Lost of key
resource
1month delay in
overall
development=20days
x 30staff x ($640per
staff day)=$384,000
20%
$384,000 x
20%=$76,800
Train backup
in this area
10days x
2staff =
12,800
0%
$21,800
Required
hardware
delivered
late
1 week delay in
overall
development=$96,000
30%
$96,000 x
30%=$28,800
Place
delivery
penalty in
subcontract
None
5%
$4,800
Contractual
throughput
measure
not
achieved
Penalty clause in
contract
invoked=$500,000
25%
$125,000
Instrument
code for
early
measurement
and
correction
$20,000
5%
$20,000+($500,
000 x
5%)=$45,000
Total
$230,600
$32,800
$62,600
|
|
4.
Pemantauan Risiko
Risiko yang berhubungan dengan perubahan proyek dari waktu ke waktu.
Beberapa proyek mengalami perubahan dan bahkan sampai mengeluarkan
biaya di luar dugaan. Yang perlu dicatat adalah perancanaan risiko harus
ditinjau dan diperbarui secara berkala.
9.
Measuring Cost and Effort (pengukuran biaya berdasarkan usaha)
Untuk pengukuran biaya berdasarkan usaha perangkat lunak,
penelitian ini menggunakan teori dari Riyanarto Sarno dan timnya dalm
makara yang berjudul “Pengembangan Metode Analogy
Untuk Estimasi
Biaya Rancang Bangun Perangkat Lunak”. (Sarno, Buliali, & Maimunah,
2002)
Sebelum menentukan estimasi biaya, terlebih dahulu harus
mengestimasi besarnya usaha, karena usaha merupakan komponen biaya
utama yang berpengaruh pada hampir semua objek biaya. Sebelum
menentukan teknik estimasi biaya pada suatu proyek pengembangan
perangkat lunak, dilakukan tahapan berikut :
1.
Penentuan nilai 3D Function Point (FP)
Mengidentifikasi fungsi-fungsi sebagai parameter proyek yang disesuaikan
dengan permintaan pemakaian antara lain : output, input, files, inquiries,
interfaces. Setelah masing-masing dikelompokkan dan dihitung, diberi
bobot sesuai dengan tingkat kompleksitasnya. Nilai total seluruh fungsi
disebut nilai Unadjasted Function Points
(UFP). Kemudian
|
 mengidentifikasi karakteristik aplikasi. Nilai FP dihitung dengan
megkalikan nilai UFP dan nilai faktor teknis kompleksitas (Adjusted
Factor / AF). Selanjutnya nilai FP yang telah diketahui dapat dikonversi ke
jumlah Source Line of Code
(SLOC) yang ekivalen. Konversi dapat
dilakukan dengan menggunakan table ekivalensi bahasa pemrograman.
Bahasa
SLOC per FP
C++ default
53
Cobol default
107
Delphi 5
17
HTML
14
Visual Basic 6
24
SQL default
13
Java 2 default
46
2.
Kalkulasi penggunaan kembali perangkat lunak yang ada dan komponen-
komponen serta komersial pustaka. Dalam menentukan similaritas
digunakan metode Nearest Neighbour Algorithm. Metode ini merupakan
algoritma umum yang didasarkan pada pengukuran jarak tiap-tiap
parameter.
3.
Estimasi usaha atau effort (E) dengan menggunakan metode analogi yang
telah dimodifikasi. Mengestimasi effort proyek baru dapat dilakukan
|
|
dengan mencari proyek serupa sebagai acuan, untuk itu dapat digunakan
persamaan
Y = ax1 + bx2 + cx3
Dimana:
Y adalah nilai estimasi effort
dan x
1,
x
2,
x3
, ...., x
n
adalah parameter-
parameter proyek, misalnya: input, output, inquiry, file.
4.
Penentuan waktu yang diperlukan (t
d
)
Setelah nilai usaha didapatkan, waktu yang diperlukan dapat dihitung
dengan persamaan :
t
d
= SM * (E)
0.33
Dimana :
t
d
: Waktu yang diperlukan (months)
E : Effort atau Usaha
SM : Schedule Multiple yang dapat dilihat nilainya pada tabel dibawah ini.
|
 Project Type
Schedule Multiple
COCOMO II default
3.67
Embedded
Development
4.00
E-Commerce
Development
3.19
Web Development
3.10
Military Development
3.80
5.
Penentuan biaya proyek
Biaya proyek dapat dihitung dengan persamaan :
Biaya produksi = B
FS
+ B
FD
+ B
MB
+ B
T
+B
M
+B
D
Estimasi biaya = biaya produksi * (1 + pajak)
Dimana
B
FS
: biaya studi kelayakan
B
FD
: biaya desain fungsi
B
MB
: biaya pemrograman
B
T
: biaya training
B
M
: biaya pemeliharaan
B
D
: biaya dokumentasi
|
 Biaya studi kelayakan (B
FS
)
Beberapa komponen yang mempengaruhi biaya aktifitas studi kelayakan
antara lain:
Waktu untuk studi kelayakan (t
Feas
)
t
Feas
= t
d
/ 4
Usaha atau effort untuk studi kelayakan (E
Feas
)
E
Feas
= MP
Feas
* t
d
/ 4
MP
Feas
: jumlah orang untuk studi kelayakan
Biaya tenaga kerja untuk studi kelayakan (C
FS
)
C
FS
= E
Feas
* UR
UR : Upah Regional
Biaya listrik untuk studi kelayakan (C
LFs
) dapat diperoleh dengan
persamaan:
C
LFs
= E
Feas
* L
Rp
Dimana
L
Komp
: ongkos listrik per unit komputer lengkap
L
Rp
: ongkos listrik per unit komputer per bulan
Biaya konsumsi untuk studi kelayakan (C
KFs
)
|
 C
KFs
= E
Feas
* K
Rp
Dimana
K
Rp
: biaya konsumsi per orang per bulan
Biaya overhead untuk studi kelayakan (BO
Fs
)
BO
Fs
= C
Gfs
+ C
Dfs
+ C
Tfs
+ C
Afs
C
Gfs
= E
Feas
* G
Rp
C
Dfs
= E
Feas
* D
Rp
C
Tfs
= E
Feas
* T
Rp
C
Afs
= E
Feas
* A
Rp
Dimana
C
Gfs
: biaya gedung dan listrik
C
Dfs
: biaya depresiasi mesin
C
Tfs
: biaya telpon
C
Afs
: biaya asuransi
G
Rp
: biaya sewa gedung dan ongkos listrik per orang per bulan
D
Rp
: biaya depresiasi mesin per bulan
T
Rp
: biaya telpon per orang per bulan
A
Rp
: biaya asuransi per orang per bulan
Jadi, biaya total studi kelayakan adalah:
|
 B
FS
= C
FS
+ C
LFs
+ C
KFs
+ BO
Fs
Biaya desain fungsi (B
FD
)
Beberapa komponen yang mempengaruhi biaya aktifitas desain fungsi
antara lain:
Waktu yang diperlukan untuk desain fungsi (t
FD
)
t
FD
= t
d
/ 3
Effort yang diperlukan untuk desain fungsi (E
FD
) sebanding dengan
estimasi effort: sesuai dengan SLOC.
Jumlah orang yang diperlukan untuk desain fungsi (MP
FD
)
MP
FD
=E
FD
/ t
FD
Biaya tenaga kerja untuk desain fungsi (C
FD
)
C
FD
= E
FD
* UR
Biaya listrik untuk desain fungsi (C
LFD
)
Biaya konsumsi untuk desain fungsi (C
KFD
)
Biaya overhead untuk desain fungsi (BO
FD
)
Jadi, biaya total desain fungsi adalah:
B
FD
= C
FD
+ C
LFD
+ C
KFD
+ BO
FD
|
 Biaya pemrograman & implementasi (B
MB
)
Beberapa komponen yang mempengaruhi biaya aktifitas pemrograman
antara lain:
Jumlah orang yang diperlukan untuk pemrograman (MP)
MP = E / t
d
Biaya tenaga kerja untuk pemrograman (C
MB
)
C
MB
= UR * E
Biaya listrik untuk pemrograman (C
LMB
)
Biaya konsumsi untuk pemrograman (C
KMB
)
Biaya overhead untuk pemrograman (BO
MB
)
Jadi, biaya total pemrograman adalah:
B
MB
= C
MB
+ C
LMB
+ C
KMB
+BO
MB
Biaya training (B
T
)
Beberapa komponen yang mempengaruhi biaya aktifitas training antara
lain:
Effort yang diperlukan untuk training (E
T
) diasumsikan sama dengan
effort untuk pemrograman: E
T
=E
Waktu yang diperlukan untuk training (t
T
)
Jumlah orang yang diperlukan untuk training (MP
T
): MP
T
= E
T
/ t
T
|
 Biaya tenaga kerja untuk training (C
T
) dapat diperoleh dengan
menggunakan persamaan C
MB
dengan penyesuaian nilai E
T
dan t
T
Biaya listrik untuk training (C
LT
)
Biaya konsumsi untuk training (C
KT
)
Biaya overhead untuk training (BO
T
)
Jadi, biaya total training adalah:
B
T
= C
T
+ C
LT
+ C
KT
+ BO
T
Biaya pemeliharaan (B
M
)
Beberapa komponen yang mempengaruhi biaya aktifitas pemeliharaan
antara lain:
Effort yang diperlukan untuk pemeliharaan (E
M
) diasumsikan sama
dengan 15% dari effort untuk pemrograman sebab effort untuk
pemeliharaan mempunyai range antara 12 sampai 17 persen dari effort
pengembangan.
E
M
= 0.15 * E
Waktu yang diperlukan untuk pemeliharaan (t
M
)
t
M
= t
d
Jumlah orang yang diperlukan untuk pemeliharaan (MP
M
)
MP
M
= E
M
/ t
M
Biaya tenaga kerja untuk pemeliharaan (C
M
) dapat diperoleh dengan
persamaan B
MB
dengan penyesuaian nilai E
M
dan t
M
.
|
 Biaya listrik untuk pemeliharaan (C
LM
)
Biaya konsumsi untuk pemeliharaan (C
KM
)
Biaya overhead untuk pemeliharaan (BO
M
)
Jadi, biaya total pemeliharaan adalah:
B
M
= C
M
+ C
LM
+ C
KM
+ BO
M
Biaya dokumentasi (B
D
)
Jumlah halaman dokumentasi dari suatu proyek dapat diprediksi dengan
menggunakan effort pengembangan sebagai input. Persamaan yang
digunakan untuk mendapatkan jumlah halaman dokumentasi (Pages)
tersebut adalah:
Pages =
Ã
Dimana:
A, B, C : konstanta penentuan jumlah halaman
i : macam dikumen yang harus dibuat
Doc
Rp
: biaya pembuatan dokumentasi per halaman
Jadi, biaya dokumentasi proyek adalah:
B
D = Doc
Rp * Pages
|
 2.5Unified Modeling Language (UML)
Unified Modeling Language
(UML) yang digunakan dalam penelitian ini
diambil dari teori Scott W.Ambler,diantaranya:(Ambler, 2005)
1.
Use Case Diagram
Use case diagrammenunjukkan hubungan antara aktor dengan use case
pada sebuah sistem.Dibawah ini merupakan contoh dari use case diagram:
Use case menekankan pada aktifitas apa yang bisa dilakukan oleh aktor.
Diluar use case
terdapat aktor yang digambarkan dengan istilah “stick man”.
Selain aktor, terdapat sebuah communication line dan system boundaries
untuk
menggambarkan use case diagram
secara utuh. Communication line
menghubungkan aktor dan use case
untuk menunjukkan bahwa aktor tersebut
berpartisipasi di dalam use case. System boundaries
digunakan untuk
menandakan pemisahan antara eksternal sistem (aktor) dan internal sistem (use
case), seperti pada contoh dibawah ini:
|
 Boundaries(Ambler, 2005)
2.
Activity Diagram
Activity diagram merupakan diagram yang menunjukkan aliran proses
yang dilakukan oleh sistem. Inisial “start” pada activity diagram digambarkan
dengan lingkarang berwarna hitam yang artinya proses akan memulai eksekusi
dan inisial “stop”
digambarkan dengan titik hitam yang
dikelilingi lingkaran
hitam yang artinya proses telah selesai dieksekusi. Berikut ini adalah contoh
activity diagram:
|
 |
 3.
Conceptual Class Diagram
Conceptual class diagram
merupakan dasar dari perancangan sequence
diagram dan class diagram. Conceptual class diagram
menentukan kelas-kelas
apa saja yang dibutuhkan dan hubungan antar kelas.
4.
Sequence Diagram
Sequence diagram merupakan gambaran komunikasi yang dinamis antar
bagian-bagian dari sistem. Dengan menggunakan sequence diagram,
pengembang bisa menjelaskan urutan interaksi apa yang akan dipanggil ketika
sebuah use case dieksekusi. Berikut adalah contoh sequence diagram:
|
 |
 5.
Attribute Conceptual Class
Attribute conceptual class adalah proses menetapkan attribute yang
dimiliki oleh kelas tersebut. Berikut adalah contoh attribute conceptual class:
6.
Class Diagram
Class diagram merupakan diagram yang menggambarkan hubungan antar
kelas yang berisi attribute dan operation pada masing-masing kelas. Class dalam
UML digambarkan sebagai persegi panjang dibagi menjadi tiga bagian. Bagian
paling atas berisi nama class, bagian tengah berisi attribute yang dimiliki oleh
kelas tersebut, dan bagian akhir berisi operation
yang menunjukkan behaviour
dari kelas. Berikut adalah contoh dari class diagram:
|
|
Untuk merancang antar muka yang baik digunakan pedoman delapan aturan
emas menurut Shneiderman diantaranya:(Shneiderman, 2005)
1.
Konsisten
Konsisten dilakukan pada urutan tindakan, perintah dan istilah yang
digunakan pada prompt, menu, serta layar bantuan.
2.
Memungkinkan pengguna untuk menggunakan shortcut
Ada kebutuhan dari pengguna yang sudah ahli untuk meningkatkan
kecepatan interaksi, sehingga diperlukan singkatan, tombol fungsi, perintah
tersembunyi, dan fasilitas makro.
3.
Memberikan umpan balik yang informatif
Untuk setiap tindakan operator, sebaiknya disertakan suatu sistem
umpan balik. Untuk tindakan yang sering dilakukan dan tidak terlalu penting,
dapat diberikan umpan balik yang sederhana. Tetapi ketika tindakan merupakan
hal yang penting, maka umpan balik sebaiknya lebih substansial. Misalnya
muncul suatu suara ketika menekan tombol pada waktu input data atau muncul
pesan kesalahannya.
4.
Merancang dialog untuk menghasilkan suatu penutupan
Urutan tindakan sebaiknya diorganisir dalam suatu kelompok dengan
bagian awal, tengah, dan akhir. Umpan balik yang informatif akan memberikan
indikasi bahwa cara yang dilakukan sudah benar dan dapat mempersiapkan
kelompok tindakan berikutnya.
|
|
5.
Memeberikan penanganan kesalahan
Sedapat mungkin sistem dirancang sehingga pengguna tidak dapat
melakukan kesalahan fatal. Jika kesalahan terjadi, sistem dapat mendeteksi
kesalahan dengan cepat dan memberikan mekanisme yang sederhana dan
mudah dipahami untuk penanganan kesalahan.
6.
Mudah kembali ke tindakan sebelumnya
Hal ini dapat mengurangi kekhawatiran pengguna karena pengguna
mengetahui kesalahan yang dilakukan dapat dibatalkan, sehingga pengguna
tidak takut untuk mengeksplorasi pilihan-pilihan lain yang belum biasa
digunakan.
7.
Mendukung tempat pengendali internal
Pengguna ingin menjadi pengotrol sistem dan sistem akan merespon
tindakan yang dilakukan pengguna daripadapengguna merasa bahwa sistem
mengotrol pengguna. Sebaiknya sistem dirancang sedemikian rupa sehingga
pengguna menjadi inisiator daripada responden.
8.
Mengurangi beban ingatan jangka pendek
Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana
atau banyak tampilan halaman yang sebaiknya disatukan, serta diberikan cukup
waktu pelatihan untuk kode dan urutan tindakan.
|
|
|