Bab ini berisi kesimpulan dari keseluruhan permasalahan penelitian tugas akhir dan saran perbaikan yang dapat dikembangkan di masa mendatang untuk bagi pihak lain yang ingin meneruskan topik tugas akhir ini. Tujuannya adalah agar pihak lain tersebut dapat menyempurnakan tugas akhir ini sehingga bisa menjadi lebih baik dan berguna.
STIKOM
9 BAB II
LANDASAN TEORI
Pada bab ini dijelaskan mengenai teori-teori dan penelitian terkait terdahulu yang digunakan dalam pengerjaan tugas akhir ini.
2.1 Penelitian Effort Rate (ER) Sebelumnya
Pada penelitian sebelumnya telah dilakukan beberapa perhitungan untuk mencari nilai effort rate. Nilai effort rate yang dihasilkan dari penelitian sebelumnya menunjukkan hasil yang berbeda-beda. Penelitian tentang effort rate yang pernah dilakukan sebelumnya dapat dilihat pada gambar 2.1 seperti berikut:
Dari gambar 2. 1 di atas, maka dapat disimpulkan bahwa nilai Effort Rate (ER) yang digunakan oleh sebagaian besar peneliti yaitu sebesar 20 man-hours seperti yang pertama kali diusulkan oleh Karner, namun penelitian tentang nilai effort rate yang dilakukan oleh Karner hanya menggunakan tiga data proyek pengembangan perangkat lunak dengan menggunakan analisis regresi. Analisis
Gambar 2.1 Penelitian effort rate sebelumnya
STIKOM
regresi dengan menggunakan tiga data diskrit cenderung tidak akurat. Analisis korelasi antar data untuk membentuk persamaan regresi juga tidak dilakukan.
Selain itu, penelitian perhitungan effort rate yang dilakukan oleh Karner terjadi pada tahun 1993. Teknologi informasi dalam rentang waktu 1993 sampai 2013 mengalami pekembangan yang cukup pesat, sehingga sangat dimungkinkan nilai effort rate yang ditemukan oleh Karner tidak sesuai apabila diaplikasikan dalam perhitungan estimasi effort untuk proyek pengembangan perangkat lunak yang dikerjakan pada tahun 2013 dan tahun-tahun mendatang. Maka dari itu, nilai Effort Rate (ER) yang diusulkan oleh Karner dapat dipertanyakan dan ditinjau ulang.
2.2 Teori Pendukung 2.2.1 Estimasi Effort
Salah satu aspek terpenting dalam tahapan perencanaan adalah melakukan estimasi atau perkiraan, baik dari segi biaya, waktu maupun sumber daya. Definisi dari estimasi adalah sebuah pengukuran yang didasarkan pada hasil secara kuantitatif atau dapat diukur dengan angka tingkat akurasinya (Tockey, 2004).
Sisi penting estimasi dalam perencanaan proyek adalah munculnya jadwal serta anggaran yang tepat, meski tidak sepenuhnya sebuah estimasi akan berakhir dengan tepat. Tetapi, tanpa sebuah estimasi dalam pelaksanaan proyek perangkat lunak maka dapat dikatakan bahwa proyek perangkat lunak tersebut adalah sebuah blind project. Yang diibaratkan seperti seorang buta yang harus berjalan di sebuah jalan raya yang sangat ramai (Rizky, 2011).
Estimasi yang dilakukan pada penelitian ini diaplikasikan dalam proyek pengembangan perangkat lunak. Definisi dari estimasi perangkat lunak yaitu suatu
STIKOM
kegiatan melakukan prediksi atau ramalan mengenai keluaran dari sebuah proyek dengan meninjau jadwal, usaha, biaya bahkan hingga ke resiko yang akan ditanggung dalam proyek tersebut (Galorath, 2006). Meski estimasi tidak mungkin dapat menghasilkan sebuah hasil yang sangat akurat, tetapi ketidakakuratan tersebut dapat diminimalkan dengan menggunakan beberapa metode yang sesuai dengan proyek yang akan dilakukan estimasi.
Penelitian ini mengangkat estimasi effort pada proyek pengembangan perangkat lunak. Effort adalah kerja real yang kita lakukan dalam menyelesaikan suatu proyek. Satuannya adalah mandays atau manhour. Misalnya suatu aplikasi diestimasi membutuhkan effort 10 mandays. Artinya aplikasi ini akan selesai bila dikerjakan 1 orang selama 10 hari terus menerus atau 5 hari bila ada 2 pekerja. Effort tidak mempertimbangkan libur ataupun cuti (Muhardin, 2011).
Dari pengertian estimasi dan effort di atas, maka dapat disimpulkan bahwa estimasi effort adalah suatu kegiatan melakukan prediksi atau ramalan mengenai berapa banyak pekerja dan berapa lama waktu yang diperlukan untuk menyelesaikan proyek tersebut. Estimasi effort pada penelitian ini akan didapatkan setelah melakukan perhitungan menggunakan metode use case point (UCP).
2.2.2 Use Case Point (UCP)
Metode use case point (UCP) adalah metode yang mempunyai kemampuan untuk memberikan estimasi effort yang diperlukan untuk membuat suatu proyek berdasarkan jumlah dan kompleksitas usecase yang dimiliki oleh proyek perangkat lunak tersebut (Karner, 1993). Menurut pendapat lain, UCP
STIKOM
Menghitung Use Case Point (UCP)
UCP = UUCP + TCF + ECF Menghitung Unajusted
Use Case Weight (UUCW) Menghitung Unajusted
Actor Weight (UAW)
Menghitung Technical Complexity Factor (TF)
Menghitung Environment Complexity Factor (EF)
Menghitung Unajusted Use Case Point (UUCP)
UUCP = UAW + UUCW
Menghitung Complexity Factor TCF = 0.6 + (0.01 * TF) ECF = 1.4 + (-0.03 * EF)
adalah metode yang dapat menganalisa actor, use case, dan berbagai faktor teknis dan faktor lingkungan hingga menjadi suatu persamaan (Clemmons, 2006).
Kelebihan dari metode use case point yaitu dapat memberikan estimasi yang hampir mendekati estimasi sebenarnya yang dihasilkan dari pengalaman pembuatan atau pengembangan software. Hal tersebut dibuktikan oleh beberapa penelitian yang pernah dilakukan sebelumnya, dan menghasilkan pernyataan sebagai berikut:
1. UCP memiliki deviasi sebesar 6% (Nageswaran, 2001).
2. UCP memiliki deviasi sebesar 19%, sementara estimasi para ahli memiliki deviasi sebesar 20% (Anda, 2002).
3. UCP memiliki deviasi sebesar 9% (Carroll, 2005).
Langkah-langkah yang dilakukan dalam proses estimasi effort dengan use case point digambarkan dalam gambar 2.2 berikut ini (Karner, 1993) :
Gambar 2.2 Langkah – langkah Metode Use Case Point (UCP)
STIKOM
2.2.2.1 Menghitung Unadjusted Use Case Point (UUCP) a). Unadjusted Actor Weights (UAW)
Langkah pertama adalah menentukan terlebih dahulu aktor sebagai simple, average, atau complex sesuai tabel 2.1 seperti berikut:
Tabel 2.1 Tipe, Bobot, dan Deskripsi Actor
Actor Weight Description
Simple 1 Didefinisikaan dengan API Medium 2 Berinteraksi melalui Protokol TCP/IP Complex 3 Berinteraksi dengan GUI atau Web Page
Total Unadjusted Actor Weights (UAW) didapat dari menghitung jumlah actor dari masing-masing jenis (tingkat kompleksitas), dikali dengan total faktor berat masing-masing sesuai dengan tabel.
b). Unadjusted Use Case Weights (UUCW)
Cara menghitung UUCW sama dengan cara menghitung UAW, yaitu masing-masing use case dibagi menjadi 3 kelompok yaitu simple, average, dan complex, tergantung dari jumlah transaksi yang dilakukan. Untuk penjelasan lebih detil tentang deskripsi use case dapat dilihat pada tabel 2.2 seperti berikut :
Tabel 2.2 Tipe, Bobot, dan Deskripsi Use Case
Use Case Weight Description
Simple 5 Menggunakan <= 3 transaksi Medium 10 Menggunakan 4 sampai 7 transaksi Complex 15 Menggunakan > 7 transaksi
Total Unadjusted Use Case Weights (UUCW) didapat dari menghitung jumlah use case dari masing-masing tingkat kompleksitas dikali dengan total faktor setiap use case. Kemudian jumlahkan UAW dan
STIKOM
UUCW untuk mendapatkan Unadjusted Use Case Point (UUCP), seperti rumus berikut :
���� = ���+����... (2.1)
2.2.2.2 Menghitung Technical Complexity Factor (TCF) dan Enviromental Complexity Factor (ECF)
Pada perhitungan nilai Use Case Point (UCP) terdapat nilai complexity factor. Pengertian dari complexity factor adalah faktor-faktor yang berpengaruh secara langsung dalam proses pengerjaan proyek perangkat lunak tersebut. Complexity factor dibagi menjadi 2 kelompok, yaitu :
1. Technical Complexity Factor (TCF) 2. Environmental Complexity Factor (ECF)
Berikut penjelasan masing-masing dari complexity factor : a). Technical Complexity Factor (TCF)
Tabel 2.3 Technical Factor dan Bobot
Technical Factor Bobot
1. Distributed System Required 2 2. Response Time is Important 1
3. End User Efficiency 1
4. Complex Internal Processing Required 1 5. Reusable Code Must Be A Focus 1
6. Installation easy 0.5 7. Usability 0.5 8. Cross-platform support 2 9. Easy to change 1 10. Highly concurrent 1 11. Custom security 1
12. Dependence on third-part code 1
13. User training 1
STIKOM
Nilai-nilai pada technical factor tersebut dikalikan dengan bobot nilai masing-masing. Bobot nilai yang 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. Hasil perkalian nilai dan bobot tersebut kemudian dijumlahkan untuk mendapatkan total Technical Factor (TF), yang kemudian digunakan untuk mendapatkan Technical Complexity Factor (TCF).
TCF = 0.6 + (0.01 x TF) ... (2.2)
b). Enviromental Complexity Factor (ECF)
Tabel 2.4 Environmental Factor dan Bobot Enviromental Factor Bobot 1. Familiarity with the Project 1.5 2. Application Experience 0.5 3. OO Programming Experience 1 4. Lead Analyst Capability 0.5
5. Motivation 1
6. Stable Requirements 2
7. Part Time Staff -1
8. Difficult Programming Language -1
Nilai-nilai pada environmental factor tersebut dikalikan dengan bobot nilai masing-masing. Bobot nilai yang 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. Hasil perkalian nilai dan bobot tersebut kemudian dijumlahkan untuk mendapatkan total Environmental Factor (EF), yang
STIKOM
kemudian digunakan untuk mendapatkan Environmental Complexity Factor (ECF).
ECF = 1.4 + (−0.03 x EF) ... (2.3)
Sehingga akhirnya kita bisa mendapatkan nilai dari Use case Point (UCP) yang didapatkan melalui perkalian UUCP, TCF, dan ECF.
UCP = UUCP + TCF + ECF... (2.4)
2.2.3 Perhitungan Nilai Effort Rate
Effort rate didefinisikan sebagai jumlah usaha per use case point. Pendekatan yang dijelaskan bersifat umum dan dapat digunakan untuk menganalisa berbagai data, tidak hanya data untuk pengembangan perangkat lunak, tetapi juga data pemeliharaan perangkat lunak dan jenis lain dari rekayasa perangkat lunak (Stewart, 2002).
Effort rate adalah rasio jumlah jam orang per use case point berdasarkan proyek-proyek di masa lalu. Jika proyek tersebut merupakan proyek baru dan tidak terdapat data histori yang telah terkumpul, maka digunakan nilai yang berkisar antara 15 sampai 30. Namun, nilai yang paling sering dipakai adalah angka 20 (Clemmons, 2006).
Rumus perhitungan estimasi effort menggunakan metode UCP adalah sebagai berikut :
Estimasi Effort = UCP x ER ... (2.5)
Apabila nilai ER dihitung dari satu proyek saja maka nilai ER didapatkan dari pembagian antara nilai actual effort dengan nilai UCP, sebagai berikut :
� �� � =� � � ��
UCP ... (2.6)
STIKOM
Namun, pada penelitian tugas akhir ini dilakukan perhitungan nilai effort rate menggunakan beberapa data proyek pengembangan perangkat lunak, sehingga untuk mendapatkan nilai ER yang valid harus dilakukan perhitungan menggunakan persamaan regresi.
2.2.4 Analisis Korelasi dan Persamaan Regresi 2.2.4.1 Analisis Korelasi
Analisis korelasi merupakan analisis terhadap kekuatan hubungan antara variabel bebas X dengan variabel tak bebas Y. Koefisien korelasi linier adalah ukuran hubungan linier antara satu variabel x dengan satu variabel y, dan dilambangkan dengan “r” (Usman, 2006). Hasil dari perhitungan korelasi diinterpretasikan pada sebuah hubungan yang didasarkan pada nilai angka yang muncul. Interpretasi nilai korelasi dapat dilihat pada tabel 2.5 seperti berikut :
Tabel 2.5 Interpretasi Nilai R (Korelasi)
R Interpretasi
0 Tidak Berkorelasi
>0 – 0.25 Korelasi Sangat Lemah >0.25 – 0.5 Korelasi Cukup
>0.5 – 0.75 Korelasi Kuat
>0.75 – 0.99 Korelasi Sangat Kuat
1 Korelasi Sempurna
2.2.4.2 Persamaan Regresi
Analisis regresi merupakan hubungan ketergantungan antara satu variabel tak bebas (dependent variabel) dengan satu atau lebih variabel bebas (independent variabel) dengan tujuan untuk memperkirakan nilai rata-rata dari variabel tak
STIKOM
bebas, apabila variabel bebasnya sudah diketahui (Usman, 2006). Variabel bebas dilambangkan dengan X dan variabel tak bebas dilambangkan Y. Berikut persamaan matematiknya:
= + ... (2.7)
Untuk mengetahui hubungan antara variabel bebas dengan variabel tak bebas dimulai dengan mencari bentuk terdekat dari hubungan tersebut dalam sebuah diagram pencar, dimana setiap datanya dinyatakan dalam bentuk koordinat (x,y). Jika titik-titik yang terbentuk mengikuti suatu garis lurus, maka variabel x dan y dikatakan saling berhubungan secara linier (Usman, 2006), seperti gambar 2.3 berikut ini:
Gambar 2.3 Pola Garis Lurus Regresi
Antara variabel bebas X dan variabel terikat Y membentuk sebuah pola garis yang lurus, dan dalam aplikasinya jika nilai X meningkat maka nilai Y juga meningkat dan jika nilai X mengalami penurunan makan nilai Y juga mengalami penurunan.
2.2.5 Proyek Perangkat Lunak Pemerintahan
Pemanafaatan internet dalam suatu institusi dapat membuat pekerjaan semakin efektif. Untuk dinas pemerintahan, internet akan sangat membantu dalam menyukseskan program e- government. Dalam e-government, internet menjadi
STIKOM
teknologi yang berperan dalam proses penyediaan dan transfer informasi dari pemerintah kepada pihak lain, misalnya warga masyarakat, ataupun sebaliknya.
Pemanfaatan teknologi komunikasi dan informasi dalam proses pemerintahan akan meningkatkan efisiensi, efektifitas, transparansi dan akuntabilitas penyelenggaraan pemerintahan. E-government merupakan perubahan radikal di dalam sistem dan tata laksana pemerintahan yang menuntut teladan kepemimpinan, kesediaan merubah paradigma, berani bertindak transparan, dan semua itu bukan sekedar untuk melayani kepen-tingan publik semata, tetapi mencakup kepentingan yang lebih luas yaitu sebagai bagian dari sistem pemerintahan yang bertujuan untuk mensejahterakan masyarakat (Wigrantoro, 2003).
Pada penelitian ini, studi kasus yang diteliti yaitu studi kasus pembuatan perangkat lunak di bidang kepemerintahan, antara lain :
1. Pembuatan perangkat lunak website Pemerintah Kabupaten Buton Utara (www.butonutarakab.go.id).
2. Pembuatan perangkat lunak Bursa Kerja online Dinas Tenaga Kerja Pemerintah Kota Surabaya (bursakerja.surabaya.go.id).
3.
Pembuatan perangkat lunak website Badan Kependudukan dan Keluarga Berencana Yogyakarta (yogya.bkkbn.go.id).4. Pembuatan perangkat lunak website resmi Pemerintah Kabupaten Tegal (www.tegalkab.go.id).
5. Pembuatan perangkat lunak website Dinas Pertanian D.I.Yogyakarta (www.distan.pemda-diy.go.id).
STIKOM
6. Pembuatan perangkat lunak website Dinas perindustrian, perdagangan, dan koperasi DIY (www.disperindagkop.pemda-diy.go.id).
7. Pembuatan perangkat lunak website Gerai Pelayanan Perizinan Terpadu BKPM Provinsi DIY (www.geraip2t.jogjaprov.go.id).
8. Pembuatan perangkat lunak website Dinas Kesehatan Kabupaten Tegal (www.dinkes.tegalkab.go.id).
STIKOM
21
Metode penelitian dalam tugas akhir diperlukan sebagai panduan agar tahapan pengerjaan tugas akhir dapat berjalan secara terarah dan sistematis. Tahapan-tahapan pengerjaan penelitian tugas akhir ini akan ditunjukkan melalui gambar 3.1 seperti berikut:
Start
Pengumpulan Data
Pembuatan Use Case Diagram Jumlah Pekerja,
Jumlah Waktu Daftar Kebutuhan Website
Hitung UUCP
Hitung TCF
Hitung ECF
Hitung UAW
Hitung UUCW
Use Case Point (UCP) Estimation
Perhitungan Use Case Point Estimation
End
Analisis Korelasi dan Persamaan Linier
Effort Rate
Hitung Lagi ? Y
Hitung Nilai Actual Effort
Nilai Actual Effort
Hitung Lagi ? Y
N N
Perhitungan Nilai Effort Rate (ER)
Gambar 3.1 Tahapan Penelitian Tugas Akhir
STIKOM
3.1 Pengumpulan Data
Pengumpulan data dilakukan dengan berbagai cara, antara lain dengan wawancara, survei atau observasi, dan kuisioner. Pengumpulan data dilakukan dengan tujuan untuk mendapatkan data-data yang dibutuhkan dalam pengerjaan tugas akhir ini. Adapun data yang butuhkan pada tugas akhir ini dibagi menjadi 3 data seperti berikut :
1. Jumlah Pekerja dan jumlah waktu kerja: jumlah pekerja dan jumlah waktu kerja digunakan sebagai bahan untuk perhitungan nilai actual effort. Nilai actual effort yaitu nilai yang dibutuhkan oleh tim pengembang untuk menyelesaikan proyek dari mulai sampai selesai. Pada penelitian ini, actual effort didapatkan melalui kegiatan wawancara yang dilakukan oleh penulis dengan pihak pengembang, terutama dengan manajer proyek pengembang perangkat lunak. Pedoman wawancara penggalian informasi nilai actual effort dapat dilihat pada tabel 3.1 seperti berikut :
Tabel 3.1 Pedoman Wawancara Penggalian Informasi Nilai Actual Effort
Peran ∑ Orang Tugas Waktu
Estimasi Actual 1.
2. 3.
∑ Orang ... ∑ hari ...
Aktul Effort = ∑ Orang x ∑ Jam ... 2. Daftar kebutuhan website : yaitu daftar yang berisi data use case dan actor apa saja yang terdapat pada masing – masing website. Banyak tim pengembang tidak membuat dokumen SKPL pada proyek pengembangan perangkat lunak website yang mereka kerjakan, begitu pula pada proyek pembuatan website
STIKOM
kepemerintahan yang diteliti oleh penulis pada tugas akhir ini. Oleh karena itu, penulis mendapatkan daftar kebutuhan proyek pengembangan website dari beberapa cara sebagai berikut :
a). Wawancara b). Observasi website c). User guide
3. Nilai technical factor dan nilai environmental factor : Penulis memberikan kuisioner kepada masing-masing pengembang perangkat lunak website kepemerintahan. Tujuan dari pembagian kuisioner ini yaitu untuk mendapatkan nilai pada masing-masing faktor yang mempengaruhi technical factor dan environmental factor sesuai dengan keadaan real yang dialami oleh pengembang proyek perangkat lunak website kepemerintahan.
3.2 Perhitungan Nilai Actual Effort
Setelah proses pengumpulan data, selanjutnya dapat dilakukan proses hitung nilai actual effort maupun proses pembuatan use case diagram. Tidak terdapat aturan urutan pengerjaan perhitungan nilai actual effort dan pembuatan use case diagram. Sehingga, perhitungan nilai actual effort maupun pembuatan use case diagram dapat dikerjakan tanpa memperhatikan urutan, tergantung dari data mana yang didapatkan terlebih dahulu.
Nilai actual effort adalah nilai yang dihasilkan dari banyaknya jumlah pegawai dan jumlah waktu yang diperlukan untuk mengerjakan proyek perangkat lunak. Nilai actual effort didapatkan melalui proses wawancara yang dilakukan kepada pihak pengembang proyek perangkat lunak website kepemerintahan. Data yang dibutuhkan yaitu banyaknya jumlah pekerja dan lama waktu pengerjaan
STIKOM
yang dibutuhkan oleh pengembang untuk menyelesaikan proyek perangkat lunak website kepemerintahan tersebut.
Setelah didapatkan jumlah pekerja dan jumlah waktu pengerjaan proyek perangkat lunak website kepemerintahan, maka selanjutnya dapat dihitung nilai actual effort untuk proyek pembuatan perangkat lunak website kepemerintahan dengan rumus, sebagai berikut :
� �� � = Pekerja x Hari Kerja x Jam Kerja per Hari .... (3.1) 3.3 Pembuatan Use Case Diagram
Setelah didapatkan daftar kebutuhan pembuatan website, maka dapat dilakukan proses pembuatan use case diagram. Daftar kebutuhan tersebut berisi use case dan actor yang dibutuhkan pada proyek pembuatan perangkat lunak website kepemerintahan. Untuk memudahkan proses pengerjaan dan pendokumentasian use case diagram, maka digunakan alat bantu atau tools yakni Enterprise Architect 7.5.
Berikut ini langkah-langkah dalam pembuatan use case diagram dalam Enterprise Architect 7.5 :
1) Buka Aplikasi Enterprise Architect 7.5.
2) Pilih Menu File > New Project > Beri nama file dan tentukan lokasi penyimpanan.
3) Setelah itu akan muncul pilihan “Select model(s)”. Pada Kolom “Name”, centang pada “Use Case”, lalu klik tombol OK.
4) Pada sebelah kanan halaman, terdapat jendela Project Browser. Diawali dengan membuat paket modul, yakni dengan cara klik kanan pada folder
STIKOM
“Use Case Model” > Add > Add Package. Beri nama package sesuai dengan modul yang akan dibuat dalam aplikasi.
5) Untuk membuat aktor baru, klik kanan pada folder “Actors” > Add > Add Element. Beri nama aktor dan jangan lupa pastikan pilihan Type ialah Actor, lalu klik Create.
6) Sedangkan untuk membuat use case baru, pada jendela Project Browser klik kanan pada folder “Use Case” > Add > Add Use Case. Beri nama use case dan jangan lupa pastikan pilihan Type yaitu UseCase, lalu klik OK.
7) Khusus untuk use case, penjelasan aktivitas sistem dapat dituangkan ke dalam skenario use case di dalam Enterprise Architect dengan cara memilih (klik 2 kali pada use case yang ada pada Project Browser), lalu pada tab “Scenario” > Buat nama skenario > pilih type nya yaitu “Basic Path” > Ketikkan poin-poin skenario pada kotak yang telah tersedia, jika sudah selesai jangan lupa klik tombol Simpan.
Setelah dilakukan pembuatan use case diagram menggunakan Enterprise Architect, maka selanjutnya dapat dilakukan penentuan kompleksitas use case berdasarkan kompleksitas masing-masing use case.
3.4 Perhitungan Use Case Point (UCP)
3.4.1 Perhitungan Unadjusted Use Case Point (UUCP)
Untuk mendapatkan nilai UUCP, maka perlu dilakukan pembobotan dan skoring terkait kompleksitas actor dan use case ditinjau dari use case diagram yang telah dibuat pada tahap sebelumnya. Skoring dihitung berdasarkan parameter-parameter yang telah ditentukan.
STIKOM
Terdapat dua langkah yang dilakukan untuk menghitung UUCP, antara lain sebagai berikut:
1. Menghitung Unadjusted Actor Weights (UAW) 2. Menghitung Unadjusted Use Case Weights (UUCW) a). Perhitungan Unadjusted Actor Weights (UAW)
Perhitungan UAW dilakukan untuk menghitung jumlah bobot actor yang terlibat pada pembuatan proyek perangkat lunak website kepemerintahan. Perhitungan bobot actor dilakukan dengan cara mengklasifikasikan masing-masing actor ke dalam masing-masing bobot yang telah ditentukan berdasarkan tabel 2.1. Setelah didapatkan masing-masing bobot pada tiap actor¸ kemudian dilakukan akumulasi dari seluruh nilai bobot actor, sehingga menghasilkan nilai UAW yang dibutuhkan pada proyek pengembangan website perangkat lunak kepemerintahan tersebut. Rumus perhitungan UAW yaitu :
UAW = Jumlah � � x Bobot � � ... (3.2) b). Perhitungan Unadjusted Use Case Weights (UUCW)
Perhitungan UUCW dilakukan untuk menghitung jumlah bobot use case yang dibutuhkan pada pembuatan proyek perangkat lunak website kepemerintahan. Perhitungan bobot use case dilakukan dengan cara mengklasifikasikan masing-masing use case ke dalam masing-masing bobot yang telah ditentukan berdasarkan tabel 2.2. Setelah didapatkan masing-masing bobot pada tiap use case¸ kemudian dilakukan akumulasi dari seluruh nilai bobot use case, sehingga menghasilkan nilai UUCW yang dibutuhkan pada proyek pengembangan website perangkat lunak kepemerintahan tersebut.
STIKOM
UUCW = Jumlah � � x Bobot � � ... (3.3)
Setelah diketahui nilai UAW dan UUCW, maka selanjutnya dapat dilakukan perhitungan nilai UUCP dengan rumus berikut :
UUCP = UAW + UUCW ... (3.4)
3.4.2 Menghitung Technical Complexity Factor (TCF)
Langkah selanjutnya setelah diketahui nilai UUCW yaitu melakukan perhitungan nilai TCF. Nilai TCF pada penelitian tugas akhir ini adalah nilai dari faktor teknis yang mempengaruhi proyek pembuatan perangkat lunak website kepemerintahan. Adapun faktor–faktor teknis yang mempengaruhi proyek pembuatan perangkat lunak website kepemerintahan beserta besar bobot masing-masing faktor teknis dapat dilihat pada tabel 2.3.
Setelah diketahui masing faktor teknis dan besar bobot masing-masing faktor teknis, kemudian dilakukan pemberian nilai pada masing-masing-masing-masing faktor teknis. Nilai yang diberikan pada setiap faktor tergantung dari seberapa besar pengaruh dari faktor tersebut terhadap pengerjaan proyek pembuatan website perangkat lunak kepemerintahan. Nilai 0 berarti tidak mempengaruhi, nilai 3 berarti rata-rata, dan nilai 5 berarti faktor teknis tersebut mempunyai pengaruh yang besar terhadap pengerjaan website kepemerintahan tersebt. Hasil perkalian nilai dan bobot pada faktor teknis tersebut kemudian dijumlahkan untuk mendapatkan nilai total Technical Factor (TF), yang kemudian nilai tersebut digunakan untuk menghitung Technical Complexity Factor (TCF) dengan rumus sebagai berikut :
TCF = 0.6 + (0.01 x TF) ... (3.5)
STIKOM
Pemberian nilai masing-masing faktor teknis dilakukan dengan cara