5
BAB II
TINJAUAN PUSTAKA
2.1 GAMBARAN UMUM FUNCTION POINT ANALYSIS
Suatu sistem berkembang terus menerus baik dari segi ukuran dan kompleksitasnya. Sistem tersebut menjadi lebih sulit untuk dimengerti. Perbaikan dari aplikasi coding memungkinkan pengembang software untuk membuat software yang luas agar dapat memenuhi kebutuhan user yang juga terus berkembang. Seiring dengan pertumbuhan sistem tersebut, maka dikembangkan juga metode yang dapat dimengerti dan dapat mengkomunikasikan ukuran yang digunakan. Function Point Analysis merupakan teknik dari pemecahan masalah yang terstruktur. FPA merupakan metode yang dapat memecahkan suatu permasalahan kedalam komponen yang lebih kecil, sehingga dapat lebih mudah untuk dimengerti dan dianalisa. Function point merupakan pengukuran unit untuk software seperti jam untuk pengukuran waktu, kilometer untuk pengukuran jarak atau Celcius untuk pengukuran suhu.
Di dunia Function Point Analysis, sistem dibagi menjadi lima kelas besar dan karakteristik sistem umum. Tiga kelas atau komponen pertama adalah External Inputs, External Outputs dan External Inquiries. Setiap komponen ini bertransaksi dengan file sehingga disebut data transaksi. Dua kelas berikutnya adalah Internal Logical Files dan External Interface Files yang merupakan tempat penyimpanan data yang dikombinasikan dengan informasi secara logic. Sedangkan karakteristik sistem secara umum menilai fungsi umum dari sistem.
Seringkali istilah user digunakan tanpa menspesifikasikan artinya. Pada kasus ini, user yang dimaksud adalah user yang dapat mengerti sistem secara fungsional.
Karena Function Points mengukur sistem dari sisi fungsional maka bergantung pada teknologi. Diluar itu, baik bahasa, metode pengembangan, atau hardware platform yang digunakan, jumlah dari function point terhadap suatu sistem akan tetap konstan. Variabel satu-satunya adalah jumlah usaha yang dibutuhkan untuk menyelesaikan suatu set dari function point, sehingga Function Point Analysis bisa digunakan untuk menentukan apakah alat, environment, atau bahasa dapat lebih produktif jika dibandingkan pada satu organisasi atau dengan orgnaisasi yang lainnya. Hal ini merupakan titik penentu dan salah satu nilai terbesar dari Function Point Analysis.
Function Point Analysis dapat menyediakan mekanisme untuk menelusuri dan mengawasi ruang lingkup dalam suatu sistem. Penghitungan Function Points pada tahap akhir requirement, analisis, desain, coding, testing dan implementasi dapat dibandingkan. Penghitungan function point pada akhir tahap requirement dan/atau desain bisa dibandingkan dengan FP yang telah diselesaikan. Jika proyek tersebut telah berkembang, maka akan muncul scope creep. Jumlah pertumbuhan dari sistem menunjukkan bagaimana requirement dikumpulkan dan/atau dikomunikasikan pada tim proyek tersebut. Jika jumlah dari pertumbuhan proyek tersebut lebih cepat dari waktu yang seharusnya, maka diasumsikan bahwa komunikasi dengan user telah meningkat.
Function Point Analysis seharusnya dilakukan oleh orang yang terlatih dan berpengalaman. Jika Function Point Analysis dilakukan oleh orang yang belum terlatih, maka akan muncul asumsi bahwa analisis akan menjadi salah. Orang yang menghitung function points harus menggunakan versi terbaru dari Function Point Manual(saat ini 4.1).
Dokumentasi dari aplikasi terbaru harus digunakan untuk menyelesaikan penghitungan function point. Contohnya, screen format, report
layouts, daftar interface dengan sistem lain dan antar sistem, data model yang akan membantu Function Point Analysis.
Tugas menghitung function point harus termasuk sebagain bagian dari keseluruhan rencana proyek. Sehingga, menghitung function point harus dijadwalkan dan direncanakan. penghitungan function point yang pertama harus dikembangkan agar dapat menyediakan ukuran yang digunakan untuk memperkirakan function point suatu proyek
2.2 FUNCTION POINT ANALYSIS
Menurut Longstreet [2012], Function point analysis adalah suatu metode standard untuk mengukur pengembangan software dari sudut pandang user/pengguna.
FPA mengukur software dengan mengukur apa yang software sediakan untuk user secara fungsional berdasarkan desain secara logic. Berdasarkan pernyataan tersebut, tujuan dari FPA adalah untuk:
mengukur secara fungsional apa yang user minta dan terima
mengukur pengembangan dan maintenance software bergantung pada teknologi yang digunakan untuk implementasi
Sebagai tambahan untuk mencapai tujuan diatas, proses dari penghitungan function point adalah:
harus cukup sederhana untuk meminimalisir overhead proses pengukuran
merupakan ukuran yang konsisten untuk berbagai jenis proyek dan organisasi
alat untuk menentukan ukuran dari aplikasi yang dibeli dengan menghitung semua fungsi yang termasuk dalam paket
alat untuk membantu user menentukan keuntungan dari paket aplikasi bagi organisasi mereka dengan cara menghitung fungsi yang cocok dengan permintaan mereka
alat untuk mengukur unit produk software untuk mendukung analisa kualitas dan produktivitas
alat untuk memperkirakan biaya dan resource yang dibutuhkan untuk pengembangan dan maintenance software
faktor normalisasi untuk perbandingan software
2.3 PENGHITUNGAN FUNCTION POINT
Berikut adalah diagram prosedur penghitungan function point berdasarkan Function Point Counting Practices Manual.
Gambar 2.1 – Diagram Prosedur Penghitungan Function Point
Penghitungan function point dapat diaplikasikan pada proyek ataupun pada aplikasi.
Ada tiga tipe penghitungan function point :
Proyek pengembangan (development project)
Pengukuran function point pada proyek pengembangan mengukur fungsi yang disediakan untuk user sejak instalasi software yang akan digunakan pertama kali semenjak proyek tersebut selesai.
Proyek penambahan (enhancement project)
Penghitungan function point pada proyek penambahan mengukur modifikasi pada aplikasi yang sudah ada baik berupa penambahan, perubahan atau penghapusan fungsi yang dilakukan setelah proyek selesai.
Ketika proyek penambahan sudah ter-install, maka penghitungan function point harus diperbaharui agar dapat merefleksikan perubahan yang terjadi pada aplikasi secara fungsional.
Aplikasi
Penghitungan function point pada aplikasi dan proyek terhubung melalui aplikasi yang diinstall, yang disebut penghitungan function point baseline atau function point yang terinstall. Penghitungan ini menyediakan ukuran dari fungsi yang ada. Hasil penghitungan muncul ketika penghitungan function point dari proyek pengembangan selesai, yang di update setiap proyek penambahan (enhancement project) mengubah fungsi dari aplikasi yang ada.
Diagram berikut mengilustrasikan tipe penghitungan function point dan hubungan antar tipe tersebut.
Gambar 2.2 – Diagram Penghitungan Function Point
2.3.2 Definisi dari Tujuan Penghitungan
Tujuan dari penghitungan function point adalah untuk menyediakan jawaban bagi masalah bisnis, yaitu :
Mempertimbangkan tipe dari penghitungan dan bidang dari penghitungan yang diinginkan untuk mendapatkan jawab dari masalah secara bisnis yang sedang diteliti.
Mempengaruhi batasan antara software yang sedang di review dan software yang terkait.
2.3.3 Definisi Bidang Penghitungan
Bidang yang akan dihitung mendefiniskan fungsional yang akan masuk ke dalam penghitungan function point, yaitu :
Mendefinisikan subset dari software yang diukur Ditentukan oleh tujuan
2.3.4 Lima komponen utama dari Function Point
Merupakan hal yang umum bagi sistem komputer untuk berinteraksi dengan sistem komputer yang lain, sehingga lingkup atau batasan harus digambarkan pada setiap sistem agar dapat diukur berdasarkan klasifikasi
komponennya. Ruang lingkup ini harus digambarkan berdasarkan sudut pandang user. Pendeknya, ruang lingkup menunjukkan batasan antar proyek atau aplikasi yang sedang diukur dengan aplikasi atau user domain eksternal. Ketika batasan telah ditentukan, komponen dapat diklasifikasikan, diukur dan dihitung.
External Inputs (EI)
Merupakan proses dasar dimana data melewati batasan dari luar kedalam aplikasi. Data ini dapat berasal dari data input pada layar atau aplikasi lain. Data tersebut dapat digunakan untuk memelihara satu atau lebih Internal Logical Files. Data dapat berupa informasi control atau bisnis. Jika data berupa informasi control maka data tersebut tidak harus mengubah Internal Logical File.
External Outputs (EO)
Merupakan proses dasar dimana data dikirim melewati batasan dari dalam ke luar. Sebagai tambahan, EO dapat mengubah ILF. Data dapat menghasilkan suatu laporan atau file output yang dikirim ke aplikasi lainnya. Laporan dan file ini dibuat dari satu ILF atau lebih dan juga dari External Internal File.
External Inquiry (EQ)
Merupakan proses dasar dengan komponen input dan output yang menghasilkan data retrieval dari satu atau lebih ILF dan External Interface Files. Proses input tidak mengubah Internal Logical Files, dan output tidak memuat data asal.
Merupakan kelompok yang dapat diidentifikasikan oleh user yang secara logika berhubungan dengan data yang berada di ruang lingkup aplikasi dan dipelihara melalui external input.
External Interface Files (EIF)
Merupakan kelompok yang dapat diidentifikasikan oleh user, data ini berhubungan dengan data yang digunakan hanya sebagai referensi. Data sepenuhnya berada di luar ruang lingkup aplikasi dan dipelihara oleh aplikasi lain. External Interface Files merupakan Internal Logical Files bagi aplikasi lain.
2.3.5 Data Functions
Data Functions terdiri atas External Interface Files dan Internal Logical Files. Perbedaan utama antara EIF dan ILF adalah EIF tidak dipelihara oleh aplikasi yang sedang dihitung, sementara ILF dipelihara oleh aplikasi yang sedang dihitung.
Berikut adalah penjelasan istilah yang digunakan pada data functions. Control Information
Control Information merupakan data yang mempengaruhi proses dasar yang sedang dihitung. Control Information menspesifikasikan apa, kapan, atau bagaimana data yang akan diproses.
User Identifiable
Istilah User Identifiable mengacu pada permintaan yang telah ditetapkan untuk proses dan/atau grup dari data yang telah disetujui, dan dimengerti oleh user dan pengembang software.
Maintaned (Dipelihara)
Istilah maintained adalah kemampuan untuk memodifikasi data melalui proses dasar.
Elementary Process (Proses Dasar)
Proses dasar merupakan unit terkecil dari aktifitas user.
2.3.6.1 Aturan Identifikasi untuk ILF
Untuk mengidentifikasikan ILF, cari suatu kelompok data atau control information yang memenuhi definisi dari ILF.
Semua aturan berikut harus dipenuhi bagi suatu informasi agar dapat dihitung sebagai ILF:
Kelompok data atau control information adalah logis dan user identifiable.
Kelompok data yang dipelihara melalui proses dasar masih dalam ruang lingkup dari aplikasi yang sedang dihitung
2.3.6.2 Aturan Identifikasi untuk EIF
Untuk mengidentifikasikan ILF, cari suatu kelompok data atau control information yang memenuhi definisi dari ILF.
Semua aturan berikut harus dipenuhi bagi suatu informasi agar dapat dihitung sebagai ILF:
Kelompok data atau control information adalah logis dan user identifiable.
Kelompok data direferensikan oleh, dan eksternal pada aplikasi yang sedang dihitung.
Kelompok data tidak dipelihara oleh aplikasi yang sedang dihitung. Kelompok data merupakan ILF dari aplikasi lain.
2.3.6.3 Kompleksitas dan Kontribusi Definisi dan Aturan
Jumlah ILF, EIF dan hubungannya dengan kompleksitas secara fungsional menentukan kontribusi dari data functions untuk penghitungan Unadjusted Function Point.
DET
DET atau Data Element Type merupakan field unik yang dikenali oleh user.
Peraturan berikut digunakan untuk menghitung DET:
Hitung DET untuk setiap field yang unik dan dipelihara atau berasal dari ILF atau EIF melalui eksekusi proses dasar.
Ketika dua aplikasi memelihara dan/atau mengacu pada ILF/EIF yang sama, tapi setiap aplikasi memelihara/mengacu pada DET yang terpisah, maka hitung DET yang sedang digunakan oleh setiap aplikasi.
Hitung DET untuk setiap data yang ditetapkan oleh user untuk menetapkan hubungan dengan ILF/EIF yang lain.
RET
RET atau Record Element Type merupakan subgroup dari data elemen dalam suatu ILF/EIF
Ada dua tipe subgroup, yaitu : Optional
Subgrup optional adalah subgroup yang dapat dipilih user apakah akan digunakan atau tidak selama proses dasar yang melakukan penambahan suatu data.
Mandatory
Subgroup mandatory adalah subgroup yang harus digunakan oleh user.
Aturan RET
Salah satu aturan berikut harus digunakan ketika menghitung RET:
Hitung RET untuk setiap subgroup optional atau mandatory dari ILF/EIF
Berikut adalah matriks kompleksitas yang digunakan untuk menghitung ILF dan EIF
Tabel 2.1 – Tabel matrik kompleksitas ILF dan EIF
Ubah ILF dan EIF kedalam unadjusted function points menggunakan table berikut:
Untuk ILF, gunakan table berikut:
Tabel 2.2 – Tabel Unadjusted Function Point untuk ILF
Dan untuk EIF, gunakan table berikut:
Tabel 2.3 – Tabel Unadjusted Function Point untuk EIF
2.3.6 Transactional Functions
Transactional function mewakili fungsionalitas yang disediakan bagi user untuk memproses data dari aplikasi. Transactional functions terdiri atas External Inputs (EI), External Outputs (EO), dan External Inquiries (EQ).
Perbedaan utama dari tipe-tipe transactional functions adalah tujuan utama dari masing-masing tipe tersebut.
Berikut adalah istilah-istilah yang digunakan pada Transactional Functions. Processing logic
Didefinisikan sebagai kebutuhan spesifik dari user untuk menyelesaikan suatu proses dasar. Kebutuhan tersebut dapat termasuk kedalam action berikut :
- Adanya suatu validasi
- Adanya formula dan penghitungan matematis - Adanya nilai yang dikonversi
- Data di filter dan dipilih dengan menggunakan criteria tertentu untuk membandingkan beberapa set data
- Kondisi dianalisa untuk menentukan kondisi mana yang dapat digunakan
- Satu ILF atau lebih berubah - Satu ILF atau lebih menjadi acuan
- Data atau control information menjadi acuan
- Data awal dibuat dengan mengubah data yang ada untuk menambah data
- Perlakuan system dapat dipotong
- Menyiapkan dan menyediakan informasi dari luar ruang lingkupMemiliki kemampuan untuk menerima data atau control information yang memasuki ruang lingkup aplikasi - Data disusun
Satu proses dasar dapat memiliki beberapa alternatif di atas.
2.3.6.1 Aturan penghitungan Transactional Functions
Untuk mengklasifikan setiap proses dasar, tentukan tujuan utama dari deskripsi berikut, dan gunakan aturan yang berhubungan untuk mengidentifikasikan tipe transactional.
External Inputs
Tujuan utama dari External Inputs adalah untuk memelihara ILF atau mengubah perilaku dari system.
Untuk setiap proses dasar yang memiliki tujuan utama untuk memelihara satu atau lebih ILF atau untuk mengubah perilaku system, gunakan aturan berikut untuk menentukan apakah fungsi tersebut termasuk kedalam External Inputs.
Semua aturan berikut harus terpenuhi:
Data atau control information diterima dari luar ruang lingkup aplikasi Setidaknya satu ILF yang dipelihara jika data yang memasuki ruang
lingkup jika data tersebut tidak mengubah perilaku dari system
Untuk proses yang sedang diidentifikasi, satu dari tiga pernyataan dibawah harus terpenuhi :
- Logika pemrosesan yang unik dari pemrosesan yang dilakukan oleh external input lain untuk aplikasi
- Set dari data elemen diidentifikasikan berbeda dari set yang diidentifikasi oleh external inputs untuk aplikasi
- Acuan untuk ILF atau EIF berbeda dari file yang diacu oleh External Inputs pada aplikasi
External Outputs dan External Inquiries
Tujuan utama dari EO dan EQ adalah proses dasar dapat menyediakan informasi untuk user, gunakan aturan berikut untuk menentukan suatu proses termasuk external output atau external inquiry. Semua aturan harus terpenuhi untuk proses dasar yang akan dihitung:
Fungsi mengirim data atau control information dari luar ke dalam ruang lingkup aplikasi
Untuk proses pengidentifikasian, salah satu dari pernyataan berikut harus terpenuhi :
- Logika pemrosesan yang unidari pemrosesan yang dilakukan oleh EO atau EQ yang lain dari aplikasi
- Set dari data elemen diidentifikasikan berbeda dari set yang diidentifikasi untuk EO atau EQ yang lain
- Acuan ILF atau EIF berbeda dari file yang diacu oleh EO atau EQ lain pada aplikasi yang sama
Adapun tambahan aturan untuk External Output adalah, salah satu dari aturan berikut harus terpenuhi :
Logika pemrosesan dari proses dasar memuat setidaknya satu formula matematis atau penghitungan
Logika pemrosesan dari proses dasar menciptakan suatu data turunan Logika pemrosesan dari proses dasar memelihara setidaknya satu buah
ILF
Logika pemrosesan dari proses dasar mengubah perilaku system Dan aturan tambahan untuk External Inquiry adalah, semua aturan
berikut harus terpenuhi :
Logika pemrosesan dari proses dasar mengacu data atau control information dari ILF atau EIF
Logika pemrosesan dari proses dasar tidak memuat formula atau penghitungan secara matematis.
Logika pemrosesan dari proses dasar tidak memelihara ILF
Logika pemrosesan dari proses dasar tidak mengubah perilaku system
2.3.6.2 Kompleksitas dan Kontribusi Definisi dan Aturan
Jumlah EI, EO dan EQ beserta hubungan kompleksitasnya secara fungsional menentukan kontribusi dari transactional function untuk penghitungan unadjusted function point.
Kompleksitas untuk EI, EO dan EQ secara fungsional berdasarkan jumlah File Types Referenced (FTRs) dan Data Element Types (DET).
File Type Referenced (FTR)
FTR merupakan ILF yang dibaca atau dipelihara oleh transactional function atau EIF yang dibaca oleh transactional function.
Data Element Type (DET)
DET merupakan field unik yang dikenali oleh user
Aturan Kompleksitas dan Kontribusi untuk External Input Berikut aturan yang digunakan ketika menghitung FTR:
Hitung FTR untuk setiap ILF yang dipelihara
Hitung FTR untuk setiap ILF atau EIF yang dibaca selama pemrosesan external input
Hitung satu untuk setiap FTR untuk setiap ILF yang dibaca dan dipelihara
Berikut aturan yang digunakan ketika menghitung DET:
Hitung satu DET untuk setiap field unik yang dikenali oleh user, yang keluar atau masuk ke ruang lingkup aplikasi dan dibutuhkan untuk melengkapi external input.
Jangan menghitung field yang diambil atau diperoleh oleh system dan disimpan pada ILF selama proses dasar jika field tersebut tidak melewati ruang lingkup aplikasi.
Hitung satu DET untuk kemampuan mengirim pesan respon dari sistem diluar ruang lingkup aplikasi untuk menunjukkan adanya error selama pemrosesan.
Hitung satu DET untuk kemampuan menspesifikasikan aksi yang harus diambil meskipun ada lebih dari satu metode untuk proses logic yang sama.
Aturan Kompleksitas dan Kontribusi untuk EO/EQ
Aturan berikut digunakan ketika menghitung FTR untuk EO dan EQ:
Hitung satu FTR untuk setiap ILF atau EIF yang dibaca selama pemrosesan proses dasar
Hitung satu FTR untuk setiap ILF yang dipelihara selama pemrosesan proses dasar
Hitung satu FTR untuk setiap ILF yang dipelihara dan dibaca selama proses dasar
Aturan berikut digunakan ketika menghitung DET baik untuk EO dan EQ:
Hitung satu DET untuk setiap field unik yang memasuki ruang lingkup aplikasi dan dibutuhkan untuk menspesifikasikan kapan, apa dan/atau bagaimana data diambil atau dihasilkan oleh proses dasar.
Hitung satu DET untuk setiap field unik yang keluar dari ruang lingkup.
Jika kedua DET masuk dan keluar dari ruang lingkup, hitung hanya sekali untuk proses dasar.
Hitung satu DET untuk kemampuan menampilkan pesan error keluar dari ruang lingkup aplikasi.
Hitung satu DET untuk kemampuan menspesifikasikan aksi yang harus diambil jika terdapat lebih dari satu metode dalam satu proses yang sama.
Jangan hitung field yang diambil atau diperoleh oleh sistem dan disimpan pada ILF selama proses dasar jika field tersebut tidak melewati batasan aplikasi.
Jangan hitung variable paging.
Berikut adalah matriks kompleksitas untuk External Inputs Tabel 2.4 – Tabel matrik kompleksitas untuk EI
Dan berikut matriks kompleksitas untuk External Outputs dan External Inquiries
Tabel 2.5 – Tabel matrik kompleksitas untuk EO dan EQ
Gunakan table berikut untuk menilai kompleksitas EI atau EQ kedalam unadjusted function points
Tabel 2.6 – Tabel Unadjusted Function Point untuk EI dan EQ
Dan gunakan table berikut untuk menilai kompleksitas EO kedalam unadjusted function points
Tabel 2.7 – Tabel Unadjusted Function Point untuk EO
2.3.7 Value Adjustment Factor
Value Adjustment Factor (VAF) merupakan 14 karakteristik sistem umum yang menilai aplikasi yang sedang dihitung dari sisi fungsional secara umum. Setiap karakteristik memiliki deskripsi yang membantu menentukan tingkat pengaruh dari karakteristik tersebut. Tingkat pengaruh untuk setiap karakteristik berkisar pada skala 0 – 5, dari yang tidak memiliki pengaruh sama sekali sampai yang memiliki pengaruh kuat.
Karakteristik tersebut dirangkum kedalam Value Adjustment Factor. Ketika digunakan, VAF menambah perhitung point Unadjusted Function +/- 35 persen untuk membuat penghitungan adjusted function point.
Karakteristik Sistem Umum (General System Characteristic - GSCs) GSC dibagi kedalam 14 pertanyaan yang mengevaluasi keseluruhan kompleksitas aplikasi. 14 karakteristik tersebut adalah :
1. Komunikasi Data
2. Pemrosesan Data yang didistribusikan 3. Performa
4. Konfigurasi yang digunakan 5. Nilai Transaksi
6. Online Data Entry 7. Efisiensi End User 8. Online Update 9. Pemrosesan Kompleks 10. Reusability 11. Kemudahan Installasi 12. Kemudahan Operasional 13. Multiple Sites 14. Perubahan fasilitas Tingkat Pengaruh
Berdasarkan kebutuhan user yang ditetapkan, setiap GSC harus dievaluasi berdasarkan tingkat pengaruhnya pada skala nol sampai lima :
0 Tidak memiliki pengaruh 1 Berpengaruh sangat kecil 2 Berpengaruh sedang 3 Berpengaruh menengah
5 Sangat berpengaruh
Berikut panduan dari setiap deskripsi GSC berikut untuk menentukan tingkat pengaruh setiap point terhadap nilai dari aplikasi.
Komunikasi Data (Data Communications)
Komunikasi data menggambarkan tingkat suatu aplikasi untuk berkomunikasi secara langsung dengan prosesor.
Data dan control information yang digunakan pada aplikasi dikirim atau diterima melalui fasilitas komunikasi. Terminal yang terhubung ke suatu unit control secara local dipertimbangkan untuk menggunakan fasilitas komunikasi. Protocol merupakan suatu set konvensi yang memungkinkan transfer atau pergantian informasi antara dua sistem atau alat. Semua hubungan komunikasi data memerlukan suatu tipe protocol. Berikut penjelasan score yang diberikan pada point komunikasi data
Tabel 2.8 – Tabel Deskripsi Tingkat Pengaruh terhadap Aplikasi Nilai Deskripsi untuk Menentukan Tingkat Pengaruh terhadap
aplikasi
0 Aplikasi murni hanya berupa batch processing atau PC tunggal
1 Aplikasi berupa batch tapi memiliki remote data entry atau remote printing
2 Aplikasi memiliki batch tapi memiliki remote data entry dan remote printing
3 Aplikasi termasuk kumpulan data online atau TP (teleprocessing) front end pada proses batch atau sistem query
4 Aplikasi lebih dari front-end, tapi hanya memungkinkan untuk satu tipe protocol komunikasi TP
5 Aplikasi lebih dari front-end, dan memungkinkan lebih dari satu tipe protocol komunikasi TP
Pemrosesan Data yang Terdistribusi (Distributed Data Processing)
Pemrosesan Data yang Terdistribusi menggambarkan tingkat transfer data antara komponen pada suatu aplikasi. Data atau fungsi pemrosesan yang terdistribusi adalah karakteristika dari aplikasi yang masih termasuk di ruang lingkupnya.
Tabel 2.9 – Tabel Deskripsi Tingkat Pemrosesan Data
Nilai Deskripsi untuk Menentukan Tingkat Pemrosesan Data 0 Aplikasi tidak memperbaiki transfer data atau fungsi
pemrosesan antara komponen dari sistem
1 Aplikasi mempersiapkan data untuk pemrosesan oleh user pada komponen sistem lainnya
2 Data dipersiapkan untuk transfer, kemudian ditransfer dan diproses pada komponen lainnya
3 Pemrosesan yang terdistribusi dan data transfer dilakukan secara online dan hanya satu arah saja
4 Pemrosesan yang terdistribusi dan data transfer dilakukan secara online dan dua arah
5 Fungsi pemrosesan dilakukan secara dinamis pada komponen yang tepat di sistem tersebut
Performa (Performance)
Performa menggambarkan tingkat waktu respond dan pertimbangan performa yang mempengaruhi pengembangan aplikasi.
Tujuan performa aplikasi adalah, baik yang dinyatakan atau disetujui oleh user, baik dalam hal respon atau throughput, mempengaruhi (atau akan mempengaruhi) desain, pengembangan, instalasi, dan support dari aplikasi.
Tabel 2.10 – Tabel Deskripsi Tingkat Performa
0 Tidak ada permintaan kinerja khusus yang dinyatakan oleh user
1 Permintaan kinerja dan desain dinyatakan dan direview tapi tidak ada tindakan khusus yang diperlukan.
2 Waktu respon sangat kritis pada saat jam sibuk. Tidak ada desain khusus yang diperlukan untuk penggunaan CPU. 3 Waktu respom sangat kritis selama jam bisnis berjalan.
Tidak ada desain khusus yang diperlukan untuk penggunaan CPU. Memproses keperluan deadline dengan sistem antarmuka yang terbatas.
4 Sebagai tambahan, user performance requirement cukup ketat untuk dilakukan analisis pada fase desain
5 Sebagai tambahan, alat analisa kinerja digunakan pada tahap desain, pengembangan, dan/atau implementasi untuk memenuhi kebutuhan user.
Konfigurasi yang digunakan
Konfigurasi yang digunakan menggambarkan sejauh mana pembatasan sumber daya aplikasi mempengaruhi pengembangan aplikasi tersebut.
Konfigurasi oprasional yang digunakan, yang membutuhkan pertimbangan desain khusus, merupakan karakteristik dari aplikasi.
Tabel 2.11 – Tabel Deskripsi Tingkat Konfigurasi yang Digunakan Aplikasi
Nilai Deskripsi untuk Menentukan Tingkat Konfigurasi yang Digunakan Aplikasi
0 Tidak ada batasan operasional secara eksplisit atau implicit.
Tidak dibutuhkan usaha khusus untuk memenuhi batasan ini.
2 Diperlukan beberapa pertimbangan keamanan dan waktu. 3 Adanya kebutuhan prosesor tertentu untuk bagian spesifik
dari aplikasi.
4 Batasan operasional membutuhkan pembatasan khusus pada aplikasi di prosesor utama atau prosesor yang sudah ada.
5 Sebagai tambahan, ada batasan khusus pada aplikasi di bagian distribusi komponen pada sistem.
Rate Transaksi
Rate transaksi menggambarkan tingkat transaksi bisnis dapat mempengaruhi pengembangan aplikasi. Rate transaksi yang tinggi dapat mempengaruhi desain, pengembangan, instalasi, dan support pada aplikasi tersebut.
Tabel 2.12 – Tabel Deskripsi Tingkat Rate Transaksi Aplikasi Nilai Deskripsi untuk Menentukan Tingkat Rate Transaksi
Aplikasi
0 Tidak ada periode jam sibuk transaksi yang harus ditangani.
1 Adanya periode transaksi puncak (per bulan, per tahun) yang perlu ditangani
2 Periode transaksi puncak per minggu perlu untuk ditangani
3 Periode transaksi puncak per hari perlu untuk ditangani. 4 Adanya tingkat transaksi yang tinggi dinyatakan oleh
user pada requirement aplikasi atau persetujuan pada level service sehingga dibutuhkan analisa performance
pada fase desain.
5 Sebagai tambahan, diperlukan penggunaan alat analisa performance pada fase desain, pengembangan, dan/atau instalasi.
Online Data Entry
Online Data Entry menggambarkan tingkat data yang dimasukkan melalui transaksi yang interaktif.
Tabel 2.13 – Tabel Deskripsi Tingkat Online Data Entry
Nilai Deskripsi untuk Menentukan Tingkat Online Data Entry 0 1 2 3 4 5
Semua transaksi diproses dengan menggunakan batch 1% - 7% dari transaksi dimasukkan secara online. 8% - 15% dari transaksi dimasukkan secara online. 16% - 23% dari transaksi dimasukkan secara online. 24% - 30% dari transaksi dimasukkan secara online. Lebih dari 30% transaksi dimasukkan secara online.
Efisiensi End User
Efisiensi End User menggambarkan tingkat pertimbangan factor manusia dan kemudahan penggunaan bagi user dari aplikasi yang sedang diukur. Fungsi online menyediakan desain untuk efisiensi end-user, yaitu :
Bantuan navigasi Menu
Dokumen dan online helps
Pemindahan kursor secara otomatis Scrolling
Pencetakan melalui transaksi online Pre-assigned function keys
Pemilihan kursor dari data layar
Penggunaan video, highlighting, dan indikator lainnya Dokumentasi hard copy dari transaksi online
Mouse interface Pop-up windows
Layar yang digunakan untuk menyelesaikan kebutuhan bisnis
Adanya dukungan bilingual (mendukung dua bahasa; dihitung sebagai 4 item)
Adanya dukungan multilingual (mendukung lebih dari dua bahasa; dihitung sebagai 6 item)
Tabel 2.14 – Tabel Deskripsi Tingkat Efisiensi End User
Nilai Deskripsi untuk Menentukan Tingkat Efisiensi End User 0 Tidak ada satupun criteria yang disebutkan di atas
1 1 – 3 dari criteria di atas 2 4 – 5 dari criteria di atas
3 6 atau lebih dari criteria di atas, tetapi tidak ada permintaan user yang berkaitan dengan efisiensi
4 6 atau lebih dari criteria di atas, ada permintaan khusus mengenai efisiensi dari user yang berhubungan dengan factor manusia (contoh, penggunaan template)
5 6 atau lebih dari criteria di atas, ada permintaan user yang berkaitan dengan efisiensi dan membutuhkan alat dan proses khusus untuk menunjukkan tujuan tersebut telah tercapai.
Online Update
Online Update menggambarkan tingkat Internal Logical Files yang di update secara online.
Tabel 2.15 – Tabel Deskripsi Tingkat Online Update
Nilai Deskripsi untuk Menentukan Tingkat Online Update pada Aplikasi
0 Tidak ada
1 Terdapat satu sampai 3 file yang di update secara online. Volume update rendah dan recovery nya mudah
2 Terdapat empat file atau lebih yang di update secara online. Volume update rendah dan recovery nya mudah 3 Terdapat Internal Logical Files besar yang di update
secara online.
4 Sebagai tambahan, pentingnya perlindungan terhadap kehilangan data dan didesain secara khusus dan terprogram didalam sistem.
5 Sebagai tambahan, volume yang tinggi berpengaruh terhadap pertimbangan biaya kedalam proses. Prosedur recovery dengan intervensi operator yang minimum.
Kompleksitas Pemrosesan
Kompleksitas pemrosesan menggambarkan tingkat logika pemrosesan dalam mempengaruhi development dari aplikasi.
Berikut adalah komponen yang dinilai : Sensitive control
Ekstensif pemrosesan logika Ekstensif pemrosesan matematika
Banyaknya exception pemrosesan yang dihasilkan dari transaksi yang belum sempurna
Kompleksitas pemrosesan untuk menangani kemungkinan input/output
Tabel 2.16 – Tabel Deskripsi Tingkat Kompleksitas Pemrosesan Nilai Deskripsi untuk Menentukan Kompleksitas Pemrosesan
0 1 2 3 4 5 Tidak ada
Salah satu dari daftar di atas Dua poin dari daftar di atas Tiga poin dari daftar di atas Empat poin dari daftar di atas. Lima poin dari daftar di atas.
Penggunaan Ulang
Penggunaan ulang mendeskripsikan sejauh mana aplikasi dan kode aplikasi tersebut telah didesain, dikembangkan, dan didukung agar dapat digunakan pada aplikasi yang lain.
Tabel 2.17 – Tabel Deskripsi Tingkat Penggunaan Ulang
Nilai Deskripsi untuk Menentukan Tingkat Penggunaan Ulang 0 Tidak ada kode yang dapat digunakan ulang
1 Kode dapat digunakan kembali pada aplikasi yang sama 2 Kurang dari 10% dari aplikasi dipertimbangkan untuk
keperluan lebih dari 1 user
3 10% atau lebih dari aplikasi dipertimbangkan untuk keperluan lebih dari 1 user
4 Aplikasi dibuat dan/atau didokumentasikan secara spesifik untuk kemudahan penggunaan kembali, dan aplikasi dapat diubah oleh pengguna pada tingkat source code nya.
5 Aplikasi dibuat dan/atau didokumentasikan secara spesifik untuk kemudahan penggunaan kembali, dan aplikasi dapat diubah dari tingkat user parameter maintenance.
Kemudahan Instalasi
Kemudahan instalasi menggambarkan tingkat konversi dari lingkungan sebelumnya dapat mempengaruhi pengembangan aplikasi.
Kemudahan konversi dan instalasi merupakan karakter dari suatu aplikasi. Rencana dan/atau alat konversi dan instalasi disediakan dan di tes selama fase tes sistem.
Tabel 2.18 – Tabel Deskripsi Tingkat Kemudahan Instalasi Nilai Deskripsi untuk Menentukan Tingkat Kemudahan
Instalasi
0 Tidak ada pertimbangan khusus yang dinyatakan oleh pengguna, dan tidak ada setup khusus yang dibutuhkan untuk instalasi
1 Tidak ada pertimbangan khusus yang dinyatakan oleh pengguna, tetapi dibutuhkan setup khusus untuk instalasi 2 Kebutuhan konversi dan instalasi dijelaskan oleh user,
dan panduan keduanya disediakan dan diuji. Pengaruh konversi pada proyek tidak terlalu penting.
3 Kebutuhan konversi dan instalasi dijelaskan oleh user, dan panduan keduanya disediakan dan diuji. Pengaruh konversi pada proyek dipentingkan.
4 Tambahan untuk 2 poin diatas, automasi konversi dan instalasi disediakan dan diuji.
5 Tambahan untuk 3 poin diatas, automasi konversi dan instalasi disediakan dan diuji.
Kemudahan Operasional
Kemudahan operasional menggambarkan tingkat kemudahan aspek operasional seperti start-up, back-up, dan proses recovery.
Tabel 2.19 – Tabel Deskripsi Tingkat Kemudahan Operasional Nilai Deskripsi untuk Menentukan Tingkat Kemudahan
Instalasi
0 Tidak ada pertimbangan operasional khusus selain prosedur back-up normal
1-4 Satu, beberapa, atau seluruh poin berikut terdapat pada aplikasi:
Terdapat proses start-up, back-up dan recovery yang efektif, tapi dibutuhkan operator
Terdapat proses start-up, back-up dan recovery yang efektif, tidak dibutuhkan operator
Aplikasi dapat meminimalisir kebutuhan tape mounts
Aplikasi dapat meminimalisir kebutuhan kertas Aplikasi didesain untuk operasi yang tidak membutuhkan operator untuk menjalankan sistem kecuali untuk menyalakan atau mematikan aplikasi.
5 Error recovery secara otomatis merupakan fitur dari aplikasi
Multiple Sites
Multiple Sites merupakan tingkat sejauh mana aplikasi dikembangkan untuk lokasi dan organisasi pengguna dengan jumlah lebih dari satu.
Aplikasi telah didesain, dikembangkan dan didukung untuk diinstal pada tempat dan organisasi pengguna yang berbeda-beda.
Tabel 2.20 – Tabel Deskripsi Tingkat Multiple Sites Nilai Deskripsi untuk Menentukan Multiple Sites
0 User requirement tidak memerlukan pertimbangan kebutuhan instalasi lebih dari satu tempat
1 Kebutuhan multiple site dipertimbangkan pada desain dan aplikasi didesain untuk beroperasi hanya pada lingkungan hardware dan software yang sama
2 Kebutuhan multiple site dipertimbangkan pada desain dan aplikasi didesain untuk beroperasi hanya pada lingkungan hardware dan software yang mirip
3 Kebutuhan multiple site dipertimbangkan pada desain dan aplikasi didesain untuk beroperasi hanya pada lingkungan hardware dan software yang berbeda
4 Terdapat rencana dokumentasi dan support untuk mendukung aplikasi pada tempat yang berbeda dan aplikasi dideskripsikan seperti pada point 1 atau 2
5 Terdapat rencana dokumentasi dan support untuk mendukung aplikasi pada tempat yang berbeda dan aplikasi dideskripsikan seperti pada point 3
Fasilitasi Perubahan
Fasilitasi perubahan menggambarkan tingkat sejauh mana aplikasi dikembangkan untuk kemudahan modifikasi pemrosesan logika atau struktur data.
Karakteristik berikut dapat digunakan untuk aplikasi :
Disediakan query dan report yang fleksibel dan dapat menangani permintaan sederhana, contoh logic and/or pada satu ILF (dihitung 1 poin)
Disediakan query dan report yang fleksibel dan dapat menangani permintaan dengan kompleksitas menengah, contoh logic and/or untuk lebih dari satu ILF (dihitung 2 poin)
Disediakan query dan report yang fleksibel dan dapat menangani permintaan yang sulit, contoh logic and/or pada satu atau lebih ILF (dihitung 3 poin)
Business control data disimpan pada table yang diawasi oleh pengguna dengan proses online yang interaktif, tapi hasil perubahan efektif pada hari berikutnya (dihitung 1 poin)
Business control data disimpan pada table yang diawasi oleh pengguna dengan proses online yang interaktif, tapi hasil perubahan secepatnya (dihitung 2 poin)
Tabel 2.21 – Tabel Deskripsi Tingkat Fasilitasi Perubahan Aplikasi Nilai Deskripsi untuk Menentukan Tingkat Fasilitasi
Perubahan 0 1 2 3 4 5 Tidak ada
Total satu poin dari daftar di atas Total dua poin dari daftar di atas Total tiga poin dari daftar di atas Total empat poin dari daftar di atas Total lima poin dari daftar di atas
2.3.8 Struktur Model-Model Estimasi
Model estimasi diperoleh melalui analisis regresi pada data yang diperoleh
pada proyek-proyek di masa lalu. Keseluruhan struktur dari beberapa model mengambil dari persamaan yang dipaparkan oleh Matson [Matson, 1994]: E = A + B x (ev)C (2-3)
dimana E adalah effort dalam orang-bulan, dan A, B, C adalah konstanta yang diperoleh secara empiris. Dalam perkembangannya persamaan tersebut dikembangkan sesuai dengan proyek yang dikerjakan oleh masing-masing pengembang perangkat lunak. Perbedaan persamaan yang digunakan oleh masing-masing pengembang dikarenakan persamaan tersebut harus dikalibrasi terlebih dahulu, sesuai dengan kondisi maupun kebutuhan.
E = -13,39 + 0,0545 FP Albercht dan Gaffney Model E = 60,62 x 7,728 x 10-8FP3 Kemerer Model
E = 585,7 + 15,12 FP Matson, Barnett, dan Mellichamp Berdasarkan penelitian yang dilakukan oleh Henderson mengenai keterkaitan antara pendekatan Function Point dan Source Line of Code (SLOC), disimpulkan bahwa untuk model Albrect dan Gaffney memiliki keterkaitan yang kuat dengan perhitungan SLOC, sehingga biasanya cocok digunakan untuk aplikasi yang memiliki tingkat teknikal cukup sulit.
Sementara untuk model Kemerer, selain memiliki keterkaitan dengan SLOC, model ini juga memiliki keterkaitan yang kuat dari sisi bisnis atau fungsional. Karena itu, model ini cocok digunakan untuk aplikasi yang memiliki sisi fungsional yang cukup banyak.
Dan untuk model Mason, Barnet, dan Mellichamp, model ini mempertimbangkan kombinasi linear dari lima komponen dasar Function Point. Namun, user interface dari aplikasi tidak dihitung secara terpisah tetapi sebagai bagian dari file master. Dan hanya menggunakan satu level kompleksitas sehingga adjustment factor yang dihasilkan hanya memiliki range ± 25%.
2.4 UNIFIED MODELLING LANGUAGE (UML)
UML adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented).
Berikut ini penjelasan singkat mengenai diagram-diagram yang digunakan dalam dokumen ini (Larman, 2005):
Use Case diagram adalah deskrpisi dari fungsionalitas yang dimiliki oleh sistem dan terdiri dari use case - use case, actor beserta hubungan interaksinya. Penjelasan dari use case biasanya dibuat dalam bentuk teks sederhana yang digunakan sebagai dokumentasi pada suatu simbol use case, tetapi bisa juga digambarkan dengan menggunakan activity diagram. Use case digambarkan sebagai suatu cara pandang terhadap sistem dilihat dari perspektif actor (pelaku terhadap sistem atau user).
Use case diartikan sebagai deskripsi dari sekumpulan aksi yang berurutan sebagai akibat dari interaksinya dengan actor. Penggambaran Use case adalah sebagai berikut :
Gambar 2.3 Use Case
Aktor merupakan representasi dari pengguna sistem yang berada diluar sistem dan berinteraksi dengan use case serta tidak mempunyai kontrol terhadap use case tersebut. Penggambaran aktor adalah sebagai berikut :
Gambar 2.4 Aktor
Activity diagram
Menyajikan workflow komponen dalam sistem. Activity diagram menunjukkan flow of control secara keseluruhan.
Simbol yang digunakan dalam activity diagram adalah : Aktifitas digambarkan dengan kotak
If (keputusan) digambarkan dengan belah ketupat
Fork/Join digunakan sebuah transisi yang masuk dan dua buah transisi atau aliran objek paralel sebagai keluaran.
Garis yang menghubungkan aktifitas menggambaran aliran objek Keadaan akhir digambarkan dengan lingkaran yang memiliki titik
hitam ditengahnya.
2.5 DUAL CURRENCY INVESTMENT (DCI)
Dual Currency Investment atau Dual Currency Deposit adalah suatu deposito jangka pendek yang dihubungkan dengan pergerakan pasar mata uang yang dapat memberikan pendapatan bunga yang lebih tinggi dibandingkan deposito biasa.
Dual Currency Deposit ditawarkan sebagai deposito dengan mata
uang pasangan dan Anda akan menerima pokok dan bunga dalam mata uang penempatan deposito ATAU pokok dan bunga dalam mata uang terkait, tergantung mana yang lebih lemah, dengan nilai tukar yang telah ditentukan sebelumnya.
DCD memberikan suku bunga yang tetap hingga saat jatuh tempo. Selain itu, besarnya suku bunga juga lebih besar dari suku bunga deposito biasa. DCD merupakan deposito dengan masa jatuh tempo 1 sampai 12 bulan. Meskipun DCD memberikan imbal hasil yang cukup tinggi, namun berinvestasi dalam DCD tetap beresiko. Resikonya adalah nasabah berpotensi menerima mata uang pengganti yang melemah terhadap mata uang asal, sehingga memungkinkan pokok deposito berkurang (unprotected principal).
Namun, kunci keberhasilan terletak pada ekspektasi nasabah terhadap ekspektasi melemahnya suatu mata uang terhadap mata uang lainnya. Misalnya, karena saat ini US Dollar diprediksi melemah terhadap Rupiah,
maka pilihlah US Dollar sebagai mata uang asal dan Rupiah sebagai mata uang pengganti.
DCD tidak dapat dicairkan sebelum masa jatuh tempo, demikian halnya dengan bunga, juga dibayarkan pada saat jatuh tempo. Sementara itu, penentuan penerimaan dalam mata uang asal atau pengganti adalah 2 hari kerja sebelum jatuh waktu DCD.
Berikut adalah simulasi transaki DCD :
Misalkan, pada tanggal 1 November 2006, seorang nasabah bernama PT Mujur mempunyai cadangan US Dollar sebesar $100.000 dari hasil ekspornya. Karena melihat US Dollar tidak mempunyai fundamental yang kuat serta memiliki kecenderung melemah terhadap Rupiah, PT Mujur menyimpan dananya dalam bentuk DCD untuk jangka waktu 1 bulan, maka transaksinya adalah.
Mata Uang Asal : US Dollar (USD) Mata Uang Pengganti : IDR
Penempatan Dana : USD 100.000,- Tanggal Efektif : 1 November 2006 Tanggal Jatuh Tempo : 1 Desember 2006 Bunga Deposito : 9.75% p.a
Bunga Premi : 1% p.a Kurs USD/IDR (spot) : 9150 Kurs Konversi : 9200 (strike price)
Tanggal Eksekusi : 29 November 2006, dengan batas waktu jam 13.00 WIB
Pada saat jatuh tempo (1 Desember), total imbal hasil yang akan diterima PT Mujur = USD 100.000 x (9.75+1)% x 30/365 = USD 883.56. karena selama masa observasi (1 November hingga 29 November) US Dollar tidak
pernah menyentuh level 9200 (strike price), maka PT Mujur akan menerima = USD 100.000 + USD 883.56 = $100.883,56
Namun, apabila selama masa observasi US Dollar sempat menyentuh level 9200, maka PT Mujur menerima dalam mata uang pengganti yakni : USD 100.883,56 x 9200 = IDR 928.128.752,-. PT Mujur berpotensi mendapatkan kerugian apabila USD/IDR pada saat eksekusi lebih besar dari harga konversi (strike price).
Pemahaman mengenai pergerakan suatu mata uang menjadi sangat penting karenanya. Lama jatuh tempo yang akan dipilih nasabah akan sangat mempengaruhi bunga premi maupun deposito, namun, semakin lama jatuh tempo yang ditentukan maka semakin besar pula resiko yang akan diterima.
