BAB 4
IMPLEMENTASI DAN EVALUASI
4.1 Spesifikasi Sistem
Aplikasi yang dirancang berdasarkan dari analisa dan perancangan pada bab sebelumnya diharapkan mampu menyelesaikan permasalahan yang ada dalam mengestimasi biaya pembuatan piranti lunak dan bisa menjadi solusi yang baik. Aplikasi berbasis web ini membutuhkan spesifikasi perangkat keras dan perangkat lunak untuk pengoperasian sistem dengan baik. Berikut ini adalah penjelasan mengenai kebutuhan spesifikasi yang diperlukan.
4.1.1Spesifikasi Perangkat Lunak
Untuk menjalankan rancangan aplikasi pengukuran biaya pembuatan piranti lunak berbasis web ini dibutuhkan spesifikasi minimum untuk perangkat lunak yaitu sebagai berikut:
• Server:
1. XAMPP versi 2.2
2. Aplikasi basis data My SQLversi 5.1 3. Sistem Operasi Windows 2000 4. Browser Chrome versi 24 5. Browser Opera versi 12.10 6. Browser Mozilla Firefox versi 18
7. Browser Safari versi 6.0 • Client:
1. Browser Chrome versi 24 2. Browser Opera versi 12.10 3. Browser Mozilla Firefox versi 18 4. Browser Safari versi 6.0
5. Sistem Operasi Windows 2000
4.1.2 Spesifikasi Perangkat Keras
Untuk menjalankan rancangan aplikasi pengukuran biaya pembuatan piranti lunak berbasis web ini dibutuhkan spesifikasi minimum untuk perangkat keras yaitu sebagai berikut:
• Server:
1. Processor intel Pentium 4 1.6 ghz 2. 256MB DDR400 ECC
3. 40GB HDD 10K SCSI 4. Graphic card 64 mb 5. Tower Case 350W 6. Monitor
7. Sistem Operasi Windows 98 • Client:
1. Processor intel Pentium 3 2.0 ghz 2. 256MB DDR400 ECC
4. Graphic card 64 mb 5. Tower Case 350W 6. Monitor
7. Sistem Operasi Windows 98
4.2 Cara Pemakaian Aplikasi
Berikut ini adalah langkah-langkah penggunaan aplikasi:
1. Tampilan halaman Login
Gambar 4. 1: Tampilan halaman Login
Aplikasi ini dimulai dengan meng-klik browser pada dekstop layar, kemudian mengetik URL pada address-nya kemudian akan ditampilkan layar login atau register seperti pada gambar diatas. Pengguna harus melakukan login jika sudah memiliki username dan password atau register jika belum memiliki username dan password.
2. Tampilan halaman Register
Gambar 4. 2: Tampilan halaman Register
Tampilan diatas merupakan tampilan form register dimana pengguna harus melakukan register terlebih dahulu untuk mendapatkan username agar bisa menggunakan aplikasi ini dan melakukan login. Pengguna diwajibkan untuk mengisi data-data yang berhubungan dengan pengguna itu sendiri dengan benar. Kemudian memilih button submit untuk menyimpan data.
3. Tampilan halaman Forgot Password
Gambar 4. 3: Tampilan halaman Forgot Password
Tampilan diatas merupakan tampilan form forgot password dimana pengguna harus memasukkan username atau email untuk mendapatkan password baru agar bisa login. Password akan secara otomatis dikirim melalui email pengguna.
4. Tampilan halaman Home
Gambar 4.4: Tampilan halaman Home
Pada tampilan homescreen terdapat 3 (tiga) menu utama yang terdiri dari: menu create project, menu my profile dan menu my project, pengguna juga bisa memilih menu help untuk melihat petunjuk penggunaan aplikasi dan tombol logout untuk keluar dari aplikasi. Menu create project untuk membuat proyek baru yang akan diestimasi, menu my profile untuk melihat data diri pengguna termasuk username dan password yang dimiliki oleh pengguna, menu my project merupakan hasil laporan yang diperoleh dari estimasi yang telah dilakukan.
5. Tampilan halaman Create Project
Gambar 4. 5: Tampilan halaman Create Project
Tampilan diatas merupaka form create project untuk membuat proyek baru dimana pengguna harus memasukkan data-data yang berhubungan dengan proyek yang akan diestimasi diantaranya project name, ownerdan transaction date. Pengguna dapat memasukkan lebih dari satu proyek dengan nama yang berbeda. Kemudian pengguna dapat memilih project mana yang akan diestimasi terlebih dahulu. Kemudian memilih button submit untuk menyimpan data.
6. Tampilan halaman Measuring Size – Unadjustment Function Point Data
Gambar 4. 6: Tampilan halaman Measuring Size- UFP Data
Tampilan diatas merupakan form measuring size untuk estimasi UFP (Unadjustment Function Point). Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi data UFP, data-data yang harus diamasukkan pengguna diantaranya External Input, External Output, Internal Logical Files, External Interface Files, dan External Queries. Masing-masing komponen di kategori berdasakan Simple, Average dan Complex dimana masing-masing kategori tersebut memiliki nilai yang berbeda. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
7. Tampilan halaman Measuring Size – Value Adjustment Factor Data
Gambar 4. 7: Tampilan halaman Measuring Size-VAF Data
Tampilan diatas merupakan form measuring size untuk estimasi VAF (Value Adjustment Factor). Pengguna diminta untuk memberi penilaian bagi masing-masing karakteristik GSC (General Characteristic System) dengan menggunakan skala standar yang bernilai 0 (nol) sampai 5 (lima), dimana skala 0 (nol) menunjukkan tidak adanya pengaruh antara karakteristikGSC dengan
keseluruhan proyek, dan skala 5 (lima) menunjukkan adanya pengaruh yang kuat antara karakteristik GSC dengan proyek. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
8. Tampilan halaman Measuring Size – Physical Size
Gambar 4. 8: Tampilan halaman Mesuring Size-Physical Size
Tampilan diatas merupakan form measuring size untuk memilih bahasa pemrograman yang digunakan pada proyek, terdapat 65 bahasa pemrograman yang disediakan dengan nilai rata-rata SLOC (Source Line Of Code) per Function Point yang berbeda. Pemilihan bahasa pemrograman yang dipilih mempengaruhi hasil estimasi ukuran sebuah proyek. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
9. Tampilan halaman Measuring Effort
Gambar 4. 9: Tampilan halaman Measuring Effort
Tampilan diatas merupakan form measuring effort yang menampilkan hasil perhitungan schedule, staff dan effort dari suatu proyek yang diperoleh dari hasil pengukuran function point pada estimasi ukuran diatas. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
10. Tampilan halaman Measuring Complexity – Defect Density For Module
Related Fault
Gambar 4. 10: Tampilan halaman Measuring Complexity-Defect Density for Module Related Fault
Tampilan diatas merupakan form measuring complexity untuk estimasi defect density for module related fault. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi defect density, diantaranya nilai constant dan module size. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
11. Tampilan halaman Measuring Complexity – Defect Density For Instruction
Related Fault
Gambar 4. 11: Tampilan halaman Measuring Compplexity-Defect Density for Instruction Related Fault
Tampilan diatas merupakan form measuring complexity untuk estimasi defect density for instruction related fault. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi defect density, diantaranya nilai probability LOC has a bug dan interaction factor. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
12. Tampilan halaman Measuring Complexity – Cyclomatic Complexity
Gambar 4. 12: Tampilan halaman Measuring Complexity-Cyclomatic Complexity
Tampilan diatas merupakan form measuring complexity untuk estimasi cyclomatic complexity. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi cyclomatic complexity, diantaranya jumlah edges, nodes dan binary decisions.Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
13. Tampilan halaman Measuring Complexity – Halstead Metric
Gambar 4. 13: Tampilan halaman Measuring Complexity-Halstead Metric
Tampilan diatas merupakan form measuring complexity untuk estimasi halstead metric. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi halstead metric berdasarkan operator dan operand pada code dengan memasukkan total number of operators, total number of operands, number of distict operator, dan number of distict operand.Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
14. Tampilan halaman Measuring Complexity – Information Flow Complexity
Gambar 4. 14: Tampilan halaman Measuring Complexity-Information Flow
Tampilan diatas merupakan form measuring complexity untuk estimasi information flow. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi information flow metric, diantaranya nilai fanin, fanout dan length dari modul. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
15. Tampilan halaman Measuring Complexity – Maintainability Index
Gambar 4. 15: Tampilan halaman Measuring Complexity-Maintainability Index
Tampilan diatas merupakan form measuring complexity untuk estimasi maintainability index. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi maintainability index, diantaranya dengan memasukkan nilai LOC per module dan number of comment. Untuk data number of comment bersifat optional atau tidak harus dihitung. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
16. Tampilan halaman Measuring Complexity – The Agresti-Card-Glass System
Complexity Metric
Gambar 4. 16: Tampilan halaman Measuring Complexity-The Agresty Card Glass
Tampilan diatas merupakan form measuring complexity untuk estimasi the agresti-card-glass system complexity metric. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi agresti-card metric, diantaranya dengan memasukkan nilai fanout of module, internal variable dan number of module. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
17. Tampilan halaman Measuring Response Time
Gambar 4. 17: Tampilan halaman Measuring Response Time
Tampilan diatas merupakan form measuring response time. Pengguna diminta untuk memilih spesifikasi perhitungan response time, kemudian memasukkan start time dan end time. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
18. Tampilan halaman Measuring Availability
Gambar 4. 18: Tampilan halaman Measuring Availability
Tampilan diatas merupakan form measuring availability. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi availability sebuah proyek, diantaranya dengan memasukkan nilai uptime atau frequency of outages dan downtime atau duration of outages. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
19. Tampilan halaman Measuring Risk
Gambar 4. 19: Tampilan halaman Measuring Risk
Tampilan diatas merupakan form measuring risk. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi risk, diantaranya risk item, cost of occurrence, probability of occurrence, mitigation action, cost of mitigation, dan probability after mitigation.Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
20. Tampilan halaman Measuring Cost and Effort
Gambar 4. 20: Tampilan halaman Measuring Cost and Effort
Tampilan diatas merupakan form measuring cost and effort. Langkah pertama pengguna diminta untuk memilih tipe proyek, kemudian memasukkan data-data seperti total of resource for feasibility study, regional salary rate, electricity computer cost per month, consumption cost per person per month, building rent electricity cost per person per month, depreciation of machine cost per month, phone cost per month, insurance cost per person per month, dan documentation cost.Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
21. Tampilan halaman Measuring Benefit
Gambar 4. 21: Tampilan halaman Measuring Benefit
Tampilan diatas merupakan form measuring benefit. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi benefit, diantaranya the price established, number of staff, dan hour per day. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
22. Tampilan halaman Measuring Return On Investment
Gambar 4. 22: Tampilan halaman Measuring Return On Investment
Tampilan diatas merupakan form measuring return on investment. Pengguna diminta untuk memasukkan data-data yang dibutuhkan untuk mengestimasi ROI (Return On Investment), diantaranya dengan memasukkan nilai cost dan investment. Kemudian memilih button submit untuk memulai mengkalkulasi hasil.
23. Tampilan halaman My Profile
Gambar 4. 23: Tampilan halaman My Profile
Tampilan diatas merupakan form yang berisi profile atau data diri pengguna. Pengguna juga dapat merubah password untuk keamanan dalam penggunaan sistem dengan memilih button change password kemudian pilih button save.
24. Tampilan halaman My Project
Gambar 4. 24: Tampilan halaman My Project
Tampilan diatas menunjukkan hasil laporan estimasi yang telah dikalkulasi. Selain berisi laporan hasil estimasi di tampilkan juga project name, owner dan transaction date.
4.3 Evaluasi Sistem
4.3.1 Evaluasi Sistem menggunakan Skenario Testing
Aktivitas-aktivitas yang bertujuan untuk mengevaluasi atribut-atribut atau kemampuan sebuah program atau sistem dan penentuan apakah sesuai dengan hasil yang diharapkan. Untuk masing-masing inputan berdasarkan pada 2 (dua) jenis pengembangan aplikasi diantaranya, aplikasi yang dikembangkan dengan metode berorientasi procedural dengan menggunakan skenario ERD dan DFD sedangkan untuk aplikasi yang dikembangkan dengan metode berorientasi object menggunakan class diagram dan usecase diagram. Terdapat 2 (dua) teknik testing yang dapat digunakan, diantaranya white box dan
black box. Dalam skenario testing menggunakan teknik black box testing.
Black box testing juga dikenal sebagai uji spesifikasi dan fungsionalitas. Suatu unit atau program diuji tanpa adanya pengetahuan tentang struktur internal dari sourcecode-nya. Pengujian dilakukan
oleh orang lain selain programmer yang membuat program tersebut. Penguji memperlakukan kode program sebagai kotak hitam yang tidak bisa dilihat dalamnya. Kasus uji dipilih berdasarkan sifat-sifat kode yang tampak dari luar yang dispesifikasikan pada dokumentasi program. Penguji hanya tertarik dengan apa yang dilakukan oleh kode tersebut, bukan bagaimana kode tersebut bekerja. Kode diuji dengan menginput data ke dalam kotak hitam dan memeriksa apakah outputnya sesuai dengan apa yang diperkirakan.
Tabel 4.1: Evaluasi Sistem menggunakan Skenario Testing
Nama Measurement Input Proses Output yang diharapkan Output hasil yang diperoleh Pass / Fail
Measuring
Unadjusted Function Point
Nilai-nilai kompleksitas pada suatu sistem berdasarkan tingkatannya (Simple, Average,
Complex), yaitu:
External Input= 1,1,1
External Output= 1,1,1
Internal Logical Files= 1,1,1
Nilai yang di input dikategorikan sesuai tingkatannya, kemudian dikalikan dengan nilai yang sudah ditetapkan. (dijelaskan dalam Bab 3, subbab 3.1). Hasil didapatkan dari total keseluruhan masing-masing UFP data yang telah dikalkulasi sebelumnya EI: 1x3=3, 1x4=4, 1x6=6 EO: 1x4=4, 1x5=5, 1x7=7 ILF: 1x7=7, 1x10=10, 1x15=15 EIF: 1x5=5, 1x4=4, 1x10=10 EQ: 1x3=3, 1x4=4, 1x6=6 Total UFP: Pass
External Interface Files= 1,1,1 External Queries= 1,1,1 EI:3+4+6=13 EO:4+5+7=16 ILF:7+10+15=32 EIF:5+4+10=19 EQ:3+4+6=13 Total UFP: 93 Measuring Value Adjustment Factor
Berdasarkan General System
Characteristic yang terdiri atas 14
kriteria dengan memberikan penilaian berupa skala dari 0 (nol) sampai 5 (lima), diantaranya:
Data Communication =3
Distributed DataI =3
Performance Objectives = 1
Heavily Used Configuration =1Transaction Rate = 0
Online Data Entry = 0
End-User Efficiency = 3
Dari masing-masing karakteristik yang sudah dijelaskan pada Bab 3, subbab 3.1 pemberian skala berkisar antara 0 sampai 5, dimana skala 0 (nol) berarti tidak adanya pengaruh terhadap keseluruhan proyek, dan skala 5 (lima) berarti adanya pengaruh yang kuat terhadap keseluruhan proyek. Proses terakhir adalah menjumlahkan nilai skala dari masing-masing karakteristik yang sudah diberi penilaian
VAF = 3+3+1+1+0+0+3+2+0+0+2+1+0+0
= 16
Online Update =2
Complex
Reusability = 0
Installation Ease
Operational Ease = 1
Multiple Site Use= 0
Facilitate Change
Measuring Adjusted Function Point
Hasil dari perhitungan UFP Data dan VAF Data yang sudah dikalkulasi terlebih dulu
Measuring Physical Size
Menentukan bahasa pemrograman yang digunakan dalam pembuatan sebuah piranti lunak.
Language: HTML avg:43
Measuring Effort Nilai Function Point diperoleh pad
(Adjusted Function Point)
proses Online Update =2 Complex Processing =0 Reusability = 0 Installation Ease= 2 Operational Ease = 1
Multiple Site Use= 0
Facilitate Change =0
Hasil dari perhitungan UFP Data dan VAF Data yang sudah dikalkulasi terlebih dulu
Proses perhitungannya adalah:
UFP * (0.65 + 0.01 * VAF)
Menentukan bahasa pemrograman yang digunakan dalam pembuatan sebuah piranti lunak.
Language: HTML avg:43
Rumus perhitungan:
Language * AFP
Function Point yang sudah
diperoleh pada perhitungan AFP
(Adjusted Function Point) dalam
proses measuring size.
Dengan menggunakan rumus sebagai berikut:
Schedule = FP
Staff = FP/150
Proses perhitungannya adalah:
UFP * (0.65 + 0.01 * VAF)
AFP= 93*(0.65+0.01*16)
AFP=75.33
Rumus perhitungan:
Language * AFP
Physical Size: Language*AFP
43*75.33= 3239,19
Dengan menggunakan rumus sebagai
Schedule = FP 0.32-0.4
Schedule = 75.330.4
Staff = 75.33/150=0.502
Effort = 0.502*5.6343=2.828 AFP= 93*(0.65+0.01*16)
Physical Size: Language*AFP
43*75.33= 3239,19 0.4 =5.6343 Staff = 75.33/150=0.502 0.502*5.6343=2.828 Pass Pass Pass Pass Pass Pass
Measuring Defect Density for Module-Related Fault
Jumlah kesalahan yang ada berdasarkan pada jumlah modul dan jumlah baris kode
Constant: 6 Module Size: 3 Measuring Defect Density for Instruction-Related Fault
Jumlah kesalahan berdasarkan pada peluang terdapatnya bug di dalam baris kode dan peluang adanya kesalahan interaksi antar baris kode dalam modul tersebut
Probability LOC has a bug: 2
Interaction factor: 2
Measuring Cyclomatic Complexity
Perhitungan
modul membutuhkan jumlah atau banyaknya
binary decisions
modul.
Edges: 25
Effort = Staff * Schedule
Jumlah kesalahan yang ada berdasarkan pada jumlah modul dan jumlah baris kode.
Constant: 6
Module Size: 3
Proses perhitungannya:
D m(s) = a/s
‘a’ merupakan konstanta yang
diperoleh secara empiris dan adalah jumlah modul
Jumlah kesalahan berdasarkan pada peluang terdapatnya bug di
baris kode dan peluang adanya kesalahan interaksi antar baris kode dalam modul tersebut.
Probability LOC has a bug: 2
Interaction factor: 2
Perhitungan untuk memperoleh banyaknya kesalahan dalam kasus ini menggunakan rumus perhitungan:
D(s) = a/s + b + c
‘b ’ merupakan peluang terjadinya
bug di dalam baris kode, peluang kesalahan interaksi
Perhitungan control flow dalam modul membutuhkan jumlah atau banyaknya nodes dan edges atau
binary decisions pada suatu
.
Edges: 25
Dengan menggunakan perhitungan:
V(g) = e – n + 2
edges)
V(g) = bd + 1...(binary decision) Effort = Staff * Schedule
Proses perhitungannya:
merupakan konstanta yang diperoleh secara empiris dan ‘s’ adalah jumlah modul
Dm(s) = constant / module size
Dm(s) = 6 / 3= 2
Perhitungan untuk memperoleh banyaknya kesalahan dalam kasus ini menggunakan rumus perhitungan:
D(s) = a/s + b + c *s
merupakan peluang terjadinya bug di dalam baris kode, ‘c’ adalah peluang kesalahan interaksi
D(s) = constanta / module size + probability LOC has a bug + interaction factor *
module size
D(s)= 6/3+2+2*3=10
Dengan menggunakan perhitungan:
n + 2...(nodes dan
...(binary decision)
V(g)= 25-11+2=16
Dm(s) = constant / module size
D(s) = constanta / module size + probability LOC has a bug + interaction factor *
D(s)= 6/3+2+2*3=10 Pass Pass Pass Pass Pass Pass
Nodes: 11
Binary Decision: optional
Measuring Halstead Metric
Perhitungan berdasarkan pada
length, difficulty
Total jumlah kemunculan operator dalam program = 1 (N1)
Total jumlah kemunculan dalam program = 2 (N2)
Jumlah operator yang berbeda = 6 (n1)
Jumlah operan yang berbeda = 3 (n2)
Measuring
Information Flow Complexity
Menhitung jumlah aliran
informasi yang masuk dan keluar dari modul (fanin, fanout) dan jumlah pernyataan dalam source di prosedur (length)
Nodes: 11
Binary Decision: optional
Perhitungan berdasarkan pada , vocabulary, volume ,
difficulty, dan effort.
Total jumlah kemunculan operator dalam program = 1 (N1)
Total jumlah kemunculan operan dalam program = 2 (N2)
Jumlah operator yang berbeda = 6
Jumlah operan yang berbeda = 3
Rumus perhitungannya: Length: N= N1 Vocabulary: n = n Volume: V = N(Log Difficulty: D =(n Effort: E = D*V ‘N1’ total jumlah
operator dalam program, ‘
jumlah kemunculan operan dalam program, ‘n1’ jumlah operator yang
berbeda dalam program, ‘
operan yang berbeda dalam program
Menhitung jumlah aliran
informasi yang masuk dan keluar dari modul (fanin, fanout) dan jumlah pernyataan dalam source di prosedur (length)
Menggunaka rumus perhitungan sebagai berikut:
Weighted IFC = length * (fanin*fanout)2 Rumus perhitungannya: 1 + N2 Vocabulary: n = n1 + n2 Volume: V = N(Log2(n)) Difficulty: D =(n1/2)*(N2/2) Effort: E = D*V
total jumlah kemunculan operator dalam program, ‘N2’ total jumlah kemunculan operan dalam
jumlah operator yang berbeda dalam program, ‘n2’ jumlah operan yang berbeda dalam program
Length= 1+2=3 Vocabulary= 6+3=9 Volume= 3(Log2(9))= 9.48 Difficulty= (6/2)*(2/2)=3 Effort= 3*9.48=28.44 rumus perhitungan sebagai berikut:
Weighted IFC = length * 2 IFC= 6*(3*11)2 = 6534 Vocabulary= 6+3=9 (9))= 9.48 )*(2/2)=3 Effort= 3*9.48=28.44 Pass Pass Pass Pass
Fanin: 3 Fanout:11 Length:6 Measuring Maintainability Index
Perhitungan berdasarkan pada nilai volume
yang telah dikalkulasi sebelumnya pada proses
complexity
cyclomatic complexity
dikalkulasi pada proses measuring
complexity
jumlah LOC per modul, dan jumlah baris komentar(bersifat opsional)
LOC per module: 2
Number of comment: 3
Measuring Agresty Card Glass System Complexity Metric
Merupakan rata
per modul. Dibutuhkan total jumlah modul dalam sistem, total kompleksitas pada sistem, total kompleksitas intermodul, total Fanin: 3
Fanout:11
Length:6
Perhitungan berdasarkan pada
volume pada metrik Halstead
yang telah dikalkulasi sebelumnya pada proses measuring
complexity-Halstead metric, nilai cyclomatic complexity yang telah
dikalkulasi pada proses measuring
complexity-cyclomatic complexity,
jumlah LOC per modul, dan jumlah baris komentar(bersifat opsional)
LOC per module: 2
Number of comment: 3
Cara perhitung
rumus sebagai berikut:
MI = 171-5.2ln(aV)
16.2ln(aLOC)+50sin[(2.4*perCM)
aV meupakan nilai volume dari metrik Halstead, aV(g’) cyclomatic complexity per modul, aLOC adalah jumlah LOC, perCM adalah baris komentar per modul.
Merupakan rata-rata kompleksitas per modul. Dibutuhkan total jumlah modul dalam sistem, total kompleksitas pada sistem, total kompleksitas intermodul, total
Perhitungannya dengan mencari niali Ct yaitu total kompleksitas sistem:
Ct = St + Dt
‘St’ adalah fanout pada metrik
Cara perhitungannya menggunakan rumus sebagai berikut:
5.2ln(aV)-0.23aV(g’)-16.2ln(aLOC)+50sin[(2.4*perCM)1/2]
aV meupakan nilai volume dari metrik Halstead, aV(g’) cyclomatic complexity per modul, aLOC adalah jumlah LOC, perCM adalah baris komentar per modul.
MI= 171-5.2ln(9.48)
=39.146
ya dengan mencari niali Ct yaitu total kompleksitas sistem:
adalah fanout pada metrik
RSC (Relative System Complexity)= 5/2+3/2=4
5.2ln(9.48)-0.23(16)-16.2ln(2)
RSC (Relative System Complexity)=
Pass
Pass Pass
kompleksitas intramodul Fanout of module: 5 Internal variabel: 3 Number of module: 2 Measuring Response Time Perhitungan
bergantung pada saat
Request kompleksitas intramodul. Fanout of module: 5 Internal variabel: 3 Number of module: 2 Henry-Kafura ,
semua kompleksitas internal untuk semua modul.
Kemudian perhitungan RSC
(Relative System Complexity):
RSC = St/n + Dt/n
‘n’ merupakan jumlah modul dalam
sistem
Perhitungan Response Time bergantung pada saat User
Request dan System Response.
Menetapkan spesifikasi perhitungan yang sesuai dengan
inginkan, memasukkan
end time(ditentukan dari rata
modul) kemudian menghitung lamanya waktu yang dibutuhkan dengan membandingkan spesifikasi perhitungan terhadap lamanya waktu respon yang diperoleh
Kafura , ‘Dt’ rata-rata dari semua kompleksitas internal untuk
Kemudian perhitungan RSC
(Relative System Complexity):
Dt/n
merupakan jumlah modul dalam
Menetapkan spesifikasi perhitungan yang sesuai dengan pengguna
inginkan, memasukkan start time dan (ditentukan dari rata-rata per modul) kemudian menghitung lamanya waktu yang dibutuhkan dengan membandingkan spesifikasi perhitungan terhadap lamanya waktu respon yang diperoleh
Perhitungan response time
membantu dalam mengkategorikan baik buruknya kecepatan reaksi yang dialami oleh pengguna
response time diharapkan dapat
membantu dalam mengkategorikan baik buruknya kecepatan reaksi yang dialami
Pass Pass
Measuring Availability
Pengukuran berdasarkan uptime dan downtime yaitu seberapa sering sistem mengalami gangguan dan seberapa lama waktu yang dibutuhkan untuk perbaikan. Uptime: 3 Downtime: 2 Perhitungannya menggunakan rumus: Availability =MTTF/(MTTR+MTTF) MTTF : uptime, MTTR : downtime Availability=MTTF/(MTTR+MTTF) = 3/(3+2)=0.6 Pass
Measuring Risk Dibutuhkan data-data diantaranya
Cost of Occurrence,Probability of Occurrence, Cost of Risk
Acceptance, Cost of Mitigation, Probability after Mitigation, dan total cost untuk melakukan
perhitungan risiko yang berkaitan dengan ancaman.
Risk item: Loss of key resource
Cost of occurrence: 385000
Probability of occurrence: 20%
Cost of risk acceptance: 80000
Perhitungan dengan menjumlahkan masing-masing dari kriteria yang telah disebutkan bergantung pada jenis risiko yang terjadi pada sistem. Rumus perhitungan:
Total cost=cost of
mitigation*probability after mitigation
Total cost of risk acceptance= cost of occurrence*probability of occurrence
Total cost= 23000*0% = 23000
Total cost of risk acceptance = 385000*20% = 77000
Total cost of mitigation = 23000
Mitigation action: train backup in this area
Cost of mitigation: 23000
Probability after mitigation: 0%
Measuring Benefit Perhitungan dilakukan
berdasarkan atas jumlah staff, jumlah hari kerja selama satu tahun, dan jumlah jam atau hari dilakukannya penghematan
The price established: 300000
Number of staff: 30
Hour per day: 6 hour
Mitigation action: train backup in this area
Cost of mitigation: 23000
Probability after mitigation: 0%
Perhitungan dilakukan
berdasarkan atas jumlah staff, jumlah hari kerja selama satu tahun, dan jumlah jam atau hari dilakukannya penghematan.
The price established: 300000
Number of staff: 30
Hour per day: 6 hour
Minimal perhitungan selama 3 (tiga) tahun untuk mengetahui pengaruh penghematan terhadap keuntungan yang diperoleh, dengan me
jumlah staff, jam kerja dan jam dilakukannya penghematan per departemen pada tahun pertama, kemudian tahun berikutnya bergantung pada banyaknya departemen. Dengan rumus perhitungan:
The price established*number of staff* hour per day
Minimal perhitungan selama 3 (tiga) tahun untuk mengetahui pengaruh penghematan terhadap keuntungan yang diperoleh, dengan mengalikan jumlah staff, jam kerja dan jam dilakukannya penghematan per departemen pada tahun pertama, kemudian tahun berikutnya bergantung pada banyaknya
Dengan rumus
The price established*number of staff* hour per day
Measuring ROI Perhitungan ROI(Return On
Investment) berdasarkan pada Benefit dan costs.
Benefit= 50000
Cost= 100000
Investment= 100000
Langkah awal yaitu mencari Net
Benefit dengan rumus:
Net Benefit = Benefit –Cost
Selanjutnya nilai Net Benefit akan digunakan untuk rumus berikutnya, yaitu:
ROI = Net Benefit / Investment
ROI year1: (50000-100000)/100000 =-50% ROI year2: 50000+50000-100000-10000/ 100000+10000 =-9% ROI year3: (50000+50000+50000-100000-10000-10000)/100000+10000+10000= 25% Pass
Measuring Cost and Effort
Untuk menghitung biaya-biaya yang dikeluarkan dalam
pembuatan proyek dibutuhkan data-data real cost, diantaranya: biaya studi kelayakan, biaya desain fungsi, biaya pemrograman dan implementasi, biaya training, biaya pemeliharaan, dan biaya dokumentasi. Sebelum
mengkalkulasi biaya-biaya tersebut, dibutuhkan perhitungan FP (function point) dan effort yang telah didapatkan sebelumnya pada proses measuring size dan
Langkah awal mencari nilai FP dan
effort yang sudah diperoleh pada
proses measuring size dan effort diatas, kemudian hasil dari effort tersebut digunakan untuk mencari waktu yang diperlukan selama pembuatan proyek, langkah
selanjutnya mengkalkulasi data-data
real cost dengan menjumlahkan
keseluruhan hasil masing-masing biaya Td= 3.67*(2.828)=10.378 Tfeas= 1.378/4=2.594 Efeas= 50*10.378=518.9 Cfs= 518.9*200000= 103780000 Clfs= 518.9*200000= 103780000 Ckfs= 518.9*200000=103780000 Cgfs=518.9*150000=77835000 Cdfs= 518.9*120000=62268000 Ctfs= 518.9*85000=44106500 Cafs= 518.9*150000= 77835000 Pass
effort diatas. FP= Effort= Bfs=103780000+103780000+103780000+ 77835000+ 62268000+ 44106500+ 77835000 = 573384500
4.3.2 Evaluasi Sistem Berdasarkan Kuesioner Pengguna
Evaluasi aplikasi yang telah ada dilakukan untuk melakukan evaluasi dari sisi pengguna terhadap sistem. Evaluasi ini dilakukan oleh 5 software house yang mencoba langsung aplikasi ini dan mengisi kuesioner yang diberikan. Berikut adalah hasil evaluasi pengguna:
1. Tampilan aplikasi
Gambar 4. 25: Diagram Evaluasi Tampilan Aplikasi
Pada diagram diatas, hasil menyatakan bahwa 80% dari pengguna menilai bahwa tampilan aplikasi sangat baik, dan sisanya yaitu 20% dari pengguna menilai tampilan aplikasi baik.
Sangat Baik 80% Baik 20% 0% 0%
Tampilan Aplikasi
2. Menggunakan aplikasi sejenis
Gambar 4. 26: Diagram Evaluasi Menggunakan Aplikasi Sejenis
Pada diagram diatas, hasil menyatakan bahwa 60% dari pengguna pernah menggunakan aplikasi sejenis dan sisanya yaitu 40% dari pengguna belum pernah menggunakan aplikasi sejenis.
3. Memahami model pengukuran function point
Gambar 4. 27: Diagram Evaluasi Memahami Function Point Pernah 60% Belum Pernah 40% 0% 0%
Menggunakan Aplikasi Sejenis
Memahami 40% Kurang Memahami 40% Tidak Memahami 20% 0%
Pada diagram diatas, hasil menyatakan bahwa 40% dari pengguna memahami model pengukuran function point, 40% lainnya kurang memahami model pengukuran function point dan sisanya yaitu 20% tidak memahami function point.
4. Memahami setiap input-an
Gambar 4. 28: Diagram Evaluasi Memahami Setiap Input-an
Pada diagram diatas, hasil menyatakan bahwa 60% dari pengguna memahami setiap inputan yang diminta untuk memasukkan nilai-nilai, 20% dari pengguna menyatakan kurang memahami inputan yang diminta dan 20% sisanya tidak memahami inputan.
Memahami 60% Kurang Memahami 20% Tidak Memahami 20% 0%
5. Membantu user dengan fitur help
Gambar 4. 29: Diagram Evaluasi Membantu User dengan Fitur Help
Pada diagram diatas, hasil menyatakan bahwa 60% dari pengguna menilai fitur help yang tersedia sangan membantu pengguna untuk menjalankan aplikasi dan sisanya yaitu 40% dari pengguna menilai fitur help yang tersedia cukup membantu pengguna dalam menjalankan aplikasi.
6. Membantu user dalam mengestimasi biaya
Gambar 4. 30: Diagram Evaluasi Membantu dalam Mengestimasi Biaya Sangat Membantu 60% Cukup Membantu 40% Kurang Membantu 0% 0%
Membantu User dengan Fitur Help
Sangat Membantu 60% Cukup Membantu 40% Kurang Membantu 0% 0%
Pada diagram diatas, hasil menyatakan bahwa 60% dari pengguna menilai aplikasi ini sangat membantu pengguna dalam mengestimasi biaya pembuatan sebuah project software dan sisanya yaitu 40% dari pengguna menilai aplikasi ini cukup membantu dalam mengestimasi biaya pembuatan sebuah project software.
7. Mudah dalam mengakses kapan saja dan dimana saja
Gambar 4. 31: Diagram Evaluasi Mengakses Kapan Saja dan Dimana Saja
Pada diagram diatas, hasil menyatakan bahwa 80% dari pengguna menilai aplikasi ini mudah diakses kapan saja dan dimana saja. 20% sisanya menilai aplikasi ini tidak mudah untuk diakses kapan saja dan dimana saja.
Ya 80% Tidak
20%
0% 0%
4.4 Evaluasi Antarmuka Pengguna 1. Konsisten
Konsisten dilakukan pada urutan tindakan, perintah dan istilah yang digunakan pada prompt, menu, serta layar bantuan.
Gambar 4. 32: Evaluasi Antarmuka Pengguna - Konsisten
2. Memenuhi kegunaan universal
Kenali kebutuhan pengguna yang beragam. Hal-hal seperti perbedaan pengguna bagi pemula dan ahli/berpengalaman, perbedaan usia dan keragaman jenis pengguna lainnya dapat memperkaya user interface dan meningkatkan kualitas sistem.
Gambar 4. 33: Evaluasi A
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.
Gambar 4. 34: Evaluasi Antarmuk
: Evaluasi Antarmuka Pengguna – Memenuhi Kegunaan Universal
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 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
: Evaluasi Antarmuka Pengguna – Memberikan Umpan Balik yang Informatif Memenuhi Kegunaan Universal
Untuk setiap tindakan operator, sebaiknya disertakan suatu sistem umpan balik. Untuk tindakan yang sering dilakukan dan tidak terlalu penting, dapat 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
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.
Gambar 4. 35: Evaluasi Antarmuka Penggun
5. Memberikan penanganan kesalahan
Sedapat mungkin sistem dirancang sehing
melakukan kesalahan fatal. Jika kesalahan terjadi, sistem dapat mendeteksi kesalahan dengan cepat dan memberikan mekanisme yang sederhana dan mudah dipahami untuk penanganan kesalahan.
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
: Evaluasi Antarmuka Pengguna – Merancang Dialog yang Menghasilkan Penutupan
Memberikan 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.
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
Merancang Dialog yang Menghasilkan
ga pengguna tidak dapat melakukan kesalahan fatal. Jika kesalahan terjadi, sistem dapat mendeteksi kesalahan dengan cepat dan memberikan mekanisme yang sederhana dan mudah
Gambar 4. 36: Evaluasi Antarmuka Penggun
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
Gambar 4. 37: Evaluasi Antarmuka Penggun
7. Mendukung tempat pengendali internal
Pengguna ingin menjadi pengotrol sistem dan sistem akan merespon tindakan yang dilakukan pengguna daripadapengguna merasa bahwa sistem mengotrol
: Evaluasi Antarmuka Pengguna – Memberikan Penanganan Kesalahan
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.
: Evaluasi Antarmuka Pengguna –Mudah Kembali ke Tindakan Sebelumnya
Mendukung tempat pengendali internal
Pengguna ingin menjadi pengotrol sistem dan sistem akan merespon tindakan yang dilakukan pengguna daripadapengguna merasa bahwa sistem mengotrol
emberikan Penanganan Kesalahan
Hal ini dapat mengurangi kekhawatiran pengguna karena pengguna mengetahui kesalahan yang dilakukan dapat dibatalkan, sehingga pengguna tidak
n yang belum biasa digunakan.
Mudah Kembali ke Tindakan Sebelumnya
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.
Gambar 4. 38: Evaluasi Antarmuka Penggun
8. Mengurangi beban ingatan jangka pendek
Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana atau banyak tampilan halaman yang sebaiknya disatukan, serta diberikan
pelatihan untuk kode dan urutan tindakan.
Gambar 4. 39: Evaluasi Antarmuka Penggun
pengguna. Sebaiknya sistem dirancang sedemikian rupa sehingga pengguna menjadi inisiator daripada responden.
: Evaluasi Antarmuka Pengguna – Mendukung Tempat Pengendali Internal
Mengurangi beban ingatan jangka pendek
Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana atau banyak tampilan halaman yang sebaiknya disatukan, serta diberikan
pelatihan untuk kode dan urutan tindakan.
: Evaluasi Antarmuka Pengguna – Mengurangi Beban Ingatan Jangka Pendek pengguna. Sebaiknya sistem dirancang sedemikian rupa sehingga pengguna menjadi
Mendukung Tempat Pengendali Internal
Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana atau cukup waktu
