GENERAL SYSTEM CHARACTERICTICS UNTUK ESTIMASI BIAYA ...

TESIS – KS142501

MODIFIKASI METODE FUNCTION POINT DENGAN

MENAMBAHKAN KOMPLEKSITAS PROSES BISNIS PADA

GENERAL SYSTEM CHARACTERICTICS UNTUK

ESTIMASI BIAYA PERANGKAT LUNAK

ANGGI YHURINDA PERDANA PUTRI

NRP. 05211650010012

DOSEN PEMBIMBING

Dr. Apol Pribadi Subriadi, S.T., M.T.

NIP. 197002252009121001

PROGRAM MAGISTER

DEPARTEMEN SISTEM INFORMASI

FAKULTAS TEKNOLOGI INFORMASI DAN KOMUNIKASI

INSTITUT TEKNOLOGI SEPULUH NOPEMBER

SURABAYA

2018

(Halaman ini sengaja dikosongkan)

THESIS – KS142501

MODIFICATION OF FUNCTION POINT METHOD BY

ADDING BUSINESS PROCESS COMPLEXITY ON GENERAL

SYSTEM CHARACTERISTICS FOR SOFTWARE COST

ESTIMATION

ANGGI YHURINDA PERDANA PUTRI

NRP. 05211650010012

DOSEN PEMBIMBING

Dr. Apol Pribadi Subriadi, S.T., M.T.

NIP. 197002252009121001

POSTGRADUATE PROGRAM

DEPARTMENT OF INFORMATION SYSTEMS

FACULTY OF INFORMATION AND COMMUNICATION TECHNOLOGY

INSTITUT TEKNOLOGI SEPULUH NOPEMBER

SURABAYA

2018

ii


iii

LEMBAR PENGESAHAN

iv


v

MODIFIKASI METODE FUNCTION POINT DENGAN MENAMBAHKAN

KOMPLEKSITAS PROSES BISNIS PADA GENERAL SYSTEM

CHARACTERICTICS UNTUK ESTIMASI BIAYA PERANGKAT LUNAK

Nama Mahasiswa : Anggi Yhurinda Perdana Putri

NRP : 05211650010012

Pembimbing : Dr. Apol Pribadi Subriadi S.T., M.T.

ABSTRAK

Metode Function Point (FPA) merupakan metode pengukuran sekaligus

satuan ukuran untuk perangkat lunak seperti jam untuk mengukur waktu, mil

untuk mengukur jarak, atau Celcius untuk mengukur suhu. Function Point

mengukur perangkat lunak dengan mengkuantifikasi fungionalitas perangkat

lunak yang disediakan untuk pengguna berdasarkan design logic. Pengukurannya

terdiri dari beberapa langkah yaitu menghitung Unadjusted Function Point (UFP),

Value Adjustment Factor (VAF), Adjusted Function Point (AFP) dan menghitung

biaya perangkat lunaknya. Namun, pada scoring level kompleksitas pada

ditentukan secara subyektif oleh pakar, pendekatan ini menjadi tidak akurat

karena dipengaruhi oleh emosi. Selain itu, proses bisnis suatu organisasi berbeda

satu dengan yang lain, begitu pula kompleksitas proses bisnisnya. Perbedaan

kompleksitas proses bisnis mempengaruhi ukuran dari perangkat lunak yang

dikembangkan.

Penulis bermaksud memodifikasi faktor kompleksitas dalam metode FPA

dengan menambahkan kompleksitas proses bisnis dalam 14 faktor kompleksitas.

Pendekatan Cyclomatic Complexity digunakan untuk mengukur kompleksitas

secara obyektif agar menghindari subyektifitas. Sedangkan dalam menentukan

kompleksitas proses bisnis, peneliti menggunakan BPMN (Business Prosess

Modelling Notation) sebagai metric dalam menentukan kompleksitanya dan

mengukurnya menggunakan Cyclomatic Complexity. Output dari modifikasi FPA

ini berupa biaya pengembangan perangkat lunak yang akan dibandingkan dengan

vi

perhitungan FPA sebelum dimodifikasi. Proyek perangkat lunak yang menjadi

obyek dalam penelitian ini yaitu empat proyek perijinan dari pemerintah daerah.

Nilai estimasi total biaya keempat proyek dengan menggunakan metode Function

point dan modified function point yaitu masing-masing senilai Rp. 216.956.881

dan Rp. 220.370.829. Hasil dari estimasi biaya ini dapat digunakan pengembang

dalam menentukan harga pokok perangkat lunak yang akan dibangun.

Kata Kunci: Pengukuran Perangkat Lunak, Estimasi Biaya Perangkat Lunak,

Function Point Analysis, Modifikasi Function Point, Kompleksitas Proses Bisnis

vii

MODIFICATION OF FUNCTION POINT METHOD BY ADDING

BUSINESS PROCESS COMPLEXITY ON GENERAL SYSTEM

CHARACTERICTICS FOR SOFTWARE COST ESTIMATION

Nama Mahasiswa : Anggi Yhurinda Perdana Putri

NRP : 05211650010012

Pembimbing : Dr. Apol Pribadi Subriadi S.T., M.T.

ABSTRACT

The Function Point (FPA) method is a measurement method as well as a

unit of measure for software such as a clock to measure time, miles to measure

distances, or Celsius to measure temperature. Function Point measures the

software by quantifying the software functionality provided to users based on

design logic. The measurement consists of several steps: calculate Unadjusted

Function Point (UFP), Value Adjustment Factor (VAF), Adjusted Function Point

(AFP) and calculate the cost of the software. However, at the scoring level of

complexity determined subjectively by the expert, this approach becomes

inaccurate because it is influenced by emotion. In addition, the business processes

of an organization differ from one another, as well as the complexity of its

business processes. The complexity of business processes affects the size of the

software developed.

The author intends to modify the complexity factor in the FPA method by

adding the complexity of business processes in 14 factors of complexity. The

Cyclomatic Complexity approach is used to measure complexity objectively in

order to avoid subjectivity. While in determining the complexity of business

processes, researchers use BPMN (Business Prosess Modeling Notation) as a

metric in determining the complexity and measuring it using Cyclomatic

Complexity. The output of this FPA modification is the cost of software

development that will be compared with the FPA calculation before it is modified.

The software project that became the object of this research are four licensing

viii

projects from local government. The estimated total cost value of the four projects

using the Function point and modified function point method is Rp. 216.956.881

and Rp. 220.370.829. The results of this cost estimation can be used developers in

determining the cost of software to be built.

Kata Kunci: Software Estimation, Software Cost Estimation, Function Point

Analysis, Mofidication of Function Point, Business Process Complexity

ix

KATA PENGANTAR

Puji syukur penulis panjatkan kepada Allah SWT, yang telah memberikan

Ridho, Rahmat, dan Hidayah-Nya sehingga Tesis yang berjudul “Modifikasi

Metode Function Point dengan Menambahkan Kompleksitas Proses Bisnis pada

General System Characteristics untuk Estimasi Biaya Perangkat Lunak” dapat

disusun dengan baik. Tesis ini disusun sebagai salah satu syarat menyelesaikan

pendidikan pada Program Magister Sistem Informasi, Jurusan Sistem Informasi,

Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember.

Dalam proses penyelesaian tesis ini, penulis mendapatkan banyak bantuan, baik

bantuan moral maupun materiil dari berbagai pihak. Oleh karena itu, penulis

mengucapkan banyak terimakasih kepada :

1. Orang tua tercinta penulis, Panut Widodo dan Hariyati Luluk Fariqoh,

S.H., yang selalu memberikan kasih sayang, motivasi, doa dan dukungan

penuh baik secara moril maupun materiil kepada penulis selama

menempuh pendidikan magister serta penyelesaian studi Tesis ini.

2. Adik-adik tercinta penulis Yitha Kartika Devy dan Finska Ayhu Dyitha

yang telah memberikan semangat, doa, dan dukungan dari awal hingga

akhir pengerjaan Tesis ini.

3. Bapak Dr. Apol Pribadi Subriadi, S. T., M. T., selaku dosen pembimbing

dan Dosen Wali Akademik yang telah meluangkan waktu, tenaga dan

pikiran, serta memberikan ilmu, dukungan, dan kesabaran selama

membimbing penulis dari awal hingga tesis ini selesai.

4. Bapak Sholiq, ST., M. Kom., selaku Dosen Pembimbing kedua yang telah

bersedia dan memberikan masukan serta ilmunya untuk penelitian ini.

5. Ibu Nur Aini Rakhmawati, S. Kom., M.Sc.Eng., Ph.D. selaku Dosen

Penguji I yang telah bersedia menguji dan memberikan masukan untuk

penelitian ini.

6. Bapak Faizal Mahananto, S. Kom., M. Eng., Ph.D., selaku Dosen Penguji

II yang telah bersedia menguji dan memberikan masukan untuk penelitian

ini.

x

7. Bapak Faturrahman, S. Kom yang bersedia menjadi informan serta berbagi

ilmunya untuk mendukung penelitian ini.

8. Bapak H. Juli Hariyanto yang telah memberikan dukungan materiil dan

moril kepada penulis dalam menempuh studi magister.

9. Bapak Yadi, S.H. dan Ibu Lies Setyawati yang telah memberikan

dukungan kepada penulis selama menempuh studi magister

10. Teman terbaik saya, Adhitya Wiratama S. Kom yang selalu memberikan

doa serta dukungan selama menempuh studi magister dan penyelesian

studi tesis ini.

11. Bapak dan Ibu dosen yang telah mendidik serta memberikan ilmu selama

Penulis menempuh pendidikan di Jurusan Sistem Informasi, Fakultas

Teknologi Informasi, Institut Teknologi Sepuluh Nopember.

12. Segenap staf dan karyawan di Jurusan Sistem Informasi, Fakultas

Teknologi Informasi, Institut Teknologi Sepuluh Nopember yang

membantu Penulis dalam pelaksanaan tesis ini. Khususnya mbak Vian

yang telah banyak membantu penulis dalam melancarkan administrasi baik

tesis maupun selama penulis menempuh studi magister.

13. Rindu Puspita Wibawa, Litafira Syahadiyanti, Amaliah Faradibah, Vicha

Azthanty Supoyo, Luqman, Maya, Septama, Gati, Tami, Nina, Fandhi

serta sahabat dan teman-teman keluarga besar S2 Sistem Informasi ITS

yang selalu memberikan semangat, dukungan, dan kebersamaan selama

Penulis menempuh pendidikan magister.

14. Segenap keluarga besar In Wedding Organizer, khususnya mas Ain yang

selalu memberikan semangat, dukungan, dan doa dalam penyelesaian tesis

ini.

15. Semua pihak yang tidak dapat disebutkan satu per satu, yang telah

membantu dan terlibat baik secara langsung maupun tidak langsung dalam

penulisan tesis ini.

Penulis menyadari bahwa tesis ini tidak lepas dari kesalahan dan kekurangan,

serta masih sangat jauh dari kata sempurna. Oleh karena itu, Penulis bersedia

menerima kritik dan saran yang membangun untuk memperbaiki diri. Penulis

xi

berharap tesis ini dapat memberi manfaat bagi kemajuan dunia pendidikan di

Indonesia.

Surabaya, Juli 2018

Anggi Yhurinda Perdana Putri

xii


xiii

DAFTAR ISI

LEMBAR PENGESAHAN ................................................................................... iii

ABSTRAK .............................................................................................................. v

ABSTRACT .......................................................................................................... vii

KATA PENGANTAR ........................................................................................... ix

DAFTAR ISI ........................................................................................................ xiii

DAFTAR GAMBAR .......................................................................................... xvii

DAFTAR TABEL ................................................................................................ xix

BAB I PENDAHULUAN ...................................................................................... 1

1.1 Latar Belakang ......................................................................................... 1

1.2 Rumusan Masalah .................................................................................... 5

1.3 Tujuan ....................................................................................................... 5

1.4 Lingkup Penelitian ................................................................................... 5

1.5 Kontribusi Penelitian .................................................................................... 5

1.5.1 Kontribusi Bidang Keilmuan ................................................................. 5

1.5.2 Kontribusi Praktis .................................................................................. 6

1.6 Sistematika Penulisan ................................................................................... 6

BAB II TINJAUAN PUSTAKA ........................................................................... 7

2.1 Kajian Teori .................................................................................................. 7

2.1.1 Pengukuran Perangkat Lunak ................................................................ 7

2.1.2 Function Point Analysis (FPA) .............................................................. 9

2.1.3 Estimasi Biaya Perangkat Lunak ......................................................... 35

2.1.4 Proses Bisnis ........................................................................................ 38

2.1.5 Metric Kompleksitas ............................................................................ 51

xiv

2.1.6 Cyclomatic ........................................................................................... 52

2.2 Kajian Penelitian Terdahulu........................................................................ 53

2.3 Profil Perusahaan .................................................................................... 57

2.3.1 Visi Misi Perusahaan ........................................................................... 58

BAB III METODE PENELITIAN ....................................................................... 59

3.1 Tahapan Penelitian ................................................................................. 59

3.1.1 Identifikasi Topik Penelitian ........................................................... 60

3.1.2 Studi Literatur ................................................................................. 60

3.1.3 Penyusunan Latar Belakang, Rumusan Masalah, Tujuan, dan

Batasan Penelitian ......................................................................................... 60

3.1.4 Rancangan Sistematika Metode Penelitian ..................................... 61

3.1.5 Rancangan Konseptual Model ............................................................. 62

3.1.6 Teknik Pengumpulan Data ................................................................... 62

3.1.7 Analisis Data ........................................................................................ 63

3.1.8 Implementasi ........................................................................................ 67

3.1.9 Pengujian ......................................................................................... 67

3.1.10 Hasil Penelitian ............................................................................... 67

3.1.11 Penyusunan Kesimpulan dan Saran ................................................ 67

3.2 Manualisasi ............................................................................................. 67

3.2.1 Perhitungan Function Point ............................................................ 68

3.2.2 Perhitungan Modified Function Point ............................................. 71

3.2.3 Estimasi Biaya ................................................................................ 77

3.3 Timeline Penelitian ................................................................................ 82

BAB IV KONSEPTUAL MODEL ....................................................................... 83

4.1 Konseptual Model .................................................................................. 83

xv

4.2 Function Point ........................................................................................ 84

4.3 Kompleksitas Proses Bisnis ................................................................... 85

4.4 Estimasi Harga ....................................................................................... 85

4.5 Pengujian ................................................................................................ 87

BAB V HASIL DAN PEMBAHASAN ............................................................... 89

5.1 Function Point ............................................................................................. 89

5.1.1 Perhitungan Unadjusted Function Point .............................................. 89

5.1.2 Perhitungan Total Degree Influences (TDI) ........................................ 90

5.1.3 Perhitungan Nilai AFP ......................................................................... 90

5.2 Modified Function Point ............................................................................. 91

5.2.1 Mengkonversi Nilai Kompleksitas Proses Bisnis ................................ 92

5.2.2 Menghitung Modified Function Point ................................................. 93

5.3 Estimasi Biaya ............................................................................................ 96

5.3.1 Nilai Effort ........................................................................................... 96

5.3.2 Nilai Effort per aktivitas ....................................................................... 97

5.3.3 Pay Rate per Position ........................................................................... 98

5.3.4 Cost per Aktivitas ................................................................................ 99

5.4 Estimasi Biaya Hasil Modifikasi .............................................................. 100

5.4.1 Nilai Effort Hasil Modifikasi ............................................................. 100

5.4.2 Nilai Effort per aktivitas hasil modifikasi .......................................... 100

5.4.3 Cost per Aktivitas hasil modifikasi .................................................... 101

5.5 Evaluasi Gap Biaya ................................................................................... 103

BAB VI PENUTUP ............................................................................................ 107

6.1 Kesimpulan ............................................................................................... 107

6.2 Saran ......................................................................................................... 108

xvi

DAFTAR PUSTAKA ......................................................................................... 109

LAMPIRAN A: DATA UNTUK FUNCTION POINT ...................................... 115

A.1 Data EI, EO, EQ ....................................................................................... 115

A.2 Data ILF dan EIF ..................................................................................... 121

A.3 Pembobotan pada EI, EO, dan EQ ........................................................... 123

A.4 Pembobotan ILF dan EIF ......................................................................... 132

A.5 Total Degree Influence ............................................................................. 134

A.6 Unadjusted Function Point ....................................................................... 138

A.7 Nilai Adjusted Function Point (AFP) ....................................................... 140

LAMPIRAN B: KOMPLEKSITAS PROSES BISNIS ...................................... 141

B.1 Proses Bisnis ............................................................................................ 141

BIOGRAFI PENULIS ........................................................................................ 147

xvii

DAFTAR GAMBAR

Gambar 1. 1 Statistik proyek yang dikerjakan dengan dan tanpa Function Point .. .2

Gambar 2.1 Perangkat Lunak dari Sudut Pandang Pengguna……….……………9

Gambar 2. 2 Tahap Perhitungan Function Point. .................................................. 13

Gambar 2. 3 External Output ................................................................................. 16

Gambar 2. 4 External Inquiries ............................................................................ 17

Gambar 2. 5 Transformasi diagram ke graph ........................................................ 55

Gambar 3. 1 Tahapan Penelitian ............................................................................ 59

Gambar 3. 2 Sistematika Metode Penelitian .......................................................... 61

Gambar 3. 3 Manualisasi Proses Bisnis Login ...................................................... 72

Gambar 4. 1 Konseptual Model ............................................................................ 83

Gambar 5. 1 Grafik Perbandingan Actual Cost dengan Function Point………..103

Gambar 5. 2 Grafik Perbandingan Function Point dan Modified FPA ................ 105

xviii


xix

DAFTAR TABEL

Tabel 2. 1 FTR dan DET EI ................................................................................... 15

Tabel 2. 2 FTR dan DET EO ................................................................................. 16

Tabel 2. 3 RET dan DET ILF ................................................................................ 18

Tabel 2. 4 RET dan DET EIF ................................................................................ 19

Tabel 2. 5 General System Characteristic ............................................................. 20

Tabel 2. 6 Degree of influence dari data communication ...................................... 21

Tabel 2. 7 Degree of influence dari Distributed data processing .......................... 22

Tabel 2. 8 Degree of influence dari performance .................................................. 23

Tabel 2. 9 Degree of influence dari heavily used configuration ............................ 24

Tabel 2. 10 Degree of influence dari transaction rate ........................................... 25

Tabel 2. 11 Degree of influence dari online data entry ......................................... 25

Tabel 2. 12 Degree of influence dari enduser efficiency ........................................ 26

Tabel 2. 13 Degree of influence dari online update ............................................... 27

Tabel 2. 14 Degree of influence dari complex processing ..................................... 28

Tabel 2. 15 Degree of influence dari reusability .................................................... 29

Tabel 2. 16 Degree of influence dari installation ease .......................................... 29

Tabel 2. 17 Degree of influence dari operational ease .......................................... 30

Tabel 2. 18 Degree of influence dari multiple sites................................................ 31

Tabel 2. 19 Degree of influence dari facilitate change .......................................... 33

Tabel 2. 20 Unadjusted Function Point (UFP) ...................................................... 34

Tabel 2. 21 Total Degree Influence (TDI) ............................................................. 34

Tabel 2. 22 Persentase Effort per Aktivitas ........................................................... 36

Tabel 2. 23 Task Description ................................................................................. 40

Tabel 2. 24 Flow Description ................................................................................ 41

Tabel 2. 25 Marker Description ............................................................................. 42

Tabel 2. 26 Data Object Description ..................................................................... 43

Tabel 2. 27 Event Description ............................................................................... 44

Tabel 2. 28 Gateaway Description ........................................................................ 49

Tabel 3. 1 Daftar Proyek Pengembangan Perangkat Lunak .................................. 63

xx

Tabel 3. 2 Nilai Proyek Perangkat Lunak .............................................................. 65

Tabel 3. 3 Data Personil Perusahaan ...................................................................... 65

Tabel 3. 4 Standar Gaji .......................................................................................... 66

Tabel 3. 5 Manualisasi UFP ................................................................................... 68

Tabel 3. 6 Manualisasi TDI.................................................................................... 70

Tabel 3. 7 Manualisasi Kompleksitas Proses Bisnis .............................................. 73

Tabel 3. 8 Manualisasi Kompleksitas Proses Bisnis pada TDID, IUI dan PP ....... 73

Tabel 3. 9 Manualiasi Mteric Kompleksitas Proses Bisnis pada TDP .................. 73

Tabel 3. 10 Manualisasi Konversi Kompleksitas Menjadi Skala .......................... 74

Tabel 3. 11 Manualisasi Nilai Kompleksitas Proses Bisnis per Proyek ................ 76

Tabel 3. 12 Skala per Proyek ................................................................................. 76

Tabel 3. 13 Manualisasi Effort per Proyek ............................................................ 78

Tabel 3. 14 Manualisasi Distribusi Effort per Aktivitas ........................................ 78

Tabel 3. 15 Pay Rate per Tim Proyek .................................................................... 79

Tabel 3. 16 Manualisasi Cost per Aktivitas ........................................................... 80

Tabel 3. 17 Timeline Penelitian ............................................................................. 82

Table 5. 1 Unadjusted Function Point……………………………………………89

Table 5. 2 Total Degree Influence ......................................................................... 90

Table 5. 3 Adjusted Function Point ....................................................................... 91

Table 5. 4 Nilai Kompleksitas Proses Bisnis pada TDId, IUI, dan PP .................. 91

Table 5. 5 Nilai Kompleksitas Proses Bisnis pada TDP ........................................ 92

Table 5. 6 Konversi Nilai Kompleksitas kedalam Indeks ...................................... 92

Table 5. 7 Modified TDI ........................................................................................ 94

Table 5. 8 Modified AFP pada Proyek TDId ......................................................... 95

Table 5. 9 Modified AFP pada Proyek IUI ............................................................ 95

Table 5. 10 Modified AFP pada Proyek PP ........................................................... 96

Table 5. 11 Modified AFP pada Proyek TDP ........................................................ 96

Table 5. 12 Nilai Effort per Proyek........................................................................ 96

Table 5. 13 Nilai Effort per Aktivitas .................................................................... 97

Table 5. 14 Pay Rate per Position .......................................................................... 98

Table 5. 15 Cost Per Aktivitas ............................................................................... 99

xxi

Table 5. 16 Nilai Effort Hasil Modifikasi ............................................................ 100

Table 5. 17 Nilai Effort per Aktivitas Hasil Modifikasi ...................................... 101

Table 5. 18 Cost per Aktivitas Hasil Modifikasi ................................................. 102

Table 5. 19 Evaluasi Gap Antara Actual Coast dengan FPA ............................... 103

Table 5. 20 Evaluasi Gap Antara FPA dengan Modified FPA ............................ 105

xxii


1

BAB I

PENDAHULUAN

Bab ini berisi ulasan awal mengenai latar belakang, permasalahan, tujuan

dari penelitian ini. Sehingga diharapkan penelitian ini dapat bermanfaat bagi

dunia pendidikan secara umum.

1.1 Latar Belakang

Estimasi pengukuran perangkat lunak merupakan aktivitas paling krusial

dalam proses pengembangan perangkat lunak. Pendekatan sistematis dalam

estimasi pengukuran perangkat lunak penting untuk manajemen dan perencanaan

perangkat lunak. Pengukuran perangkat lunak yang efektif membantu

keberhasilan manajer proyek dalam mengerjakan proyek perangkat lunak sesuai

dengan konsep triple constraint – Scope (kualitas), Cost (sumber daya), dan

Schedule (waktu) (I, 2008). Dalam proses pengembangan perangkat lunak

teknologi berubah dengan sangat cepat. Sehingga aturan pengukurannya harus

disesuaikan dengan perubahan tersebut. Harus ada metodologi umum yang

independent terhadap teknologi dalam industry perangkat lunak. Function Point

Analysis (FPA) sangat sesuai dengan kategori ini (Raju and Krishnegowda, 2013).

Metode Function Point (FPA) merupakan metode pengukuran sekaligus

satuan ukuran untuk perangkat lunak seperti jam untuk mengukur waktu, mil

untuk mengukur jarak, atau Celcius untuk mengukur suhu (Pradani et al., 2013).

FPA pertama dikenalkan oleh Alan J. Albrecht dari IBM pada tahun 1979

(Albrecht, 1983). International Function Point User Group (IFPUG) secara resmi

mendeklarasikan bahwa metode Function Point sesuai untuk semua jenis

perangkat lunak. Terdapat penelitian yang menggunakan Function Point

menghasilkan cost estimation dengan deviasi 3.26 persen (Sari and Pribadi, 2018).

Hal ini berarti metode Function Point hampir mendekati Actual Cost dalam

proyek pengembangan perangkat lunak. Berdasarkan Software Productivity

Research, pengukuran perangkat lunak dengan Function Point secara signifikan

dapat meningkatkan kemungkinan keberhasilan proyek perangkat lunak on time

2

dan on budget. Gambar 1.1 menunjukkan statistik proyek yang dikerjakan dengan

dan tanpa Function Point.

Gambar 1. 1 Statistik proyek yang dikerjakan dengan dan tanpa Function Point.

(Sumber: Software Productivity Research) (George & Vogt, 2008)

Function Point mengukur perangkat lunak dengan mengkuantifikasi

fungionalitas perangkat lunak yang disediakan untuk pengguna berdasarkan

design logic. Pengguna yang dimaksud yaitu sophisticated user yang memahami

sistem dari perspektif fungsional, lebih dari “user” yang memberikan pernyataan

kebutuhan atau melakukan acceptance testing (Pradani, 2013). FPA memiliki 5

parameter atau domain untuk pengukuran perangkat lunak. Lima parameter

tersebut yaitu External Input (EI), External Output (EO), External Inquiry (EQ),

Internal Logic File (ILF) dan External Interface File (EIF). Kemudian

menentukan complexity weights pada masing-masing komponen menggunakan

level simple¸ average, dan complex. Fase terakhir, mengevaluasi General System

Characteristic (GSC) perangkat lunak, terdiri dari 14 faktor kompleksitas teknis

yang memberikan gambaran jelas dari kompleksitas internal perangkat lunak (Al-

hajri et al., 2005).

Kompleksitas adalah variabel dan subyektif idiom yang dapat dilihat

dengan cara yang berbeda, semakin rumit suatu perangkat lunak menghasilkan

lebih banyak bias, semakin sulit di-maintain dan di-update. Banyak teknik

pengukuran yang diterapkan dalam proses estimasi perangkat lunak dengan

melibatkan banyak Adjustment Factor seperti Function Point dan Use Case Point.

Nilai dari Adjustment Factor ini ditentukan berdasarkan pengalaman estimator

3

dengan beberapa aturan yang terbatas, tidak ada aturan spesifik yang lengkap atau

standart proses menentukan faktor-faktor tersebut. Sehingga diperlukan penelitian

yang harus fokus menginvestigasi cara yang sesuai dalam menentukan nilai

Adjustment Factor dengan highlight suatu standart untuk mengelola proses ini

(Vijay anda Manoharan, 2011).

Kompleksitas suatu perangkat lunak berbeda dengan perangkat lunak

lainnya (Pradani, 2013). Kompleksitas harus proporsional dengan effort proyek

berdasarkan dengan pendekatan: semakin kompleks suatu perangkat lunak

semakin besar effort yang harus dikeluarkan (Xiaa and Capretz, 2009). Hampir

sebagian besar penelitian mengalami dilemma yang sama yaitu perangkat lunak

semakin berkembang begitu pula kompleksitasnya, sehingga sangat sulit

memprediksi secara akurat ukuran perangkat lunak yang dikembangkan (Boehm

and Abts, 1998). Kompleksitas berpengaruh besar terhadap nilai suatu effort

perangkat lunak yang dikembangkan (Suharjito and Widodo, 2006). Selain itu,

faktor kompleksitas kurang relevan sehingga modifikasi diperlukan berdasarkan

kebutuhan perangkat lunak (Sari and Pribadi, 2018). Oleh karena itu, FPA harus

didukung dengan data tambahan untuk memperkuat pengukuran perangkat lunak

yang dikembangkan (Pratiwi, 2013).

Perangkat lunak seperti semua sistem kompleks yang lain, dapat

berkembang dari satu periode waktu ke periode waktu lainnya (Gilb, 1988).

Kebutuhan dan proses bisnis dapat berubah seiring dengan laju perkembangan

penggunanya (Raharja and Sn, 2012). Proses bisnis merupakan suatu akivitas

yang saling berhubungan dimana dilakukan oleh sebuah sistem untuk merubah

input menjadi output agar bernilai tambah bagi perspektif pengguna

(Almudimigh, 2007). Kompleksitas dari suatu proses bisnis menghasilkan

kebutuhan yang kompleks dalam pengembangan perangkat lunak (Yunis,

Surendro, and Telaumbanua, 2010). Proses bisnis suatu organisasi berbeda satu

dengan yang lain, begitu pula kompleksitas proses bisnisnya. Perbedaan

kompleksitas proses bisnis mempengaruhi ukuran dari perangkat lunak yang

dikembangkan (Dwi Lanang, 2018).

4

Berdasarkan uraian tersebut, penulis bermaksud memodifikasi General

System Characterictic (GSC) atau faktor kompleksitas dalam metode FPA dengan

menambahkan kompleksitas proses bisnis dalam 14 faktor kompleksitas. Selain

itu, dikarenakan saat ini scoring level kompleksitas ditentukan secara subyektif

oleh pakar, pendekatan ini menjadi tidak akurat karena dipengaruhi oleh emosi,

opini, dan pengalaman pakar. Sehingga, peneliti bermaksud menggunakan

pendekatan Cyclomatic Complexity dan beberapa metric lainnya untuk mengukur

kompleksitas secara obyektif agar menghindari subyektifitas atau mengira-ngira

dalam mengukur faktor kompleksitas pada Function Point. Sedangkan dalam

menentukan kompleksitas proses bisnis, peneliti menggunakan BPMN (Business

Prosess Modelling Notation) sebagai metric dalam menentukan kompleksitanya

dan mengukurnya menggunakan Cyclomatic Complexity dan beberapa metric

lainnya.

Beberapa penelitian yang melakukan modifikasi faktor kompleksitas yang

berpengaruh terhadap nilai pembobotan sebelum memperoleh nilai Adjusted

Function Point (AFP). Pertama, (Albrecht, 1983) meneliti tentang effort yang

diprediksi menggunakan Function Point Analysis (FPA) berdasarkan fungsi

perangkan lunak dan jumlah baris kode (SLOC) pada IBM. Penelitian kedua,

(Sari and Pribadi, 2018) memodifikasi faktor kompleksitas FPA untuk

mengestimasi harga aplikasi pelayanan publik dengan Use Case Point (UCP) dan

Term Of Reference (TOR). Penelitian ketiga yang dilakukan oleh (Pratiwi, 2013)

yaitu meneliti pengukuran volume perangkat lunak dengan menggunakan dua

pendekatan pemodelan yaitu berorientasi obyek dan model structural. Dengan

menggunakan FPA.

Dari kajian literature yang telah dilakukan, menurut penulis sejauh ini

belum ditemukan atau sangat sedikit penelitian yang memodifikasi FPA dengan

kompleksitas proses bisnis dan mengukurnya menggunakan Cyclomatic

Complexity. Modifikasi FPA ini, diduga akan menghasilkan perhitungan biaya

pembuatan perangkat lunak yang lebih akurat. Output dari modifikasi FPA ini

adalah berupa harga pengembangan perangkat lunak yang akan dibandingkan

dengan perhitungan FPA.

5

1.2 Rumusan Masalah

Berdasarkan dari persoalan yang telah dijabarkan pada pendahuluan,

berikut ini adalah bentuk pertanyaan penelitian:

a. Bagaimana pengaruh modifikasi faktor kompleksitas dalam metode function

point terhadap hasil estimasi pengkuran perangkat lunak?

b. Berapakah hasil evaluasi gap antara pengukuran perangkat lunak

menggunakan FPA dengan modifikasi dari FPA?

c. Berapakah harga perangkat lunak hasil pengukuran modifikasi faktor

kompleksitas dalam metode function point?

1.3 Tujuan

Tujuan dilakukannya penelitian ini adalah untuk mengetahui bagaimana

pengaruh modifikasi faktor kompleksitas metode function point dengan

menambahkan kompleksitas proses bisnis terhadap hasil pengukuran perangkat

lunak.

1.4 Lingkup Penelitian

Adapun beberapa limitasi dan lingkup dari penelitian ini yaitu:

a. Modifikasi metode Function Point ditekankan pada General System

Characteristic (GSC), dengan menambahkan kompleksitas proses bisnis

dalam 14 faktor kompleksitasnya.

b. Pengukuran perangkat lunak yang menjadi obyek penelitian menitikberatkan

pada masa pengembangan (Development).

c. Obyek penelitian yang digunakan adalah proyek pengembangan perangkat

lunak dalam negeri dengan menyesuaikan jenis perangkat lunak yang

dibangun.

1.5 Kontribusi Penelitian

Kontribusi dalam penelitian ini dibagi menjadi dua yaitu kontribusi di

bidang keilmuan dan kontribusi praktis.

1.5.1 Kontribusi Bidang Keilmuan

Bagi ilmu pengetahuan, kontribusi penelitian yang diberikan berupa

koreksi General System Characteristic (GSC) dari Function Point dengan

menambahkan kompleksitas proses bisnis pada Faktor Kompleksitasnya.

6

Modifikasi metode function point ini diharapkan dapat memberikan sumbangan

teoritis estimasi pengukuran biaya perangkat lunak.

1.5.2 Kontribusi Praktis

Kontribusi praktis dari penelitian ini diharapkan dapat membantu

Developer dalam melakukan estimasi pengukuran biaya perangkat lunak agar on-

time dan on-budget.

1.6 Sistematika Penulisan

Sistematika penulisan proposal penelitian ini adalah sebagai berikut:

a. Bab 1 Pendahuluan

Bab ini terdiri dari latar belakang penelitian, perumusan masalah, tujuan

penelitian, kontribusi penelitian, batasan penelitian, dan sistematika

penulisan.

b. Bab 2 Kajian Pustaka

Bab ini berisi kajian yang meliputi teori-teori dan penelitian yang sudah

ada terkait dengan topik penelitian.

c. Bab 3 Metode Penelitian

Bab ini membahas mengenai rancangan penelitian dan juga tahapan-

tahapan sistematis yang digunakan selama melakukan penelitian.

7

BAB II

TINJAUAN PUSTAKA

Bagian ini menjelaskan kajian pustaka untuk menunjang penelitian. Kajian

pustaka terdiri dari kajian teori yang dilakukan oleh peneliti dan penelitian-

penelitian sebelumnya.

2.1 Kajian Teori

Kajian teori membahas mengenai teori dasar dan konsep yang terkait

dengan penelitian guna mendapatkan landasan konstruksi teoritis sebagai

pedoman dan tolak ukur penelitian. Kajian teori pada penelitian ini meliputi

Pengukuran Perangkat Lunak, Function Point Analysis (FPA), Kompleksitas

Proses Bisnis, dan Modifikasi Faktor Komplekasitas.

2.1.1 Pengukuran Perangkat Lunak

Pengukuran perangkat lunak merupakan aktivitas dalam rekayasa

perangkat lunak yang digunakan untuk mengestimasi ukuran komponen perangkat

lunak agar dapat mengimplementasikan aktivitas manajemen proyek perangkat

lunak yang lain (Ng‟ang‟a and Tonui, 2015). Untuk mencapai keberhasilan

proyek perangkat lunak yang dapat diandalkan dalam pengembangan perangkat

lunak, perencana perangkat lunak memerlukan rencana yang dapat dicapai yaitu

perkiraan jadwal, ukuran sumber daya, dan risiko yang layak (Galorath & Evans,

2006). Kegagalan proyek perangkat lunak menjadi salah satu tantangan dan

norma utama dalam industri rekayasa perangkat lunak, bahkan banyak yang

dibatalkan sebelum selesai atau tidak diimplementasikan sama sekali. Mengatasi

beberapa alasan utama kegagalan proyek perangkat lunak merupakan titik awal

yang terbaik. Menurut (ISPA, 2008) alasan utama dibalik kegagalan proyek dan

masalah perangkat lunak terjadi karena hal berikut:

a. Ketidakmampuan mengukur proyek perangkat lunak dengan akurat

b. Ketidakmampuan menentukan pengembangan perangkat lunak dan

lingkungan yang sesuai secara akurat

c. Penentuan level kepegawaian dan keterampilan yang tidak tepat

8

d. Kebutuhan yang kurang terdefinisi dengan baik untuk perkiraan aktivitas

perangkat lunak

Kegagalan proyek perangkat lunak terutama karena estimasi perangkat

lunak yang tidak tepat. Ukuran perangkat lunak tetap merupakan bidang yang

menuntut di lingkup rekayasa perangkat lunak, berdasarkan (Gencel & Demirors,

2008) alasan utama mengukur ukuran perangkat lunak yaitu:

a. Ukuran perangkat lunak adalah ukuran utama yang digunakan sebagai

masukan dalam memperkirakan biaya dan usaha

b. Ukuran yang diestimasi dan ukuran sebenarnya dibandingkan untuk

memantau pencapaian proyek

c. Kontrak juga dibentuk dengan menggunakan ukuran pengukuran perangkat

lunak

d. Ukuran perangkat lunak juga digunakan dalam normalisasi tindakan lainnya

Ukuran perangkat lunak harus diestimasi pada tahap requirement pada

siklus hidup penegmbangan perangkat lunak (SDLC). Ukuran perangkat lunak

merupakan masukan utama untuk pengembangan perangkat lunak, jika ukuran

yang diestimasi benar maka perkiraan effort akan realistis dan akan diterjemahkan

ke estimasi biaya yang realistis (Galorath & Evans, 2006). Setelah ukuran

perangkat lunak ditentukan, bisnis memperkirakan upaya yang dibutuhkan untuk

membangun produk perangkat lunak yang dibutuhkan (Ng‟ang‟a and Tonui,

2015).

2.1.1.1 Metode Pengukuran Perangkat Lunak

Banyak pendekatan dan teknik pengukuran perangkat lunak yang telah

diusulkan selama bertahun-tahun oleh Engineering Research Community.

Perencana proyek perangkat lunak menggunakan pendekatan ini untuk

memperkirakan biaya proyek yang tepat untuk mengembangkan produk perangkat

lunak. Teknik pengukuran perangkat lunak ini dapat dikategorikan secara luas

menjadi dua, metrik pengukuran berbasis kode dan pengukuran ukuran fungsional

(FSM). Metrik pengukuran berbasis kode mengukur ukuran perangkat lunak

menggunakan program source code. Contoh metrik ukuran berbasis kode meliputi

LOC (Lines of Code), persamaan panjang perangkat lunak Halstead, McCabe's

9

Cyclometic Complexity. FSM (Functional Size Measurement) adalah alternatif

dari metode pengukuran berbasis kode termasuk Function Points Analysis (FPA)

yang memperhitungkan aspek statis dan dinamis dari sistem (Nguyen, 2010).

Selain itu juga terdapat metric pengukuran Use Case Point, COCOMO II, Test

Point, Object Point dan lain-lain (Borade, 2013).

2.1.2 Function Point Analysis (FPA)

Ukuran dan kompleksitas sistem terus berkembang, sehingga semakin sulit

untuk dipahami. Oleh karena itu, coding tools memungkinkan pengembang

perangkat lunak untuk menyediakan jumlah perangkat lunak lebih banyak untuk

memenuhi kebutuhan pengguna yang melebar. Sebuah metode harus digunakan

untuk memahami dan mengkomunikasikan ukuran. Teknik terstruktur pemecahan

masalah, function point analysis adalah metode yang memecah sistem menjadi

komponen yang lebih kecil sehingga dapat dipahami dan dianalisa dengan lebih

baik (Longstreet, 2005). Metode Function Point merupakan bagian dari Metode

FSM (Functional Size Measurement) yang pertama kali dikenalkan oleh Albrecht

pada tahun 1979 sebagai metode pengukuran nilai kompleksitas dan

fungsionalitas dalam proyek perangkat lunak (Pratiwi, 2013). Gambar 2.1

menunjukkan sistem perangkat lunak dari sudut pandang pengguna.

Gambar 2. 1 Perangkat Lunak dari Sudut Pandang Pengguna

(Sumber: Software Cost Estimation Using FPA) (B. Allen, 2005)

10

Pada level konseptual, FPA membantu mendefinisikan dua level abstrak

data, yaitu data at rest dan data in motion (Longstreet, 2005).

A. Data in motion

Data in motion ditangani melalui tipe fungsi transaksional atau transaksi

sederhana. Semua aplikasi perangkat lunak akan memiliki sejumlah

elementary processes atau independent processes untuk memindahkan data.

Transaksi (atau elementary processes) yang membawa data dari luar domain

aplikasi (atau application boundary) kedalam application boundary yang

disebut sebagai external input.

Transaksi (atau elementary processes) yang mengambil data dari resting

position (biasanya pada file) keluar domain aplikasi (atau application

boundary) disebut juga sebagai external input atau external inquiries.

B. Data at rest

Data at rest yang dipelihara oleh aplikasi yang bersangkutan diklasifikasikan

sebagai internal logic file. Data at rest yang dipelihara oleh aplikasi lain yang

bersangkutan diklasifikasikan sebagai external interface files.

2.1.2.1 Kegunaan Function Point Analysis

Perhitungan Function point analysis mempunyai banyak kegunaan, yaitu

sebagai berikut (Longstreet, 2005):

a. Function Points dapat digunakan untuk berkomunikasi lebih efektif

dengan kelompok pengguna bisnis.

b. Function Points dapat digunakan untuk mengurangi waktu lembur.

c. Function Points dapat digunakan untuk membuat inventory semua

transaksi dan file dari proyek atau aplikasi saat ini. Inventory ini bisa

dijadikan alat evaluasi finansial suatu aplikasi. Jika inventory dilakukan

untuk development project atau enhancement project, inventory yang sama

dapat digunakan untuk membantu menjaga scope creep dan untuk

membantu mengendalikan pertumbuhan proyek. Yang lebih penting lagi,

inventory ini membantu memahami besarnya masalah.

d. Function Points dapat digunakan untuk mengukur aplikasi software.

Ukuran merupakan komponen penting dalam menentukan produktivitas

11

(output / input), memprediksi usaha, memahami biaya unit, dan

sebagainya.

e. Tidak seperti beberapa metrik perangkat lunak lainnya, orang yang

berbeda dapat menghitung Function Points pada waktu yang berbeda,

untuk mendapatkan ukuran yang sama dalam selisih kesalahan yang wajar.

Artinya, kesimpulan yang sama akan diambil dari hasilnya.

f. FPA dapat membantu organisasi memahami biaya unit dari aplikasi

perangkat lunak atau proyek. Begitu biaya unit dipahami alat, bahasa,

platform dapat dibandingkan secara kuantitatif daripada secara subyektif.

Jenis analisis ini jauh lebih mudah dipahami daripada informasi teknis.

Jadi pengguna non teknis dapat memahami Function Points

2.1.2.2 Kapan tidak menggunakan Function Points?

Function Point bukanlah ukuran yang sangat sesuai saat mengukur

maintenance efforts (memperbaiki masalah) atau saat mencoba memahami

masalah kinerja. Sebagian besar effort terkait dengan memperbaiki masalah

(production fixes) karena mencoba untuk menyelesaikan dan memahami masalah

(detective work). Masalah lain yang melekat dengan pengukuran maintenance

work yaitu sebagian besar maintenance programming dilakukan oleh satu atau

dua individu. Keterampilan individu menjadi Faktor utama saat mengukur jenis

pekerjaan ini. Produktivitas individu maintenance programmers bisa bervariasi

sebanyak 1.000 persen. Penyesuaian kinerja mungkin ada atau mungkin tidak ada

hubungannya dengan fungsionalitas. Performance tuning merupakan hasil dari

mencoba memahami throughput aplikasi dan waktu pemrosesan. Ada metrik yang

lebih baik untuk digunakan saat mengukur jenis pekerjaan ini (Longstreet, 2005).

2.1.2.3 Keuntungan Function Point

Function Point Analysis menawarkan banyak kelebihan dibandingkan

metode ukuran perangkat lunak lainnya (Longstreet, 2005):

a. Tidak tergantung pada bahasa komputer, metodologi pengembangan,

teknologi, platform, atau kemampuan tim proyek.

b. Terhubung langsung dengan kebutuhan dan fungsionalitas pengguna.

12

c. Dapat diterapkan mulai dari tahap requirement paling awal dan sepanjang

siklus pengembangan perangkat lunak.

d. Function Point dapat membantu membangun komunikasi efektif antara

komunitas pengguna akhir dan pengembang perangkat lunak.

e. Karena Function Points didasarkan pada pengguna external use system,

bahkan pengguna non teknis sistem perangkat lunak dapat memahami dengan

baik tentang apa yang diukur Fuction Point.

f. Memberikan dasar kuantitatif untuk Earned Value Manajemen (EVM).

g. Memberikan dasar kuantitatif untuk First Time Yield (FTY) untuk mengukur

kemampuan pengerjaan ulang dan proses.

h. FPA konsisten, dapat didokumentasikan, dan metodologi pengukuran

berulang

i. FPA dapat mengungkap kesenjangan dalam kebutuhan fungsional, sehingga

menghindari pengenalan awal yang cacat pada aplikasi.

j. Cukup sederhana untuk meminimalkan overhead dan beratnya proses

pengukuran.

k. Memberikan pengukuran yang konsisten antar berbagai proyek dan

organisasi.

l. Function Point Analysis adalah satu-satunya yang diakui internasional dan

standar ISO untuk mengukur ukuran kebutuhan fungsional pengguna.

m. Function Points dapat disertakan sebagai bagian dari RFPs dengan dokumen

kebutuhan, untuk memberikan kesamaan pemaahaman.

n. Function Points bisa menjadi fondasi setting benchmarking organisasi

2.1.2.4 Tahap Perhitungan Function Point

Tujuan utama tahap perhitungan ini untuk menentukan perhitungan

Adjusted Function Point. Terdapat beberapa langkah yang harus dilakukan yaitu

ditunjukkan pada gambar 2.2:

13

Gambar 2. 2 Tahap Perhitungan Function Point.

Perhitungan Unadjusted Function Point (UFP) ditentukan pada tahap 3

dan 4. Perhitungan akhir Function Point (Adjusted Function Point)

dikombinasikan dengan Unadjusted Function Point (UFP) dan General System

Characteristics (GSC) atau faktor kompleksitas.

2.1.2.5 Tipe Perhitungan Function Point

Perhitungan Function Point dapat dikaitkan dengan proyek atau aplikasi.

Ada tiga jenis proyek perangkat lunak utama (Development, Enhancements dan

Maintenance). Sesuai dengan jenis Function Point ini ada tiga jenis perhitungan

Function Point yang berbeda (Development, Enhancement dan Application)

(Longstreet, 2005).

14

a. Development Project Function Point Count

Function Points dapat dihitung pada semua fase pembangunan proyek dari

proses requirement sampai implementasi. Jenis perhitungan ini terkait dengan

pekerjaan pengembangan baru. Lingkup creep dapat dilacak dan dipantau

dengan memahami ukuran fungsional pada semua tahap proyek. Seringkali,

jenis perhitungan ini disebut baseline function point count.

b. Enhancement Project Function Point Count

Hal ini umum untuk meningkatkan perangkat lunak setelah dimasukkan ke

dalam produksi. Jenis hitungan Function Point ini mencoba untuk

meningkatkan ukuran proyek. Semua aplikasi produksi berkembang dari

waktu ke waktu. Dengan melacak ukuran perangkat tambahan dan biaya

terkait, database historis yang dapat dibangun organisasi. Selain itu, penting

untuk memahami bagaimana sebuah proyek pembangunan telah berubah dari

waktu ke waktu.

c. Application Function Point Count

Perhitungan aplikasi dilakukan pada aplikasi yang sudah ada. "Baseline

Count" ini dapat digunakan dengan keseluruhan metrik aplikasi seperti total

maintenance hours. Metrik ini dapat digunakan untuk melacak maintenance

hours per Function Point dan merupakan contoh metrik yang dinormalisasi.

Hal itu tidak cukup untuk memeriksa maintenance saja, tapi seseorang harus

memeriksa rasio maintenance hours untuk mengukur aplikasi agar

mendapatkan gambaran yang benar.

2.1.2.6 Transaction Function

Transaction Function merepresentasikan sejumlah fungsionalitas yang

disediakan untuk end user untuk memproses data oleh aplikasi. Transaction

Function terdiri dari 3 tipe, yaitu:

1. External Input

External Inputs (EI) - adalah proses dasar dimana data melintasi

boundary dari luar ke dalam. Data ini masuk dari luar aplikasi. Data mungkin

berasal dari layar input data atau aplikasi lain. Data dapat digunakan untuk

memelihara satu atau lebih internal logic file (IFPUG, 2000). Data dapat

15

berupa informasi kontrol atau informasi bisnis. Jika data adalah informasi

kontrol tidak harus memelihara internal logic file.

Jika input eksternal menambahkan, mengubah dan menghapus

(menyimpan) informasi pada internal logic file, maka terdapat tiga masukan

eksternal. Masukan eksternal (terutama change & delete) dapat didahului

oleh penyelidikan eksternal.

Seperti semua komponen, External Input (EI) diberi nilai dan skor.

Pemberian nilai berdasarkan pada jumlah Data Elemen Type (DET) dan File

Type References (FTR). Tabel 2.1 menunjukkan level keduanya (low,

average, atau high) dan skor yang sesuai (3, 4, atau 6).

Tabel 2. 1 FTR dan DET EI

File Type Referenced (FTR) Data Elements (DET)

1-4 5-15 Lebih dari 15

Kurang dari 2 Low (3) Low (3) Average (4)

2 Low (3) Average (4) High (6)

Lebih dari 2 Average (4) High (6) High (6)

Untuk semua referensi EI yang lebih dari 2 FTR, semua yang perlu

diketahui adalah jika EI memiliki lebih dari 4 tipe elemen data yang dirujuk.

Jika EI memiliki lebih dari 4 DET, maka EI akan dinilai high; kurang dari 4

DET's the EI akan dinilai average. Setiap referensi EI yang kurang dari 2

FTR harus dipilih dan dihitung secara terpisah.

2. External Output

External Outputs (EO) - sebuah proses dasar dimana data yang diturunkan

melewati boundary dari dalam ke luar. Selain itu, EO dapat memperbarui

ILF. Data membuat laporan atau file output yang dikirim ke aplikasi lain.

Laporan dan file ini dibuat dari informasi yang terdapat dalam satu atau lebih

internal logical file dan external logical file. External Output dianalogikan

seperti gambar 2.3

16

Gambar 2. 3 External Output

(Sumber: Fundamentals of Function Point Analysis) (Longstreet, 2005)

Derived Data adalah data yang diproses di luar pengambilan langsung

dan pengeditan informasi dari internal logic file atau external interface file.

Data yang diturunkan biasanya merupakan hasil dari algoritma, atau

perhitungan. Data turunan terjadi bila satu atau lebih elemen data

digabungkan dengan formula untuk memperoleh elemen data tambahan. Data

turunan ini tidak muncul dalam FTR (internal logic file atau external

interface file).

Seperti semua komponen, EO dinilai dan diberi skor. Peringkat

didasarkan pada jumlah elemen data (DET's) dan jenis file yang dirujuk

(FTR's). Peringkat didasarkan pada jumlah elemen gabungan unik (gabungan

unique input dan sisi output) (DET's) dan jenis file yang dirujuk (FTR's)

(gabungan unique input dan sisi output). Tabel 2.2 mencantumkan tingkat

(rendah, rata-rata atau tinggi) dan skor yang sesuai (4, 5 atau 7)

Tabel 2. 2 FTR dan DET EO

File Type Referenced (FTR) Data Elements (DET)

1-5 6-19 Lebih dari 19

Kurang dari 2 Low (4) Low (4) Average (5)

2 atau 3 Low (4) Average (5) High (7)

Lebih dari 3 Average (5) High (7) High (7)

Untuk semua referensi EO yang lebih dari 3 file, semua yang perlu

diketahui adalah jika EO memiliki lebih dari 5 tipe elemen data. Jika EO

memiliki lebih dari 5 tipe elemen data maka EO akan dinilai high, kurang

dari 5 EO akan dinilai average. Setiap referensi EO yang kurang dari 3 file

harus dipilih dan dihitung secara terpisah.

17

3. External Inquiries

External Inquiry (EQ) - sebuah proses dasar dengan komponen input

dan output yang menghasilkan pengambilan data dari satu atau lebih internal

logic file atau external interface file. Proses input tidak memperbarui atau

memelihara FTR's (Internal Logical Files atau External Interface Files) dan

sisi output tidak mengandung data turunan.

Transaksi antar aplikasi disebut sebagai interface. Pengguna hanya

bisa memiliki output eksternal atau penyelidikan eksternal terhadap data di

luar aplikasi. Jika pengguna mendapatkan data dari aplikasi lain dan

menambahkannya ke file dalam aplikasi, hal tersebut adalah kombinasi get

dan add (external inquiry dan external input). External Inquiries

dianalogikan seperti gambar 2.4

Gambar 2. 4 External Inquiries

(Sumber: Fundamentals of Function Point Analysis) (Longstreet, 2005)

Seperti semua komponen, EQ ditentukan dan dinilai. Pada dasarnya,

EQ dinilai (Low, Average atau High) seperti EO, namun diberi nilai seperti

EI. Peringkat didasarkan pada jumlah elemen data unik (gabungan unique

input dan sisi output) (DET's) dan jenis file yang dirujuk (FTR's) (gabungan

unique input dan sisi output). Jika FTR yang sama digunakan pada sisi input

dan output, maka hanya dihitung satu kali. Jika DET yang sama digunakan

pada sisi input dan output, maka hanya dihitung satu kali juga. Functional

Complexity Matrix EQ, sama dengan tabel yang digunakan pada EO.

2.1.2.7 Data Function

Data Function merepresentasikan kumpulan data logic yang dibutuhkan

end user. Data Function terdiri dari dua tipe, yaitu:

1. Internal Logical File

18

Internal Logical Files (ILF) - kelompok pengguna data logis yang

diidentifikasi seluruhnya berada dalam boundary aplikasi dan dipelihara

melalui external input. Internal Logical Files memiliki arti inheren yang

dipelihara secara internal, terdapat beberapa struktur logis dan disimpan

dalam sebuah file. Meskipun bukan sebuah peraturan, ILF setidaknya harus

memiliki satu external output atau external inquiry. Artinya, setidaknya satu

external output atau external inquiry harus mencakup ILF sebagai

FTR. Sederhananya, informasi disimpan dalam ILF, sehingga bisa digunakan

nantinya. EO atau EQ bisa dari aplikasi lain, kemungkinan bahwa ILF

tertentu tidak direferensikan oleh EO atau EQ, namun digunakan oleh EI

(selain EI yang memeliharanya).

Seperti semua komponen, ILF dinilai dan diperingkat. Peringkat

tersebut didasarkan pada jumlah data elemen (DET's) dan jenis rekaman

(RET's). DET dan RET sudah dibahas sebelumnya. Itu Tabel 2.3

mencantumkan tingkat (rendah, rata-rata atau tinggi) dan skor yang sesuai (7,

10 atau 15).

Tabel 2. 3 RET dan DET ILF

Record Element Type (RET) Data Elements (DET)

1-19 20-50 Lebih dari 51

1 RET Low (7) Low (7) Average (10)

2 – 5 RET Low (7) Average (10) High (15)

Lebih dari 6 RET Average (10) High (15) High (15)

JIka seluruhnya atau banyak file hanya berisi satu record ketik, maka

semua itu diperlukan untuk mengetahui apakah file tersebut berisi lebih atau

kurang dari 50 tipe data elemen (DET's). Jika file berisi lebih dari 50 elemen

data maka file tersebut akan dinilai average, jika kurang dari 50 tipe data

jenis file akan dianggap low. Setiap file yang berisi lebih dari satu jenis

record bisa dipilih dan dihitung secara terpisah

2. External Interface File

External Interface File (EIF) - grup data terkait identitas pengguna

yang dapat dikenali tujuan referensi saja. Data berada sepenuhnya di luar

19

boundary aplikasi dan dipelihara oleh aplikasi input eksternal lain. File

antarmuka eksternal External Interface File bersifat internal logic file untuk

aplikasi lain Aplikasi dapat menghitung file sebagai EIF ILF atau tidak

keduanya. External Interface File memiliki arti inheren yang dipelihara

secara eksternal (mungkin oleh beberapa aplikasi lain), sebuah antarmuka

harus dikembangkan untuk mendapatkan data dan disimpan didalam file.

Setiap EIF yang termasuk dalam function point harus memiliki

setidaknya satu external output atau External Interface File. Setidaknya satu

transaksi, input eksternal, output eksternal atau eksternal inquiries harus

menyertakan EIF sebagai FTR. Setiap aplikasi, yang mereferensikan EIF,

perlu memasukkannya ke dalam FP Count mereka.

Seperti semua komponen, EIF dinilai dan diperingkat. Peringkat

tersebut didasarkan pada jumlah data elemen (DET's) dan jenis rekaman

(RET's). Tabel 2.4 mencantumkan tingkat (rendah, rata-rata atau tinggi) dan

skor yang sesuai (5, 7 atau 10).

Tabel 2. 4 RET dan DET EIF

Record Element Type (RET) Data Elements (DET)

1-19 20-50 Lebih dari 51

1 RET Low (5) Low (5) Average (7)

2 – 5 RET Low (5) Average (7) High (10)

Lebih dari 6 RET Average (7) High (10) High (10)

Jika file berisi lebih dari 50 elemen data maka file tersebut akan dinilai

average, jika kurang dari 50 data element type akan dianggap low. Setiap file

yang berisi lebih dari satu jenis record bisa dipilih dan dihitung secara

terpisah.

2.1.2.8 General System Characteristic (GSC)

Perhitungan Value Adjustment Factor (VAF) didasarkan pada 14 General

System Characteristic (GSC's) yang memberikan bobot fungsi umum dari aplikasi

yang dihitung. Setiap karakteristik memiliki deskripsi yang saling berkaitan untuk

menentukan degrees of influence. Degrees of influence berkisar pada skala 0

sampai 5, dari tidak berpengaruh hingga sangat berpengaruh. Setiap karakteristik

20

diberi peringkat berdasarkan deskripsi detail yang disediakan oleh IFPUG.

Perigkatnya yaitu:

0 : Tidak ada, atau tidak berpengaruh

1 : berpengaruh insidental

2 : berpengaruh sedang

3 : berpengaruh rata-rata

4 : berpengaruh signifikan

5 : berpengaruh kuat seluruhnya

Tabel 2.5 menunjukkan 14 kriteria untuk perhitungan General System

Characteristic (GSC's) (Longstreet, 2005):

Tabel 2. 5 General System Characteristic

General System Characteristic Deskripsi

1 Data Communication

Berapa banyak fasilitas komunikasi yang

ada untuk membantu mentransfer atau

bertukar informasi dengan aplikasi atau

sistem?

2 Distributed data processing Bagaimana data terdisribusi dan fungsi

pemrosesan ditangani?

3 Performance Apakah pengguna memerlukan respose time

atau throughput?

4 Heavily used configuration

Seberapa banyak penggunaan platform

perangkat keras saat ini dimana sistem akan

dieksekusi?

5 Transaction rate

Seberapa sering transaksi dieksekusi setiap

hari, setiap minggu, setiap bulan, dan lain-

lain?

6 On-line data entry Berapakah persentase infomasi yang

dimasukkan secara online?

7 End-user efficiency Apakah aplikasi dirancang untuk efisiensi

enduser?

21


8 On-line update Berapa banyak ILF yang diperbaharui oleh

transaksi online?

9 Complex processing Apakah aplikasi memiliki extensive logical

atau mathematical processing?

10 Reusability

Apakah aplikasi dikembangkan untuk

memenuhi satu atau lebih kebutuhan

pengguna?

11 Installation ease Seberapa sulit konversi dan instalasi?

12 Operational ease Seberapa efektif dan/atau otomatis start-up,

back up, dan prosedur recovery?

13 Multiple sites

Apakah aplikasi dirancang, dikembangkan

dan didukung terutama untuk diinstal pada

multiple sites untuk beberapa organisasi?

14 Facilitate change

Apakah aplikasi dirancang, dikembangkan

dan didukung untuk memudahkan

perubahan?

Item GSC seperti Transaction Rate, End Usr Efficiency, Online Update, dan

Reusability biasanya diberikan skor tinggi untuk aplikasi GUI dibandingkan

dengan aplikasi tradisional. Sebaliknya, Performance, Heavily Uses

Configuration, Multiple Sites diberikan skor lebih rendah untuk aplikasi GUI

dibandingkan dengan aplikasi tradisional (Longstreet, 2005).

1. Data Communication

Tingkat kebutuhan transfer data antara aplikasi dan processor. Tabel 2.6

menunjukkan deskripsi masing-masing bobot untuk menentukan degree of

influence dari data communication.

Tabel 2. 6 Degree of influence dari data communication

BOBOT Deskripsi untuk menentukan degree of influence

0 Aplikasi adalah pemrosesan batch murni atau standalone PC

22


1 Aplikasi bersifat batch namun memiliki remote entri data atau

remote printing.

2 Aplikasi bersifat batch namun memiliki remote data entry dan

remote printing

3 Aplikasi meliputi pengumpulan data online atau TP

(teleprocessing) front end ke proses batch atau sistem query.

4 Aplikasi lebih dari sekedar front-end, tapi hanya mendukung

satu jenis protokol komunikasi TP.

5 Aplikasi lebih dari sekedar front-end, dan mendukung lebih

dari satu jenis protokol komunikasi TP.

2. Distributed data processing

Data terdistribusi atau fungsi pemrosesan merupakan karakteristik aplikasi

dalam boundary aplikasi. Tabel 2.7 menunjukkan deskripsi masing-masing

bobot untuk menentukan degree of influence dari Distributed data

processing.

Tabel 2. 7 Degree of influence dari Distributed data processing


0 Aplikasi tidak membantu transfer data atau pengolahan fungsi

antar komponen sistem.

1

Aplikasi menyiapkan data untuk pemrosesan enduser pada

komponen yang lain dari sistem seperti PC spreadsheets dan

PC DBMS

2

Data disiapkan untuk transfer, kemudian ditransfer dan

diproses pada komponen lain dari sistem (bukan untuk

Pengolahan enduser).

3 Pengolahan data dan transfer data secara online dan satu arah

saja.

4 Pengolahan dan transfer data terdistribusi secara online dan

23


masuk kedua arah.

5 Fungsi pemrosesan secara dinamis ditampilkan pada komponen

paling banyak yang sesuai dari sistem.

3. Performance

Tujuan kinerja aplikasi, dinyatakan atau disetujui oleh pengguna, baik dalam

respon maupun throughput, pengaruh (atau akan mempengaruhi) desain,

pengembangan, pemasangan, dan dukungan aplikasi. Tabel 2.8 menunjukkan

deskripsi masing-masing bobot untuk menentukan degree of influence dari

performance.

Tabel 2. 8 Degree of influence dari performance


0 Tidak ada kebutuhan kinerja khusus yang dinyatakan oleh

pengguna.

1 Kebutuhan kinerja dan rancangan dinyatakan serta ditinjau tapi

tidak ada tindakan khusus yang diperlukan.

2

Waktu respon atau throughput sangat penting selama jam

sibuk. Tidak ada rancangan khusus untuk penggunaan CPU

yang dibutuhkan. Batas waktu proses adalah untuk hari kerja

berikutnya.

3

Waktu respon atau throughput sangat penting selama semua

business hours. Tidak ada rancangan khusus untuk penggunaan

CPU yang dibutuhkan. Memproses kebutuhan deadline dengan

interfacing sistem merupakan menghambat.

4

Selain itu, kebutuhan kinerja pengguna yang disebutkan cukup

ketat untuk membutuhkan performance analysis task di fase

desain

5 Selain itu, alat analisis kinerja digunakan di tahap desain,

pengembangan, dan/atau implementasi untuk mencapai

24


kebutuhn kinerja pengguna yang disebutkan.

4. Heavily used configuration

Konfigurasi operasional yang banyak digunakan, yang memerlukan

pertimbangan desain khusus, ysitu karakteristik aplikasi. Misalnya, pengguna

ingin menjalankan aplikasi yang ada atau commited equipment yang akan

banyak digunakan Tabel 2.9 menunjukkan deskripsi masing-masing bobot

untuk menentukan degree of influence dari heavily used configuration.

Tabel 2. 9 Degree of influence dari heavily used configuration


0 Tidak ada batasan operasional eksplisit atau implisit yang

disertakan.

1

Pembatasan operasional memang ada, tapi kurang ketat dari

pada sebuah aplikasi tertentu. Tidak ada upaya khusus yang

diperlukan untuk memenuhi pembatasan.

2 Beberapa pertimbangan keamanan atau waktu disertakan.

3 Kebutuhan prosesor khusus untuk bagian tertentu dari aplikasi

disertakan

4 Batasan operasi yang diatur memerlukan batasan khusus

aplikasi di central processor atau dedicated prosesor

5 Selain itu, ada kendala khusus pada aplikasi dalam komponen

terdistribusi dari sistem.

5. Transaction rate

Tingkat transaksi tinggi dan mempengaruhi desain, pengembangan,

pemasangan, dan dukungan dari aplikasi Tabel 2.10 menunjukkan deskripsi

masing-masing bobot untuk menentukan degree of influence dari transaction

rate.

25

Tabel 2. 10 Degree of influence dari transaction rate


0 Tidak ada periode transaksi puncak yang diantisipasi.

1 Periode transaksi puncak (mis., Bulanan, kuartalan, musiman,

setiap tahun) diantisipasi.

2 Periode transaksi puncak mingguan diantisipasi.

3 Periode transaksi puncak harian diantisipasi.

4

Tarif transaksi tinggi yang dinyatakan oleh pengguna dalam

kebutuhan aplikasi atau perjanjian tingkat layanan cukup tinggi

memerlukan tugas analisis kinerja pada tahap perancangan.

5

Tarif transaksi tinggi yang dinyatakan oleh pengguna dalam

kbutuhan aplikasi atau perjanjian tingkat layanan cukup tinggi

memerlukan tugas analisis kinerja dan memerlukan

penggunaan alat analisis kinerja dalam desain, tahap

pengembangan, dan / atau instalasi.

6. On-line data entry

Online data entry dan control functions disediakan dalam aplikasi. Tabel 2.11


influence dari online data entry.

Tabel 2. 11 Degree of influence dari online data entry


0 Semua transaksi diproses dalam mode batch.

1 1% sampai 7% dari transaksi adalah entri data interaktif.

2 8% sampai 15% transaksi adalah entri data interaktif.



5 Lebih dari 30% transaksi adalah entri data interaktif.

26

7. End-user efficiency

Fungsi online yang diberikan menekankan desain untuk efisiensi pengguna

akhir. Desainnya meliputi:

a. Bantuan navigasi (misalnya, tombol fungsi, lompatan, menu yang

dibuat secara dinamis)

b. Menu

c. Bantuan dan dokumen online

d. Gerakan kursor otomatis

e. Scrolling

f. Remote printing (melalui transaksi online)

g. Tombol fungsi yang telah ditentukan sebelumnya

h. Batch jobs dikirim dari transaksi online

i. Pemilihan kursor data layar

j. Penggunaan reverse video, highlight, color underlining, dan indikator

lainnya

k. Dokumentasi pengguna hard copy transaksi online

l. Antarmuka mouse

m. Jendela pop-up.

n. Layar sedikit mungkin untuk menyelesaikan fungsi bisnis

o. Dukungan bilingual (mendukung dua bahasa; dihitung sebagai empat

item)

p. Dukungan multi bahasa (mendukung lebih dari dua bahasa; dihitung

sebagai enam item)

Tabel 2.12 menunjukkan deskripsi masing-masing bobot untuk menentukan

degree of influence dari enduser efficiency.

Tabel 2. 12 Degree of influence dari enduser efficiency


0 Bukan dari salah satu dari kriteria desain yang disebutkan.

1 Satu sampai tiga dari kriteria desain yang disebutkan.

2 Empat sampai lima dari kriteria desain yang disebutkan.

3 Enam atau lebih hal dari kriteria desain yang disebutkan, tapi

27


tidak ada kebutuhan pengguna khusus yang berkaitan dengan

efisiensi.

4

Enam atau lebih kebutuhan dari kriteria desain yang

disebutkan, dan pernyataan kebutuhan untuk efisiensi

pengguna akhir cukup kuat untuk membutuhkan tugas desain

Human tasks yang harus disertakan (misalnya meminimalkan

key strokes, memaksimalkan default, penggunaan template).

5

Enam atau lebih dari kriteria desain yang disebutkan, dan

menyatakan kebutuhan untuk efisiensi pengguna akhir yang

cukup kuat membutuhkan pemakaian alat dan proses khusus

untuk menunjukkan bahwa tujuan telah tercapai

8. On-line update

Aplikasi menyediakan online update untuk internal logic file (ILF). Tabel

2.13 menunjukkan deskripsi masing-masing bobot untuk menentukan degree

of influence dari online update.

Tabel 2. 13 Degree of influence dari online update


0 Tidak ada

1 Online update satu sampai tiga file kontrol disertakan. Volume

update rendah dan recovery mudah dilakukan.

2 Online update dari empat atau lebih file kontrol disertakan.

Volume update rendah dan recovery mudah.

3 Pembaruan online internal logic file utama disertakan.

4

Selain itu, perlindungan terhadap data yang hilang sangat

penting dan telah dirancang serta diprogram secara khusus

dalam sistem.

5 Selain itu, volume tinggi membawa pertimbangan biaya ke

dalam proses recovery. Prosedur recovery yang sangat otomatis

28


dengan intervensi operator minimal disertakan

9. Complex processing

Complex processing merupakan ciri khas dari aplikasi. Komponen yang

disajikan adalah sebagai berikut:

a. Kontrol sensitif (misalnya, pemrosesan audit khusus) dan / atau

pengolahan keamanan khusus aplikasi

b. Proses logis yang ekstensif

c. Pengolahan matematika secara ekstensif

d. Banyak proses pengecualian yang mengakibatkan transaksi tidak

lengkap yang harus diolah kembali, misalnya transaksi ATM yang tidak

lengkap yang disebabkan oleh gangguan TP, kehilangan nilai data, atau

gagal mengedit

e. Pengolahan kompleks untuk menangani beberapa kemungkinan input /

output, misalnya multimedia, atau independensi perangkat


degree of influence dari complex processing.

Tabel 2. 14 Degree of influence dari complex processing


0 Bukan dari salah satu di atas.

1 Salah satu di atas.

2 Dua hal di atas.

3 Tiga hal di atas.

4 Keempat hal di atas.

5 Kelima hal di atas.

10. Reusability

Aplikasi dan kode dalam aplikasi telah dirancang, dikembangkan, dan

didukung untuk dapat digunakan dalam aplikasi lain. Tabel 2.15

29


influence dari reusability.

Tabel 2. 15 Degree of influence dari reusability


0 Tidak ada kode yang dapat digunakan kembali.

1 Kode dapat digunakan kembali digunakan dalam aplikasi.

2 Kurang dari 10% aplikasi dianggap lebih dari satu kebutuhan

pengguna

3 Sepuluh persen (10%) atau lebih dari aplikasi dipertimbangkan

lebih dari satu kebutuhan pengguna

4

Aplikasi dikemas secara khusus dan / atau didokumentasikan

untuk memudahkan penggunaan ulang, dan aplikasi

disesuaikan oleh pengguna pada tingkat kode sumber.

5

Aplikasi secara khusus dikemas dan / atau didokumentasikan

untuk memudahkan penggunaan ulang, dan aplikasi

disesuaikan untuk digunakan dengan cara pemeliharaan

parameter pengguna.

11. Installation ease

Kemudahan konversi dan pemasangan adalah karakteristik dari aplikasi.

Konversi dan rencana instalasi atau alat konversi disediakan serta diuji

selama tahap uji sistem. Tabel 2.16 menunjukkan deskripsi masing-masing

bobot untuk menentukan degree of influence dari installation ease.

Tabel 2. 16 Degree of influence dari installation ease


0

Tidak ada pertimbangan khusus yang dikemukakan oleh

pengguna, dan tidak ada pengaturan khusus yang diperlukan

untuk instalasi.

1 Tidak ada pertimbangan khusus yang dikemukakan oleh

pengguna namun pengaturan khusus diperlukan untuk instalasi

30


2

Kebutuhan konversi dan pemasangan dinyatakan oleh

pengguna, panduan konversi dan pemasangan disediaka serta

diuji. Dampak konversi pada proyek tidak dianggap penting

3

Kebutuhan konversi dan pemasangan dinyatakan oleh

pengguna, dan panduan konversi dan pemasangan disediakan

dan diuji. Dampak konversi pada proyek ini adalah dianggap

penting

4 Selain 2 di atas, konversi dan pemasangan otomatis alat

disediakan dan diuji

5 Selain 3 di atas, konversi dan pemasangan otomatis alat

disediakan dan diuji

12. Operational ease

Kemudahan operasional adalah karakteristik dari aplikasi. Prosedur start-up,

back up, dan recovery yang efektif diberikan dan diuji selama fase uji sistem.

Aplikasi meminimalkan kebutuhan akan kegiatan manual, seperti tape mount,

penanganan kertas, dan intervensi manual langsung di lokasi. Tabel 2.17


influence dari operational ease.

Tabel 2. 17 Degree of influence dari operational ease


0 Tidak ada pertimbangan operasional khusus selain prosedur back-

up yang normal dinyatakan oleh pengguna.

31


1 - 4

Satu, beberapa, atau semua hal berikut berlaku untuk aplikasi.

Pilih semua yang berlaku. Setiap item ada benarnya nilai satu,

kecuali seperti yang dinyatakan lain.

Proses start-up, back-up, dan recovery yang efektif disediakan,

tapi intervensi operator diperlukan.

Proses start-up, back-up, dan recovery yang efektif disediakan,

tapi tidak ada intervensi operator yang diperlukan (dihitung

sebagai dua item).

Aplikasi ini meminimalkan kebutuhan akan tape mount

Aplikasi ini meminimalkan kebutuhan penanganan kertas

5

Aplikasi ini dirancang untuk operasi yang tidak dijaga. Operasi

tanpa pengawasan berarti tidak ada intervensi operator diperlukan

untuk mengoperasikan sistem selain untuk start up atau shut down

aplikasi. Pemulihan error otomatis adalah fitur

dari aplikasi

13. Multiple sites

Aplikasi ini telah dirancang, dikembangkan, dan didukung secara khusus

untuk dipasang di beberapa situs untuk beberapa organisasi. Tabel 2.18


influence dari multiple sites.

Tabel 2. 18 Degree of influence dari multiple sites


0 Kebutuhan pengguna tidak perlu mempertimbangkan

kebutuhan lebih dari satu pengguna / situs instalasi.

1 Kebutuhan beberapa situs dipertimbangkan dalam desain, dan

32


aplikasi dirancang untuk beroperasi hanya dibawah lingkungan

perangkat keras dan perangkat lunak yang identik.

2

Kebutuhan beberapa situs dipertimbangkan dalam desain, dan

aplikasi dirancang untuk beroperasi hanya dibawah lingkungan

perangkat keras dan / atau perangkat lunak yang serupa.

3

Kebutuhan beberapa situs dipertimbangkan dalam

perancangan, dan aplikasi ini dirancang untuk beroperasi di

bawah lingkungan perangkat keras dan / atau perangkat lunak

yang berbeda.

4

Rencana dokumentasi dan dukungan disediakan serta diuji

untuk mendukung aplikasi dibeberapa situs dan aplikasinya

seperti yang dijelaskan pada 1 atau 2.

5

Rencana dokumentasi dan dukungan disediakan serta diuji

untuk mendukung aplikasi di beberapa situs dan aplikasinya

seperti yang dijelaskan oleh 3

14. Facilitate change

Aplikasi ini telah dirancang secara khusus, dikembangkan, dan didukung

untuk memudahkan perubahan. Karakteristik berikut dapat diterapkan untuk

aplikasi:

a. Fasilitas query dan laporan fleksibel yang disediakan dapat menangani

permintaan sederhana; sebagai contoh, dan / atau logika hanya

diterapkan pada satu internal logic file (dihitung sebagai satu item).

b. Fasilitas query dan laporan fleksibel yang disediakan dapat menangani

permintaan dengan kompleksitas rata-rata, misalnya, dan / atau logika

yang diterapkan pada lebih dari satu internal logic file (dihitung sebagai

dua item).

c. Fasilitas query dan laporan fleksibel yang disediakan dapat menangani

permintaan yang rumit, misalnya, dan / atau kombinasi logika pada satu

atau lebih internal logic file (dihitung sebagai tiga item).

33

d. Data kontrol bisnis disimpan dalam tabel yang dikelola oleh pengguna

dengan proses interaktif secara online, tapi perubahan hanya berlaku

pada hari kerja berikutnya.

e. Data kontrol bisnis disimpan dalam tabel yang dikelola oleh pengguna

dengan proses interaktif secara online, dan perubahan berlaku segera

(dihitung sebagai dua item)


degree of influence dari facilitate change.

Tabel 2. 19 Degree of influence dari facilitate change


0 Bukan dari salah satu di atas.

1 Salah satu di atas.

2 Dua hal di atas.

3 Tiga hal di atas.

4 Keempat hal di atas.

5 Kelima hal di atas.

2.1.2.9 Perhitungan Adjusted Function Point (AFP)

Perhitungan terakhir dari function point yaitu perkalian antara Value Adjusted

Point (VAF) dan Unadjusted Function Point (UFP). Formulanya adalah:

………………………… [1]

Unadjusted Function Point (UFP) diperoleh dari pembobotan pada komponen

fungsional sistem, kemudian dijumlahkan untuk memperoleh nilai dari UFP.

Tabel 2.20 menunjukkan contoh pembobotan UFP yang masih kosong.

34

Tabel 2. 20 Unadjusted Function Point (UFP)

Value Adjusted Point (VAF) merupakan nilai adjustment yang telah ditentukan

dengan formula:

∑ …………………………. [2]

.………………………… [3]

(Total Degree Influence) adalah jumlah seluruh nilai dari 14 kriteria General

System Characteristics (GSC) yang merupakan skor sistem dari perangkat lunak

yang diukur. Tabel 2.21 menunjukkan tabel scoring dari GSC.

Tabel 2. 21 Total Degree Influence (TDI)


1 Data Communication О 0 О 1 О 2 О 3 О 4 О 5

2 Distributed data processing О 0 О 1 О 2 О 3 О 4 О 5

3 Performance О 0 О 1 О 2 О 3 О 4 О 5

4 Heavily used configuration О 0 О 1 О 2 О 3 О 4 О 5

5 Transaction rate О 0 О 1 О 2 О 3 О 4 О 5

6 On-line data entry О 0 О 1 О 2 О 3 О 4 О 5

7 End-user efficiency О 0 О 1 О 2 О 3 О 4 О 5

35


8 On-line update О 0 О 1 О 2 О 3 О 4 О 5

9 Complex processing О 0 О 1 О 2 О 3 О 4 О 5

10 Reusability О 0 О 1 О 2 О 3 О 4 О 5

11 Installation ease О 0 О 1 О 2 О 3 О 4 О 5

12 Operational ease О 0 О 1 О 2 О 3 О 4 О 5

13 Multiple sites О 0 О 1 О 2 О 3 О 4 О 5

14 Facilitate change О 0 О 1 О 2 О 3 О 4 О 5

Total Degree of Influence =

Peringkatnya yaitu:

0 : Tidak ada, atau tidak berpengaruh

1 : berpengaruh insidental

2 : berpengaruh sedang

3 : berpengaruh rata-rata

4 : berpengaruh signifikan

5 : berpengaruh kuat seluruhnya

2.1.3 Estimasi Biaya Perangkat Lunak

Software Cost Estimation adalah proses memprediksi Biaya yang

diperlukan untuk mengembangkan sebuah perangkat lunak. Software Cost

Estimation meliputi satu atau lebih dari 1) Effort; 2) Project Duration; 3) Cost

(Leung et al., 2002). Software Cost Estimation berperan penting pada

keberhasilan manajemen proyek perangkat lunak (Li et al., 2009). Guideline

untuk melakukan estimasi biaya perangkat lunak yaitu:

1. Menentukan distribusi Effort per aktivitasnya

Tahap awal yang harus dilakukan dalam fase pengembangan perangkat lunak

adalah mengidentifikasi aktivitas-aktivitas yan tela ditetapkan oleh manajer

proyek. Setelah memperoleh daftar aktivitas, perlu untuk memperoleh

distribusi effort per aktivitas dalam bentuk persentase. Beberapa penelitian

yang telah melakukan persentase effort per aktivitas yaitu Kassem Saleh

36

(Saleh, 2011) untuk pengembangan proyek dari medium ke besar dan

Primandari, et al (Primandari, 2015) untuk proyek perangkat lunak skala kecil

yang ditunjukkan pada tabel 2.22

Tabel 2. 22 Persentase Effort per Aktivitas

No Activity

Distribution per project size

(%)

Medium-large Small

Software development phase

1 Requirements 7.5% 1.17%

2 Specifications 7.5% 6.75%

3 Design 10% 5.57%

4 Implementation 10% 55.65%

5 Integration Testing 7.5% 6.42%

6 Acceptance & deployment 7.5% 5.6%

Ongoing activities & quality and testing

7 Project management 8.34% 2.55%

8 Configuration management 4.16% 3.58%

9 Quality assurance 8.34% 0.66%

10 Documentation 4.16% 9.76%

11 Training & support 4.16% 0.6%

12 Evaluation & testing 20.84% 1.67%

Namun, kita dapat menggunakan distribusi effort yang berbeda untuk proyek

yang kita estimasi.

2. Menentukan Effort per Proyek

Setelah menentukan distribusi effortnya, selanjutnya menentukan effort per

proyek dengan menggunakan persamaan:

………………………................................... [4]

37

Effort per proyek diperoleh dengan mengalikan nilai FPA dengan Effort Rate.

Nilai Effort rate yaitu 8.2 man-hours untuk pengembangan proyek peranggkat

lunak skala kecil dan medium berdasarkan penelitian yang dilakukan oleh

(Subriadi, Sholiq and Ningrum, 2014)

3. Menentukan pay rate per aktivitas

Pay rate dapat ditentukan pada basis personil salary rate setiap posisi dalam

team proyek penembangan perangkat lunak. Contohnya pay rate untuk

manajer proyek, sistem analyst, programmer, documenter, tester dan lain-lain.

Pada penelitian ini payrate ditentukan dengan mengacu pada Kelly Service

Salary Guide 2013. Pay rate diperoleh dari gaji per bulan yang dibagi menjadi

per minggu atau per hari. Gaji per minggu disebut Person Month Rate (PMR),

gaji per minggu disebut People Week Rate (PWR), gaji per hari disebut

Person Day Rate (PDR), sedangkan gaji per jam disebut People Hour Rate

(PHR) (Saleh, 2011). Hubungan antara PMR, PWR, PDR, dan PHR

ditunjukkan pada persamaan (Saleh, 2011):

PWR = PMR/4.1

PDR = PMR/22 x 1.1

PHR = PDR/8 x 1.3 …………………………………………………………… [ ]

4. Menentukan Cost per aktivitas

Biaya per aktivitas dapat ditentukan dengan persamaan

……………… [6]

Dimana:

- Cost dalam aktivitasi merupakan biaya yang dibutuhkan untuk aktivitas

terkait dalam pengembangan proyek atau aktivitasi

- Effort dibutuhkan untuk melengkapi proyek pengembangan perangkat

lunak

- Percentagei berkaitan dengan aktivitas distribusi effort

38

- Pay Ratei merupakan pay rate untuk aktivitas i

2.1.4 Proses Bisnis

Menurut (Hannus, 1994), proses bisnis adalah entitas yang terdiri dari

aktivitas dan operasi terkait yang dimulai dari kebutuhan customer dan selesai

dengan memenuhi kebutuhannya. (Koistinen, 1997) mendefinisikan proses bisnis

sebagai kumpulan kegiatan yang memasukkan input dan menghasilkan output

yang bernilai bagi pelanggan. (Smeds et al., 1999) melihat proses bisnis sebagai

rangkaian aktivitas manusia yang kompleks dan dinamis, didukung oleh

teknologi, dihubungkan oleh aliran material dan informasi, serta diintegrasikan ke

dalam rantai nilai ekonomi untuk menciptakan nilai bagi pelanggan dan

keuntungan bagi para pemangku kepentingan. Hal ini merupakan definisi proses

bisnis yang konsisten.

2.1.4.1 Kompleksitas Proses Bisnis

Proses bisnis adalah sistem kompleks aktivitas manusia yang dirancang

dan ditingkatkan untuk menciptakan nilai bagi pelanggan (Hannus, 1994).

Sebagai hasil dari kebutuhan eksternal, seperti globalisasi, kemajuan teknologi,

siklus pengembangan yang lebih pendek dan persaingan yang semakin ketat,

proses bisnis menjadi semakin kompleks. Untuk mengatasi kompleksitas proses

bisnis intrinsik ini, pada dasarnya ada dua pendekatan yang berbeda: mengurangi

kompleksitas yang tidak perlu, dan mengelola kerumitan lainnya. Tujuan

utamanya adalah untuk memperbaiki proses bisnis, sehingga memberikan utilitas

yang semakin meningkat bagi pemangku kepentingannya.

Kompleksitas dapat dikelola dengan memodelkan proses bisnis seperti

peta proses dan diagram. Model proses membantu memahami proses yang

mendasarinya dengan memvisualisasikannya serta dengan mengungkapkan

antarmuka antara aktivitas dan unit organisasi yang berbeda. Sebagai hasil

perbaikan bisnis, model proses berkembang dan berubah. Kompleksitas yang

tidak perlu dalam proses bisnis kemungkinan akan mengakibatkan kegagalan

proses. Penelitian yang dilakukan oleh (Latva-Koivisto, 2001), mengungkapkan

bahwa kompleksitas proses bisnis dapat diukur dengan menggunakan Cyclomatic

complexity. Metric ini selain sederhana, lebih modular dibandingkan dengan

39

metric pengukuran kompleksitas lainnya. (Cardoso et al., 2006) juga

merekomendasikan Cyclomatic complexity sebagai metric pegukuran

kompleksitas.

2.1.4.2 BPMN (Business Prosess Modelling Notation)

Business Prosess Modelling Notation (BPMN) adalah standart untuk

pemodelan proses bisnis yang menyediakan notasi grafis untuk menspessifikkan

proses bisnis dalam sebuah Business Process Diagram (BPD), berdasarkan pada

teknik diagram alir tradisional. Tujuan dari BPMN yaitu untuk mendukung

pemodelan proses bisnis untuk pengguna teknis dan pengguna bisnis, dengan

menyediakan notasi yang intuitif bagi pengguna bisnis, namun dapat

merepresentasikan semantic proses. BPMN dirancang agar siap dipahami oleh

semua pemangku kepentingan bisnis. Termasuk analis bisnis yang membuat dan

menyempurnakan prosesnya, pengembang teknis bertanggung jawab dalam

mengimplementasikannya, dan manajer bisnis yang memonitor serta

mengelolanya. Sehingga, BPMN melayani seperti bahasa biasa yang

menjembatani gap komunikasi yang sering terjadi antara perancangan dan

implementasi proses bisnis (Latva-Koivisto, 2001).

A. Notasi BPMN

Tujuan utama pengembangan BPMN adalah menciptakan notasi yang

sederhana dan mudah dimengerti untuk menciptakan model Proses Bisnis,

sekaligus memberikan semantik serta mekanisme mendasar untuk

menangani kompleksitas yang melekat dalam Proses Bisnis. Pendekatan

yang diambil untuk menangani kedua kebutuhan yang saling bertentangan

ini adalah untuk mengatur aspek grafis dari notasi ke dalam kategori

tertentu. Terdapat seperangkat kategori notasi kecil sehingga pembaca

diagram BPMN dapat dengan mudah mengenali jenis elemen dasar dan

memahami diagramnya. Berbagai bentuk dasar BPMN ditunjukkan di

bawah ini (Tabel 2.22-2.27): Dalam kategori dasar elemen, variasi dan

informasi tambahan dapat ditambahkan untuk mendukung persyaratan

kompleksitas tanpa mengubah secara dramatis tampilan dasar dan nuansa

40

diagram. Pada bagian berikut, menggambarkan bagaimana bentuk BPMN

digunakan dalam berbagai model BPMN end-to-end.

BPMN Task Description

Tabel 2. 23 Task Description

Notasi Task Description

Tidak ada jenis task khusus yang ditunjukkan.

Task Pengguna adalah jenis tugas "alur kerja"

yang mana human performer melakukan tugasnya

dengan bantuan aplikasi perangkat lunak dan bisa

dijadwalkan melalui daftar task manajer

Tugas Manual adalah tugas yang diharapkan

dilakukan tanpa bantuan mesin atau aplikasi

eksekusi proses bisnis.

Tugas Layanan adalah tugas yang menggunakan

beberapa jenis layanan, bisa berupa layanan web

atau aplikasi otomatis.

Tugas Menerima adalah tugas sederhana yang

dirancang untuk menunggu pesan tiba dari peserta

eksternal (relatif terhadap proses).

Tugas Kirim adalah tugas sederhana yang

dirancang untuk mengirim pesan ke peserta

eksternal (relatif terhadap proses).

41

Notasi Task Description

Tugas Script dijalankan oleh mesin proses bisnis.

Pemodel atau pelaksana mendefinisikan naskah

dalam bahasa yang bisa diinterpretasikan oleh

mesin. Saat tugas siap untuk memulai, mesin akan

menjalankan script. Saat skrip selesai, tugasnya

juga akan selesai.

Tugas Aturan Bisnis menyediakan mekanisme

proses untuk memberikan masukan kepada

Business Rules Engine dan untuk mendapatkan

hasil perhitungan yang mungkin disediakan oleh

aturan bisnis mesin. Spesifikasi input / output dari

tugas akan memungkinkan proses mengirim dan

menerima data dari Business Rules Engine.

Sub-Process adalah jenis aktivitas dalam suatu

proses, namun juga dapat "dibuka" untuk

menunjukkan proses yang lebih rendah. Hal ini

berguna untuk proses dekomposisi atau general

process organization.

Aktivitas Panggilan adalah jenis aktivitas dalam

suatu proses. Aktivitas Panggilan menyediakan

tautan ke aktivitas yang dapat digunakan kembali:

misalnya, akan memanggil tugas ke Proses (lihat

gambar yang atas) atau Proses lainnya (lihat

gambar yang bawah).

BPMN Flow Description

Tabel 2. 24 Flow Description

Notasi Flow Description

42

Notasi Flow Description

Sequence flow diwakili oleh garis padat dengan

garis panah padat digunakan untuk menunjukkan

order (urutan) di mana aktivitas akan dilakukan

dalam diagram proses atau koreografi.

Message flow diwakili oleh garis putus-putus

dengan kepala panah terbuka dan digunakan

untuk menunjukkan aliran pesan antara dua

peserta proses terpisah (entitas bisnis atau peran

bisnis) yang mengirim dan menerimanya.

Asosiasi diwakili oleh garis putus-putus, yang

mungkin memiliki garis panah pada satu atau

kedua ujungnya, dan digunakan untuk mengaitkan

teks dan artefak lainnya dengan objek aliran.

Data Association diwakili oleh garis putus-putus

dengan garis panah dan digunakan untuk

mengaitkan data (elektronik atau nonelektronik)

dengan objek aliran. Asosiasi Data digunakan

untuk menunjukkan input dan output kegiatan.

BPMN Marker Description

Tabel 2. 25 Marker Description

Notasi Marker Description

Marker Loop digunakan untuk mewakili suatu

aktivitas yang akan dieksekusi beberapa kali

sampai kondisi terpenuhi. Kondisi tersebut dapat

divalidasi baik pada awal maupun akhir kegiatan

Marker Multi-Instance Paralel digunakan untuk

mewakili aktivitas yang dapat dieksekusi sebagai

beberapa instances yang dilakukan secara paralel.

Jumlah instances akan ditentukan melalui ekspresi

43

Notasi Marker Description

kondisi yang dievaluasi pada awal aktivitas.

Semua instances akan dimulai secara paralel dan

setiap instance memiliki parameter masukan yang

berbeda. Aktivitas secara keseluruhan selesai

setelah semua kasus selesai. Namun, ekspresi lain,

jika itu menjadi true, akan menghentikan semua

instances dan menyelesaikan aktivitas

Marker Multi-Instance sekuensial merupakan

aktivitas yang serupa dengan aktivitas Multi-

Instans Paralel, namun instances-nya akan

dijalankan secara berurutan. Instances kedua akan

menunggu sampai instances pertama selesai dan

seterusnya.

Adhoc Marker adalah simbol tilde dan digunakan

untuk menandai Sub-Process dimana pola urutan

normal idle dan aktivitasnya dapat dilakukan

sesuai urutan kebijaksanaan pengguna. Tugas

dapat dimulai kapan saja tanpa ketergantungan

langsung pada tugas-tugas lain.

Anotasi Marker adalah mekanisme bagi pemodel

untuk memberikan informasi teks tambahan

(yaitu, catatan) untuk pembaca diagram BPMN.

Anotasi dapat dihubungkan ke objek lain melalui

Asosiasi

BPMN Data Object Description

Tabel 2. 26 Data Object Description

Notasi Data Object Description

44

Notasi Data Object Description

Objek Data mewakili data yang digunakan

sebagai input dan output untuk aktivitas suatu

proses. Objek Data dapat mewakili objek tunggal

atau kumpulan objek

Input Data adalah input data eksternal untuk

keseluruhan proses. Ini adalah semacam

parameter masukan.

Output Data adalah hasil data dari keseluruhan

proses. Ini adalah jenis parameter output.

Data Store adalah tempat proses membaca atau

menulis data (misalnya database atau kabinet

arsip). Ini bertahan melampaui masa proses

instance.

Kumpulan Objek Data mewakili kumpulan

elemen data yang terkait dengan entitas data yang

sama (misalkan Daftar item pesanan).

BPMN Event Description

Tabel 2. 27 Event Description

Notasi Event Description

Start Events menunjukkan instance atau inisiasi

suatu proses atau Event Sub-Process dan tidak

memiliki arus deret yang masuk. Proses dapat

memiliki lebih dari satu Start Event, namun Event

Sub-Proses hanya memiliki satu Start Event.

Non-interrupting Start Events dapat digunakan

untuk memulai Event Sub-Process tanpa

mengganggu aliran proses utama.

45


Intermediate Events menunjukkan sesuatu yang

terjadi atau mungkin terjadi selama proses

berlangsung, antara Start dan End. Intermediate

Catching Event dapat digunakan untuk

menangkap event trigger dan dapat berada dalam

aliran atau dilekatkan pada batas aktivitas.

Intermediate Throwing Event dapat digunakan

untuk melempar event trigger.

Non-Interrupting Boundary Event dapat

dilekatkan pada batas aktivitas. Saat dipicu, arus

akan dihasilkan, namun aktivitas sumbernya akan

terus dilakukan.

The End Event menunjukkan di mana jalur dalam

Proses akan berakhir. Proses bisa memiliki lebih

dari satu End. Proses berakhir saat semua jalur

aktif telah berakhir. End Events tidak memiliki

arus keluar.

Menerima pesan untuk memulai Proses atau di

tengah Proses, baik dalam arus atau dilekatkan

pada batas aktivitas.

Kirim pesan di tengah atau di akhir jalur Proses.

46


Event Timer selalu catch type dan digunakan

untuk menandakan menunggu kondisi waktu

tertentu untuk mengevaluasi ke true, yang akan

memulai sebuah Proses, memulai Event Sub-

Proses, tunggu di tengah arus, atau tunggu sebagai

Boundary Event

Event Eskalasi menangani kondisi eskalasi,

memicu dimulainya Event Sub-Proses atau

Boundary Event.

Throw Escalation Event akan menyebabkan

kondisi eskalasi yang akan memicu catch Events.

Sebuah Link Event tidak memiliki arti penting

terkait bagaimana Proses dilakukan, namun

memfasilitasi proses pembuatan diagram.

Misalnya, menggunakan dua tautan yang saling

terkait sebagai alternatif long sequence flow.

Terdapat throwing link event sebagai "titik

keluar", dan catching link event sebagai "titik

masuk", dan kedua peristiwa ditandai sebagai

pasangan

Sebuah catch Error Event digunakan untuk

menangkap error dan mengatasinya. Event ini

hanya bisa digunakan sebagai permulaan Sub-

Proses Event atau sebagai Boundary Event.

Peristiwa ini dapat menangkap error yang

dilemparkan oleh throw Error Events atau

47


kesalahan yang dilemparkan oleh sistem atau

layanan BPM yang digunakan oleh Proses.

Sebuah throw Error Event digunakan mengatur

error untuk ditangani. Event ini hanya dapat

digunakan sebagai End Event (yaitu, tidak pernah

sebagai Intermediate Event).

Cancel Event hanya dapat digunakan dalam

konteks transaksi. The Catch Cancel Event

digunakan sebagai Boundary Events untuk Sub-

proses transaksi, dan akan memicu roll back

transaksi (yaitu, aktivitas Sub-Proses).

Cancel Event hanya dapat digunakan dalam

konteks transaksi. The throw Cancel Events hanya

digunakan dalam Sub-proses transaksi.

Conditional Events digunakan untuk menentukan

apakah akan memulai (atau melanjutkan) hanya

jika kondisi tertentu true. Seperti Event Timer,

Event Kondisional hanya ada sebagai catching

event. Mereka dapat digunakan pada awal Proses

atau event Sub-Proses, di tengah arus, atau

sebagai Boundary Event.

Event Kompensasi digunakan untuk menangani

kompensasi dalam prosesnya. Peristiwa catching

compensation event dipicu sebagai Event Sub-

Process Start Event, atau sebagai Boundary Event.

Event Kompensasi digunakan untuk menangani

kompensasi dalam prosesnya. The throwing

Compensation Event dapat digunakan di tengah

atau akhir jalur Proses.

48


Catching signal event digunakan untuk menerima

sinyal. Mereka adalah bentuk komunikasi generik

dan sederhana yang ada di dalam kolam (peserta

yang sama), melintasi kolam (peserta yang

berbeda), dan diseluruh diagram. Mereka dapat

digunakan pada awal Proses atau Event Sub-

Proses, di tengah arus, atau sebagai Boundary

Event.

Throwing signal event digunakan untuk mengirim

sinyal. Mereka adalah bentuk komunikasi generik

dan sederhana yang ada di dalam kolam (peserta

yang sama), melintasi kolam (peserta yang

berbeda), dan di seluruh diagram. Mereka dapat

digunakan di tengah atau akhir jalur Proses.

Multiple Event digunakan untuk meringkas

beberapa jenis Event dengan satu simbol. Event

dipicu jika salah satu dari jenis tersebut puas.

Mereka dapat digunakan pada awal Proses atau

Event Sub-Proses, di tengah arus, atau sebagai

Boundary Event.

Multiple Event digunakan untuk meringkas

beberapa jenis acara dengan satu simbol. Bila

event-nya yang tercapai, maka semua jenis event

dilempar. Mereka dapat digunakan di tengah atau

akhir jalur Proses.

Parallel multiple event digunakan untuk

meringkas beberapa jenis event dengan satu

simbol. Perbedaan antara event ini dan Multiple

Event adalah bahwa Multiple Paralel hanya dipicu

jika semua tipe tersebut terpuaskan. Mereka dapat

49


digunakan pada awal Proses atau event Sub-

Proses, di tengah arus, atau sebagai Boundary

Event.

Terminate End Event adalah acara "stop

everything". Saat Endate End Event tercapai,

seluruh proses dihentikan, termasuk semua

aktivitas paralel.

BPMN Gateaway Description

Tabel 2. 28 Gateaway Description

Notasi Gateway Description

Gateways digunakan untuk mengontrol

bagaimana jalan proses bertemu dan menyimpang

dalam suatu proses.

Event Gateway, saat splitting, mengarahkan arus

hanya ke satu outgoing branch, berdasarkan

kondisi. Saat penggabungan, ia menunggu satu

cabang yang masuk untuk menyelesaikannya

sebelum melanjutkan arus. Gateway dapat

ditampilkan dengan atau tanpa tanda "X", namun

sifatnya sama.

The Inclusive Gateway, saat splitting,

memungkinkan satu atau lebih cabang diaktifkan,

berdasarkan kondisi. Semua cabang masuk yang

aktif harus selesai sebelum digabungkan.

Gateway Paralel, saat splitting, akan mengarahkan

arus ke semua cabang keluar. Saat penggabungan,

menunggu semua cabang menyelesaikannya

sebelum melanjutkan arus.

50

Notasi Gateway Description

Event Gateway selalu diikuti dengan catching

event atau menerima task. Aliran Proses dialihkan

ke event / tugas berikutnya yang terjadi lebih

dulu. Saat penggabungan, ia berperilaku seperti

Event Gateway.

Gateway ini dapat dikonfigurasi sedemikian rupa

sehingga bisa digunakan untuk memulai sebuah

Proses, berdasarkan peristiwa pertama yang

mengikutinya (lihat gambar di sebelah bawah).

Parallel Event Gateway hanya digunakan untuk

memulai sebuah Proses. Ini dikonfigurasi seperti

Gateway Peristiwa biasa, namun semua peristiwa

berikutnya harus dipicu sebelum instance proses

baru dibuat.

Gateway Kompleks mendefinisikan perilaku yang

tidak tertangkap oleh gateway lain. Ekspresi

digunakan untuk menentukan perilaku

penggabungan dan pemisahan.

B. Diagram BPMN

Pemodelan Proses Bisnis digunakan untuk mengkomunikasikan berbagai

macam konfigurasi proses ke berbagai macam khalayak. Dengan demikian,

BPMN dirancang untuk mencakup banyak jenis pemodelan dan

memungkinkan pembuatan Proses Bisnis end-to-end. Elemen struktural

BPMN memungkinkan viewer dapat dengan mudah membedakan antara

bagian Diagram BPMN. Ada tiga tipe dasar submodel dalam lingkungan

pemodelan BPMN (Latva-Koivisto, 2001):

1. Proses (Orkestrasi), meliputi:

- Sebuah Proses Bisnis pribadi Non-executable (internal).

- Proses Bisnis Eksternal executable (internal).

51

- Proses Publik.

2. Koreografi.

3. Kolaborasi, yang dapat mencakup Proses dan / atau Koreografi.

- Tampilan Percakapan.

2.1.5 Metric Kompleksitas

Metric kompleksitas yang digunakan dalam mengukur kompleksitas

proses bisnis pada penelitian ini yaitu Cyclomatic, NOA(C/JS), CFC, CNC dan

Diameter. Cardoso et al memperkenalkan beberapa metric kompleksitas

sederhana yang diadaptasi dari software engineering. Berdasarkan metric

sederhana yang menghitung jumlah baris kode (LOC) program, Cardoso et al

mengajukan tiga metric (Cardoso et al., 2006):

- NOA : Jumlah aktivitas dalam proses

- NOAC : Jumlah aktivitas dan elemen control flow

- NOAJS : Jumlah aktivitas, join dan split

Untuk mengevaluasi bisnis proses, Cardoso memperkenalkan metrik

Control-Flow Complexity (CFC) yang meminjam ide dari kompleksitas

Cyclomatic McCabe (Cardoso et al., 2005). Metric ini menggunakan sejumlah

state yang diinduksi dari elemen control-flow dalam proses.

A. M. Latva-Koivisto (Koivisto, 2001) mengajukan metrik Coefficient of

Network Complexity (CNC) untuk bisnis proses. CNC merupakan metric yang

digunakan secara luas dalam jaringan analisis dan diajukan untuk mengukur

tingkat kompleksitas critical pass network. Cardoso et al. (Cardoso et al., 2006)

memberikan persamaan:

………………………………….. [7]

Selain beberapa metric yang telah disebutkan, penelitian ini juga

menggunakan metric sederhana yaitu diameter dari proses bisnis. Diameter

merupakan longest path dari node awal hingga node terakhir. Namun, (Koivisto,

52

2001) merekomendasikan Cyclomatic dalam menghitung kompleksitas karena

kelebihan dari Cyclomatic yaitu sebagai berikut:

- Cyclomatic menghasilkan good result sebagai modul pengukuran

kompleksitas perangkat lunak

- Validitas yang tinggi, karena kemungkinan pengukuran sangat sederhana

dalam menangkap isi kompleksitas graph

- Reliabilitas yang baik

- Kemudahan implementasi

- Independent terhadap ukuran

- Modularitas yang menjanjikan

2.1.6 Cyclomatic

Salah satu metric kompleksitas perangkat lunak untuk mengukur

kompleksitas program yaitu Cyclomatic complexity (CC), yang dikembangkan

oleh McCabe pada tahun 1976 (Tiwari and Kumar, 2014). Teori dasarnya adalah

semakin besar jumlah path suatu modul, semakin tinggi kompleksitasnya.

Cyclomatic complexity dihitung dengan menggunakan Control Flow Graph

(CFG), dihasilkan dari source code. Untuk membuat CFG, yaitu dengan membuat

simpul pada setiap statement dalam source code dan memberi nomor pada

masing-masing node, kemudian menghubungkan setiap node (ditunjukkan oleh

panah) berdasarkan flow-nya. Setelah itu, menghitung Cyclomatic complexity

dengan persamaan (4). Control Flow Graph digunakan untuk menunjukkan aliran

control dimana node merepresentasikan processing task (satu atau lebih kode

statement) dan edge/path merepresentasikan aliran control antar node (Tiwari and

Kumar, 2014).

Nilai Cyclomatic complexity harus tetap dibawah 10. Hal ini menunjukkan

kode yang terstruktur dengan baik dan ditulis dengan baik, kemampuan uji coba

yang tinggi, biaya dan usaha yang rendah untuk membangun dan memelihara.

Jika jumlah Cyclomatic complexity diatas 10, kode sumbernya rumit, memiliki

kemampuan uji rendah, serta biaya dan usaha yang tinggi untuk membangun dan

memelihara.

53

………………………… [6]

Dimana E = jumlah path-nya, N = jumlah node-nya

Pengukuran kompleksitas perangkat lunak dengan menggunakan

Cyclomatic complexity dapat dilakukan tidak hanya pada tahap koding. Ada

beberapa penelitian yang menggunakan Cyclomatic complexity untuk mengukur

kompleksitas perangkat lunak pada tahap desain (Chouhan et al., 2012),

(Boghdady et al., 2011), mengusulkan penggunaan activity diagram untuk

mengukur kompleksitas perangkat lunak dan menghasilkan test case perangkat

lunak dengan menggunakan kompleksitas siklo Cyclomatic complexity. (Nigam et

al., 2012) juga mengusulkan pendekatan yang sama tapi berbasis pada storyboard.

(Zapata et al., 2013) mengusulkan penggunaan flow graph untuk mengukur

kompleksitas dari sistem terstruktur dengan menggunakan Cyclomatic complexity.

2.2 Kajian Penelitian Terdahulu

Subbab ini menjabarkan penelitian terdahulu yang berkaitan dengan

penelitian yang akan dilakukan. Penelitian yang akan dibahas adalah kajian teori

yang telah dilakukan peneliti sebelumnya sehingga bisa ditemukan celah yang

nantinya akan diteliti lebih lanjut dan diharapkan dapat dilakukan penggalian

lebih mendalam dari penelitian-penelitian yang disesuaikan dengan kebutuhan

penelitan ini.

A. Modifikasi Faktor Kompleksitas Pada Metode Function Point untuk

Estimasi Harga Perangkat Lunak Terhadap Aplikasi Pelayanan Publik -

(Sari and Pribadi, 2018)

(Sari and Pribadi, 2018) pada penelitiannya yang berjudul A Modification

Complexity Factor in Function Points Method for Software Cost Estimation

Towards Public Service Application meneliti mengenai estimasi usaha dan

biaya perangkat lunak dengan pada 4 aplikasi layanan public. Dalam

penelitiannya terdapat dua fase yaitu pertama, mengelaborasi faktor

kompleksitas berdasarkan referensi metode lain (yaitu Use Case Point) dan

memetakan kebutuhan non-fungsional pada Term of References (TOR).

54

Kemudian fase kedua yaitu menghitung dan membandingkan usaha dan harga

dari original FPA sebelum dan sesudah memodifikasi faktor kompleksitasnya.

Peneliti memodifikasi faktor kompleksitas pada FPA sejumlah 14

aspek, 13 aspek teknis pada UCP, dan 16 kebutuhan non-fungsional

berdasarkan TOR. Hasil penelitiannya menunjukkan bahwa FPA tanpa

modifikasi menghasilkan deviasi 10.45%, sedangkan FPA ynag dimodifikasi

memiliki deviasi lebih kecil yaitu 3.26. Artinya bahwa perbedaan anatar kedua

metode yaitu 7.19% lebih baik jika metode FPA memodifikasi faktor

kompleksitasnya dengan 16 item.

B. Komplesitas Cyclomatic untuk Menentukan Level Kompleksitas Produk

pada COCOMO II – (Subandri and Sarno, 2017)

(Subandri and Sarno, 2017) pada penelitiannya yang berjudul Cyclomatic

Complexity for Determining Product Complexity Level in COCOMO II

meneliti mengenai level kompleksitas produk pada COCOMO II dengan

menggunakan Cyclomatic Complexity. Input misjudgment pada suatu atribut

akan meyebabkan dampak yang besar terhadap estimasi effort. Saat ini level

kompleksitas produk diukur secara subyektif oleh pakar.

Peneliti mengajukan Cyclomatic yang merupakan pendekatan baru

untuk mengukur kompleksitas produk secara obyektif. Perhitungan cyclomatic

menggunakan UML activity diagram yang diperoleh dari software requirement

untuk menentukan level kompleksitas produk.

Gambar 2.5 menunjukkan transformasi diagram kedalam bentuk graph

untuk dapat dihitung menggunakan cyclomatic. Studi kasus yang digunakan

dalam penelitian ini yaitu proyek perangkat lunak belanja online, dengan hasil

perhitungan cyclomatic sebesar 9. Nilai kompleksitas ini jika diterjemahkan

dalam kompleksitas produk dalam COCOMO II bernilai low.

55

Gambar 2. 5 Transformasi diagram ke graph

Untuk mengevaluasi keandalan pendekatan ini, hasilnya dibandingkan

dengan penilaian subjektif para pakar. Tiga pakar diminta untuk menilai

kompleksitas produk dari 20 proyek perangkat lunak. Hasilnya, ketiga pakar

tersebut memberikan penilaian berbeda terhadap 7 proyek. Untuk menemukan

alternatif penilaian terbaik, digunakan pendekatan MCDA. Setelah

mendapatkan nilai seragam, hasil Cyclometer dibandingkan dengan penilaian

pakar dengan menggunakan statistik kappa. Kesepakatan antara Cyclometer

dan peringkat pakar memiliki nilai kappa 0,78 yang ditafsirkan sebagai

moderat. Hal ini berarti bahwa Cyclometer dapat digunakan sebagai

pendekatan alternatif untuk menentukan kompleksitas produk di COCOMO II.

Penelitian selanjutnya, penelitu berencana untuk menggunakan basic flow of

requirement dalam dokumen SRS untuk menentukan peringkat kompleksitas

produk COCOMO II tanpa mengubahnya menjadi diagram aktivitas dan grafik

aliran control.

56

C. Implementasi Function Point Analysis dalam Mengukur Estimasi Volume

Sistem Perangkat Lunak Berorientasi Obyek dan Model Struktural pada

Sistem Akademik – (Pratiwi, 2013)

(Pratiwi, 2013) pada penelitiannya yang berjudul Implementation of Function

Point Analysis in Measuring the Volume Estimation of Software System in

Object Oriented and Structural Model of Academic System meneliti

pengukuran volume perangkat lunak dengan menggunakan dua pendekatan

pemodelan yaitu berorientasi obyek dan model structural. Pengukurannya

meliiputi beberapa tahap, dengan menjabarkan sistem informasi yang akan

disusun dalam bentuk model UML dan terstruktur. Kemudian model akan

dianalisis dengan menghitung Crude Function Points (CRP), Relative

Complexity Adjustment Factor (RCAF) dan kemudian menghitung FPA-nya.

FPA dapat digunakan sebagai alternative untuk mengukur volume

perangkat lunak berdasarkan kompleksitasnya, baik dari segi model

berorientasi obyek dan model terstruktur. Penggunakan FPA membutuhkan

pengalaman pakar profesional karena perhitungannya yang subyektif. Karena

perhitungannya berdasarkan representasi data processing FPA juga harus

didukung dengan data tambahan untuk memperkuat estimasi volume

perangkat lunak yang akan dikembangkan. FPA yang digunakan pada model

berorientasi obyek dan terstruktur tidak berbeda secara signifikan. Dimana

FPA berorientasi obyek sebesar 174.64 dan FPA model terstruktur sebesar

180.93. Sehingga dapat dikatakan pengukuran FPA menggunakan model

berorientasi obyek maupun model terstruktur cukup bagus untuk memberikan

ide hasil estimasi dari proses estimasi.

D. Usuluan Square Metric untuk Pengukuran Kompleksitas Model Proses

Bisnis - (Kluza and Nalepa, 2012)

(Kluza and Nalepa, 2012) dalam penelitiannya yang berjudul Proposal of

Square Metrics for Measuring Business Process Model Complexity meneliti

mengenai permasalahandalam menganalisa karakteristik pada model proses

bisnis dan mengukur kualitasnya menggunakan metric Square. Metric ini

mudah diinterpretasikan dan memberikan beberapa informasi dasar mengenai

57

struktur kompleksitas model. Metric yang diajukan akan digunakan dengan

model yang dibangun menggunakan BPMN.

Peneliti mengusulkan menggunakan ukuran dengan

mempertimbangkan elemen proses dan jumlahnya. Berdasarkan distribusi

jenis elemen proses, Durfee Square Metric (DSM), sedangkan untuk

memberikan representasi bentuk distribusi yang lebih akurat, peneliti

mengusulkan menggunakan Perfect Square Metrics (PSM). Baik DSM

maupun PSM dimaksudkan untuk mengukur secara bersamaan variasi dan

jumlah elemen proses. Ada beberapa keuntungan dari metrik yang diusulkan,

yaitu sangat intuitif bagi perancang (bilangan natural yang mudah ditafsirkan)

dan tidak terlalu rumit untuk dihitung. Selain itu, dapat dengan mudah

digunakan untuk mengukur model proses apa pun, khususnya untuk model

BPMN. Sebagai metrik dinyatakan mudah untuk menafsirkan bilangan asli

dan sangat intuitif. Dengan menggunakannya seseorang dapat memperoleh

informasi tentang kompleksitas struktural dari model proses bisnis. Penelitian

di masa depan akan fokus pada evaluasi praktis dari metrik yang diusulkan

dan penyesuaian untuk beragam kasus BP.

2.3 Profil Perusahaan

DTS (Dynamic Team Solution) awal didirikan atas inisiatif beberapa

mahasiswa aktif di jurusan Sistem Informasi ITS yang ingin membentuk sebuah

tim atau grup usaha dalam bidang Teknologi Informasi. DTS mulai beroperasi

pada pertengahan September 2011. Nama DTS kami pilih karena ingin

membangun sebuah tim kerja yang dinamis. Tim yang dinamis adalah tim yang

berkinerja tinggi, tim yang memanfaatkan energinya untuk memberikan yang

terbaik atas kepercayaan yang telah customer berikan. Serta tim yang percaya diri,

tim yang para anggotanya menyadari kekuatannya dan menggunakannya untuk

mencapai visi perusahaan.

Saat ini CV. DTS (Dynamic Team Solution) merupakan Perusahaan yang

bergerak dalam bidang jasa pembuatan aplikasi dan website. Jasa yang ditawarkan

dapat membantu customer dalam melakukan branding secara online, sehingga

58

dengan begitu dapat membantu beberapa permasalahan customer dalam

memasarkan bisnisnya secara online.

Beberapa perusahaan, instansi pemerintah, organisasi menjadi partner

DTS. Adapun beberapa patner yang telah bekerjasama yaitu Pemerintah

Kabupaten Buton Utara, Dinas Komunikasi dan Informatika kota Surabaya,

Organisasi CIMSA Score Universitas Indonesia, Digital Printing Amanah,

Jurusan Perencanaan Wilayah Kota ITS Surabaya, Media Center ITS Surabaya,

Eureka TV ITS Surabaya, Association for Information System Indonesia

(AISINDO), Himpunan Mahasiswa Sistem Informasi (HMSI) ITS Surabaya,

Klinik 3DClinic Mulyosari Surabaya, PT. Bama Berita Sarana Televisi (BBS TV)

Surabaya, Yayasan Pendidikan Al Falah Surabaya, PT. Voltech Kreasi

Engineering, Al ReyadaHIjra Hotel Malaysia, Toko Online Elana Malaysia,

Koperasi PT. Perusahaan Gas Negara (Persero), EventEdukasi Universitas

Airlangga Surabaya, PT. Skema Energi Asia Jakarta Selatan, PilihTutormu.

2.3.1 Visi Misi Perusahaan

Visi dan misi DTS (Dynamic Team Solution) yaitu sebagai berikut:

Visi

Menjadi perusahaan yang terpercaya di bidang perencanaan dan pengembangan

sistem informasi di Indonesia.

Misi

Memperluas jaringan mitra kerja usaha di seluruh Indonesia.

Memberikan pelayanan yang kontinyu dan mengedepankan kualitas produk.

Menciptakan lingkungan kerja yang profesional, kompetitif, dan dinamis

dengan memegang teguh komitmen perusahaan.

59

BAB III

METODE PENELITIAN

Bab ini memaparkan tahapan penelitian yang dilakukan dari awal hingga

penelitian selesai. Secara garis besar, bab ini dibagi menjadi dua bagian yaitu

tahapan dari penelitian dan waktu pengerjaan latihan.

3.1 Tahapan Penelitian

Gambar 3.1 menunjukkn tahapan penelitian yang digambarkan melalui

bagan:

Gambar 3. 1 Tahapan Penelitian

60

Berikut penjelasan mendetail dari tahapan-tahapan penelitian yang ditunjukkan

pada gambar 3.1

3.1.1 Identifikasi Topik Penelitian

Topik suatu penelitian dimulai dari identifikasi isu yang terjadi untuk

mendapatkan informasi terkait topic penelitian. Sehingga dengan idetifikasi isu,

didapatkan latar belakang mengapa penelitian perlu dilakukan. Pada tahap ini,

peneliti mengangkat fenomena yang terjadi pada proses pengembangan dan

pengukuran perangkat lunak di Indonesia. Pada penelitian ini didapatkan temuan

bahwa kompleksitas proses bisnis setiap perangkat lunak berbeda-beda, sehingga

ukuran perangkat lunak juga dipengaruhi oleh faktor proses bisnis.

3.1.2 Studi Literatur

Studi literature dilakukan dengan mengumpulkan data, informasi dan teori-

teori yang mendukung penelitian. Selain itu juga mengulas penelitian terkait dan

metode yang dijadikan acuan dalam penelitian. Pemahaman studi literature

bertujuan untuk mengulas metode function point dan kompleksitas proses bisnis

yang mempengaruhi pengukuran perangkat lunak. Pembahasan studi literature

dituangkan pada kajian pusataka yang dijelaskan pada bab dua.

3.1.3 Penyusunan Latar Belakang, Rumusan Masalah, Tujuan, dan Batasan

Penelitian

Latar belakang penelitian disusun setelah dilakukan identifikasi fenomena

dalam pengembangan perangkat lunak dan penelitian sebelumnya. Sedangkan

rumusan masalah merupakan hasil dari indentifikasi masalah dengan merumuskan

permasalahan dalam penelitian. Kemudian tujuan penelitian ditetapkan uruh

menentukan arah penelitian. Kontribusi penelitian ditetapkan dalam rangka

pengembangan ilmu pengetahuan bagi masyarakat dan bisnis sehingga dapat

digunakan dalam penelitian selanjutnya. Selain itu, diperlukan juga batasan

penelitian agar penelitian lebih terfokus dan sesuai dengan kebutuhan.

Pembahasan dari ketiga poin ini dijabarkan pada bab satu.

61

3.1.4 Rancangan Sistematika Metode Penelitian

Penyusunan tesis ini memiliki kerangka berpikir yang sekaligus

menunjukkan sistematika metode penelitian. Langkah-langkahnya ditunjukkan

pada gambar 3.2

Gambar 3. 2 Sistematika Metode Penelitian

Keterangan:

EI : External Input TR : Transaction Rate

EO : External Output ODE : Online Data Entry

EQ : External Inquiry EUE : End User Efficiency

ILF : Internal Logic File OU : Online Update

EIF : External Interface File CP : Complex Process

UFP : Unadjusted Function Point REU : Reusability

AFP : Adjusted Function Point IE : Installation Ease

FP : Function Point OE : Operational Ease

DC : Data Communication MS : Multiple Sites

DDP : Distributed Data Processing FC : Facilitate Change

62

PF : Performance BPC : Business Process

Complexity

HUC : Heavily Used Configuration

Tahap-tahap untuk mendapatkan nilai dari function point yaitu menentukan

dan memberikan nilai pada data functional types dan data transaction types.

Selanjutnya menentukan nilai VAF diperoleh dari nilai TDI (Total Degree

Influence) dikalikan dengan 0.01 dan jumlahkan dengan 0.65. Nilai TDI diperoleh

dari penjumlahan skor 14 faktor kompleksitas atau General System Characteristic

(GSC) ditambah dengan kompleksitas proses bisnis yan merupakan faktor ke-15

dari GSC. Kompleksitas proses bisnis dimodelkan menggunakan BPMN

(Business Process Management Notation) dan dihitung menggunakan metric

komplekasitas seperti Cyclomatic, NOA(C/JS), CNC dan Diameter. Hasil dari

AFP merupakan nilai dari Function Point yang kemudian dikonversi dalam bentuk

rupiah agar didapatkan harga perangkat lunak. Tahap terakhir yaitu Pengujian

yang dilakukan dengan membandingkan harga perangkat lunak dengan Function

Point, Modifikasi Function Point dan Actual Cost-nya.

3.1.5 Rancangan Konseptual Model

Pada tahap perancangan konseptual model, peneliti menyusun kerangka

berpikir dengan memodelkan modifikasi metode function point. Metode function

point fokus pada pengukuran perangkat lunak, kemudian ditambahkan

kompleksitas proses bisnis pada 14 faktor kompleksitas function point. Sehingga,

kompleksitas proses bisnis menjadi faktor yang ke-15. Sedangkan proses bisnis

lebih fokus pada aktivitas kompleks yang ada didalamnya. Perancangan

konseptual model dituangkan dalam bentuk bagan konseptual model yang

dijabarkan pada bab empat.

3.1.6 Teknik Pengumpulan Data

Pengumpulan data pada sebuah penelitian dapat dilakukan dalam berbagai

setting, berbagai sumber, dan berbagai cara (Sugiyono, 2016). Jika dilihat dari

segi settingnya, data dikumpulkan pada setting alamiah, pada sebuah eksperimen

atau diskusi dan sebagainya. Sedangkan dari sumber datanya, pengumpulan data

dapat menggunakan sumber data primer yaitu sumber data yang langsung

63

memberikan data kepada pengumpul data dan data sekunder yang merupakan

sumber data yang tidak langsung memberikan data kepada pengumpul data, atau

data sekunder dapat diperoleh melalui orang lain atau dokumen. Selanjutnya jika

dilihat dari segi cara atau teknik pengumpulan data, maka teknik pengumpulan

data dapat dilakukan dengan literatur review (studi kepustakaan), observasi

(pengamatan), interview (wawancara), kuesioner (angket), dokumentasi dan

gabungannya.

3.1.7 Analisis Data

Data yang dianalisis dapam penelitian ini yaitu berupa data kuantitattif dan

data kualitatif dari sumber data.

3.1.7.1 Data Kuantitatif

Data kuantitatif diperoleh dari pengumpulan data dengan survey. Data

yang dihimpun yaitu data lima proyek pengembangan perangkat lunak yang

dikerjakan oleh suatu perusahaan yang bergerak di bidang jasa pengembangan

perangkat lunak. Selain itu, data kuantitatif lain yang diperlukan dalam penelitian

ini yaitu data nilai proyek pengembangan perangkat lunak dari lima proyek

perangkat lunak yang dipilih. Data tersebut dijadikan acuan untuk dibandingan

dengan harga proyek perangkat lunak yang dihitung menggunakan modifikasi dari

function point.

- Data Proyek Perangkat Lunak

Berdasarkan survey yang telah dilakukan, maka terdapat 4 proyek

pengembangan perangkat lunak yang dikerjakan oleh suatu perusahaan yang

bergerak di bidang jasa pengembangan perangkat lunak. Berikut data-data

yang berhasil dihimpun ditunjukkan pada table 3.1

Nama Perusahaan : Dynamic Team Solution

Klien : Pemerintah Daerah XYZ

Tabel 3. 1 Daftar Proyek Pengembangan Perangkat Lunak

No Nama Proyek Perangkat Lunak Jenis Waktu

1 Tanda Daftar Industri Perizinan 2 Bulan

2 Izin Usaha Industri Perizinan 2 Bulan

3 Persetujuan Prinsip Perizinan 2 Bulan

64

No Nama Proyek Perangkat Lunak Jenis Waktu

4 Tanda Daftar Perusahaan Perizinan 4 Bulan

Sumber: Buku SKPL, 2013

Keterangan:

1. Nama Perangkat Lunak: Tanda Daftar Industri (TDId)

Aplikasi pelayanan public ini digunakan untuk melakukan pendaftaran

industry skala kecil dengan modal kurang dari Rp. 10 milyar. Aplikasi

perizinan ini dikelola oleh Dinas Perdagangan dan Perindustrian.

2. Nama Perangkat Lunak: Izin Usaha Industri (IUI)

Aplikasi pelayanan public ini digunakan untuk mendaftarkan usaha

industri skala besar dengan modal lebih dari Rp. 10 milyar. Aplikasi

perizinan ini dikelola oleh Dinas Perdagangan dan Perindustrian.

3. Nama Perangkat Lunak: Persetujuan Prinsip (PP)

Aplikasi pelayanan public ini digunakan untuk mendaftarkan usaha

industry yang belum beroperasi, sehingga masih dalam tahap

pembangunan pabrik. Aplikasi perizinan ini dikelola oleh Dinas

Perdagangan dan Perindustrian.

4. Nama Perangkat Lunak: Tanda Daftar Perusahaan (TDP)

Aplikasi pelayanan public ini digunakan untuk mendaftarkan segala jenis

usaha yang telah memiliki izin teknis, seperti TDId, IUI, PP, dan lain-lain.

Sehingga TDP merupakan legalitas yang wajib dimiliki setiap pengusaha.

Aplikasi perizinan ini dikelola oleh Dinas Perdagangan dan Perindustrian.

- Profil Informan

Nama : Faturrahman

Alamat : Perumahan GBR3 blok F.7 No. 3 Nggamprah Bandung

Barat

Jabatan : Project Manager merangkap sebagai System Analyst

Pengalaman : 3 tahun sebagai Project Manager dan Terakhir sebagai

Business Analyst di PT FIF Jakarta

Lulusan : Institut Teknologi Sepuluh Nopember Surabaya

Email : [email protected]

mailto:[email protected]

65

- Data Nilai Proyek

Seperti yang tercantum pada Kontrak dan Surat Perintah Kerja uang diberikan

kepada CV. Dynamic Team Solution, nilai nominal masing-masing proyek

ditunjukkan pada table 3.2

Tabel 3. 2 Nilai Proyek Perangkat Lunak

No Nama Proyek Perangkat Lunak Nilai Proyek (Rp)

1 Tanda Daftar Industri 44.300.000

2 Izin Usaha Industri 47.080.000

3 Persetujuan Prinsip 46.800.000

4 Tanda Daftar Perusahaan 91.500.000

Total 229.680.000

Sumber: Buku SKPL, 2013

- Data Personil Perusahaan

Data personil perusahaan meliputi posisi dan deskripsi pekerjaannya yang


Tabel 3. 3 Data Personil Perusahaan

No Posisi Deskripsi Pekerjaan

1 Project Manager Melakukan perencanaan, pengawasan, dan evaluasi

terhadap seluruh proyek yang dikerjakan

perusahaan.

2 Tester Menguji aplikasi yang telah dibangun oleh

Programmer yang mengacu pada dokumentasi

System Analyst

3 System Analyst Melakukan pengamatan lapangan dan menganalisis

hasil pengamatan menjadi suatu spesifikasi

kebutuhan pengguna dan desain antarmuka

perangkat lunak

4 Senior Programmer Mengeksekusi kode program sesuai dengan

kebutuhan perangkat lunak yang telah dianalisis

dengan tingkat keahlian yang tinggi

5 Junior Programmer Mengeksekusi kode program sesuai dengan

66

No Posisi Deskripsi Pekerjaan

kebutuhan perangkat lunak yang telah dianalisis

dengan tingkat keahlian yang cukup

6 Administrasi

Keuangan dan

Dokumentasi

Mengelola laporan keuangan perusahaan sesuai

dengan kaidah akuntansi dan perpajakan. Selain itu

melakukan pendokumentasian terhadap

kelengkapan dokumen proyek. Peran ini tidak

khusus mengelola kepegawaian, karena

rampingnya fungsi perusahaan.

Sumber: SK Direktur CV DTS, 2013

Besaran atau nominal gaji yang telah diterima tim proyek didapatkan dari standar

pengupahan yang diteliti oleh KellyService.co.id pada tahun 2013 yang


Tabel 3. 4 Standar Gaji

No Nama Proyek Perangkat Lunak Pengalaman Nominal Upah (Rp)

1 Project Manager 3 tahun 7.000.000

2 Tester 1 tahun 4.000.000

3 System Analyst 2 tahun 4.000.000

4 Senior Programmer 3 tahun 5.000.000

5 Junior Programmer 1 tahun 3.000.000

6 Administrasi Keuangan dan

Dokumentasi 1 tahun 2.000.000

Sumber: (KellyServices, 2013)

3.1.7.2 Data Kualitatif

Data kualitatif yang diperlukan yaitu alur prosedur setiap perangkat yang

telah dirancang oleh analis sistem dalam bentuk diagram UML. Selain itu data

lainnya yang diperlukan untuk menunjang penelitian ini. Berdasarkan hasil

pengamatan di lapangan, penulis memperoleh data-data yang kualitatif sesuai

dengan Buku Spesifikasi Kebutuhan Perangkat Lunak (DTS, 2013). Data

kualitatif tersebut diantaranya sebagai berikut:

1. Alur prosedur setiap kelompok yang telah dirancang oleh analis system

2. Perbedaan kelompok aktivitas yang telah dirumuskan oleh (Shaleh, 2011)

67

3. Data pendukung lainnya yang berkaitan dengan penelitian dan akan

diintergrasikan dengan perangkat lunak

3.1.8 Implementasi

Pada tahap ini merupakan implementasi dari metode penelitian yang disusun

pada bab tiga. Konsep model yang telah dikonstruk pada bab empat, selanjutnya

akan dilakukan perhitungan dengan metode function point beserta modifikasinya.

3.1.9 Pengujian

Pengujian dilakukan setelah perhitungan estimasi biaya function point dan

modifikasinya didapatkan. Selanjutnya penulis akan melakukan pengujian

validitas dengan membandingkan perhitungan biaya berdasarkan function point

dan modified function point dengan realisasi biaya perusahan.

3.1.10 Hasil Penelitian

Pada tahap penyusunan hasil atau pembahasan, hasil dari implementasi dan

pengujian yang telah tervalidasi digunakan untuk menjawab pertanyaan

penelitian.

3.1.11 Penyusunan Kesimpulan dan Saran

Tahap akhir dalam penelitian ini yaitu menganalisis dan membahas

temuan keseluruhan dalam penelitian, terkait dengan hasil implementasi dan

pengujian yang diperoleh. Tahap penyusunan kesimpulan dilakukan dengan

menelaah secara keseluruhan terhadap apa yang telah dilakukan pada penelitian

ini. Kesimpulan dibuat berdasarkan hasil studi literatur, sistematika metode

penelitian, impelementasi, pengujian dan penyusunan hasil yang diperoleh dari

pengukuran baiya perangkat lunak menggunakan FPA yang telah dimodifikasi

dengan menambahkan proses bisnis pada faktor kompleksitasnya. Selain itu pada

tahapan ini, peneliti memberikan saran untuk peluang penelitian yang akan

datang.

3.2 Manualisasi

Pada subbab ini berisi mengenai manualisasi perhitungan metode function

point, modifikasi dari metode function point dan estimasi biaya.

68

3.2.1 Perhitungan Function Point

Perhitungan function point merupakan komponen utama dalam menentukan

harga perangkat lunak yang dikembangkan. Hasil akhir dari perhitungan ini yaitu

merupakan ukuran dari perangkat lunak yang dihitung. Untuk memperoleh ukuran

dari perangkat lunak, langkah-langkah yaitu sebagai berikut:

1. Menghitung Unadjusted Fuction Point (UFP)

UFP merupakan salah satu faktor yang mempengaruhi ukuran dari

perangkat lunak yang dikembangkan. Nilai dari UFP diperoleh dengan

menentukan tipe fungsi pengguna dan bobot kompleksitanya. Langkah

pertama yaitu, melakukan identifikasi pada fungsi-fungsi yang digunakan

sebagai parameter perhitungan pada perangkat lunak dengan menggunakan

pendekatan Use Case Diagram (ditunjukkan pada Lampiran A.1 dan A.2).

Langkah kedua, menentukan pengklasifikasian pada tipe fungsi

pengguna berdasarkan pada karakteristik kompleksitas yang dimiliki

dengan pendekatan Use Case Diagram, elemen fungsi meliputi Internal

Logical File (ILF), External Interface File (EIF), External Input (EI),

External Output (EO dan External Inquery (EQ) yang ditunjukkan pada

lampiran A.1 dan A.2 (Marthaler, 2005).

Langkah ketiga, pada setiap fungsi yang telah dikelompokkan lalu

diberi bobot sesuai dengan tingkat kompleksitasnya, dalam penentuan

bobot kompleksitas Function Point meliputi Data Element Type (DET),

Record Element Type (RET) dan File Type Reference (FTR). Bobot

kompleksitas tiap elemen fungsi disajikan pada Tabel 2.1, Tabel 2.2, Tabel

2.3 dan Tabel 2.4. Perhitungan UFP ditunjukkan pada tabel

Tabel 3. 5 Manualisasi UFP

Tipe

Komponen

Level Kompleksitas

Low Average High

Total Count

Weighting

Factor Point Count

Weighting

Factor Point Count

Weighting

Factor Point

EI 17 3 51 3 4 12 4 6 24 87

EO 5 4 20 1 5 5 0 7 0 25

EQ 5 3 15 0 4 0 1 6 6 21

ILF 5 7 35 2 10 20 0 15 0 55

69

Tipe

Komponen

Level Kompleksitas

Low Average High

Total Count

Weighting

Factor Point Count

Weighting

Factor Point Count

Weighting

Factor Point

EIF 2 5 10 0 7 0 0 10 0 10

Total Unadjusted Function Point 198

Pada kolom count merupakan jumlah elemen proses pada Use Case

Diagram yang dipetakan berdasarkan level kompleksitasnya yaitu low,

averae dan high. Pemetaan tersebut berdasarkan pada DET, RET dan FTR

seperti yang telah dijelaskan pada Bab 2. Sedangkan weighting factor

merupakan konstanta yang nantinya akan dikalikan dengan jumlah proses

setiap level kompleksitas (kolom „count‟). Hasil perkalian pada kelima

komponen disajikan dalam kolom point. Sedangkan nilai dari UFP

merupakan total keseluruhannya.

Tabel merupakan contoh perhitungan pada proyek Tanda Daftar

Industri (TDId). Pada komponen EI (Eksternal Input) terdapat 24 proses

yang masing dipetakan menjadi: 17 proses pada level low, 3 proses pada

level average dan 4 proses pada level high. Masing – masing level

dikalikan dengan konstanta, yaitu 17 x 3 = 51, 3 x 4 = 12, dan 4 x 6 = 24.

Perhitungan tersebut berlaku pada komponen lainnya, namun dikalikan

dengan konstanta yang sesuai. Nilai UFP merupakan total nilai secara

keseluruhan pada proyek Tanda Daftar Industri (TDId) yaitu bernilai 198.

2. Menghitung Total Degree Influence (TDI)

Untuk memperoleh nilai atau score dari Total Degree Influence, 14

General System Characteristics (GSC) merupakan standar yang digunakan

untuk memperkirakan dampak pada produktivitas yang berkaitan dengan

berbagai masalah teknis pada proyek perangkat lunak (disajikan pada tabel

2.5). Setiap faktor diberikan bobot atau skor berdasarkan dampak relative

pada faktor tersebut.

Selanjutnya, System Analyst memberikan penilaian pada ke-14 faktor

dengan menggunakan skor 0 sampai 5. Kriteria pembobotannya

ditunjukkan padda Tabel 2.6 – 2.19 dalam Bab 2. Skor 0 mengindikasikan

70

bahwa faktor tidak relevan, skor 3 mengindikasikan bahwa faktor

memiliki pengaruh moderat ketika faktor dalam keraguan dan skor 5

mengindikasikan bahwa faktor tersebut sangat penting untuk

pengembangan proyek. Ke-14 faktor yang telah diberikan skor, kemudian

dijumlahkan untuk memperoleh nilai Total Degree Influence. Contoh

perhitungan Total Degree Influence (TDI) pada proyek Tanda Daftar

Industri (TDId) ditunjukkan pada tabel

Tabel 3. 6 Manualisasi TDI

No Characterictics Project

TDId

1 Data Communication 5

2 Distributed data processing 4

3 Performance 4

4 Heavily used configuration 2

5 Transaction rate 1

6 On-line data entry 5

7 End-user efficiency 5

8 On-line update 4

9 Complex processing 3

10 Reusability 5

11 Installation ease 5

12 Operational ease 3

13 Multiple sites 5

14 Facilitate change 3

Total Degree of Influence = 54

Pada kolom Characteristic merupakan 14 faktor GSC sedangkan pada

kolom TDId merupakan skor pada proyek Tanda Daftar Industri (TDId).

Contoh skor pada Data Communication, dalam menentukan skornya harus

berdasarkan dengan kriteria yang ditunjukkan pada Tabel 2.6. Faktor Data

Communication memperoleh skor sebesar 5 (berpengaruh secara

keseluruhan) sehingga sesuai dengan kriteria “Aplikasi lebih dari sekedar

front-end, dan mendukung lebih dari satu jenis protokol komunikasi TP”

(pada Tabel 2.6)

3. Menghitung Nilai Value Adjustment Factor (VAF)

71

Nilai Value Adjustment Factor diperoleh menggunakan persamaan [3].

Contoh perhitungan VAF pada proyek Tanda Daftar Industri (TDId) yaitu:

= 54 * 0.01 + 0.65

= 1.19

Sehingga nilai VAF pada proyek Tanda Daftar Industri (TDId) yaitu

1.19. Nilai tersebut diperoleh dari Total Degree Influence dengan nilai 54

dikalikan dengan 0.01 dan dijumlahkan dengan 0.65.

4. Menghitung Adjusted Funtion Point (AFP)

Perhitungan terakhir dari Function Point adalah AFP, dimana AFP

merupakan nilai Function Point sekaligus sebagai ukuran dari proyek yang

dihitung. Nilai AFP diperoleh dengan menggunakan persamaan [1].

Contoh perhitungan AFP pada proyek Tanda Daftar Industri (TDId) yaitu:

= 198 * 1.19

= 235.62

Sehingga nilai AFP atau ukuran dari proyek Tanda Daftar Industri

(TDId) yaitu 235.62 FP (Function Point). Nilai tersebut diperoleh dari

Unadjusted Function Point dengan nilai 198 dikalikan dengan nilai dari

Value Adjustment Factor dengan nilai 1.19.

Tahap peritungan function point dari perhitungan UFP hingga AFP berlaku

pada 3 proyek lainnya, yaitu Ijin Usaha Industri (IUI), Persetujuan Prinsip (PP),

dan TDP (Tanda Daftar Perusahaan).

3.2.2 Perhitungan Modified Function Point

Perhitungan Modified Function Point pada umumnya serupa dengan

perhitungan FPA biasa, modifikasinya terletak pada perhitungan Total Degree

Influence (TDI). Nilai TDI diperoleh dari penjumlahan 14 faktor General System

Characteristic (GSC). Modifikasi dilakukan dengan menambahkan 1 faktor yaitu

Kompleksitas Proses Bisnis yang menjadi faktor ke 15 dalam GSC. Tahap

perhitugan Modified Function Point yaitu sebagai berikut:

1. Menghitung Unadjusted Fuction Point (UFP)

72

Perhitungan Unadjusted Function Point (UFP) serupa dengan UFP

pada Original Function Point, karena proses modifikasi tidak dilakukan

pada tahap ini. Sehingga Nilai UFP pada proyek Tanda Daftar Industri

(TDId) tetap sama yaitu bernilai 198, begitu juga pada 3 proyek lainnya.

2. Menghitung Total Degree Influence (TDI)

Untuk memperoleh nilai atau score dari Total Degree Influence tetap

menggunakan cara yang sama yaitu dengan menjumlahkan 14 faktor

General System Caracterictis (GSC). Begitu pula dengan penambahan

faktor Kompleksitas Proses Bisnis. Penilaian pada ke-14 faktor dengan

menggunakan skor 0 sampai 5 dilakukan secara subyektif oleh System

Analyst. Kriteria pembobotannya ditunjukkan pada Tabel 2.6 – 2.19 dalam

Bab 2. Sedangkan faktor ke-15 ditentukan secara kuantitatif dengan

perhitungan, langkahnya yaitu sebagai berikut.

Langkah pertama, menghitung nilai dari Kompleksitas Proses Bisnis

dengan menggunakan metric kompleksitas berdasarkan BPMN (Business

Process Management Notation) yang ditunjukkan pada Lampiran B.1.

Gambar 3. 3 Manualisasi Proses Bisnis Login

Penentuan kompleksitas proses bisnis berdasarkan pada BPMN,

gambar adalah contoh diagram BPMN pada proses bisnis menu Login.

73

Dari gambar tesebut kompleksitas proses bisnis dihitung dengan beberapa

metric yaitu ditunjukkan pada Tabel

Tabel 3. 7 Manualisasi Kompleksitas Proses Bisnis

Metric Rumus Menu

Login

Cyclomatic Edge - Node + 2 2

NOA Jml activites 6

NOAC=NOAJS Jml activites and

control flow 9

CNC Edge/jml acivities join

split 1

Diameter Longest path from start

to end node 8

Perhitungan metric kompleksitas juga berlaku pada 7 proses bisnis

yang lain. Pada penelitian ini keempat proyek memiliki proses bisnis yang

sama, namun berbeda pada proses bisnis ke-5 yaitu Pemohonan Baru pada

proyek Tanda Daftar Perusahaan (TDP). Pada Tabel menunjukkan

perhitungan kompleksitas proses bisnis pada proyek TDI, IUI, dan PP.

Tabel 3. 8 Manualisasi Metric Kompleksitas Proses Bisnis pada TDID, IUI dan PP

Metric Proses Bisnis

Nilai 1 2 3 4 5 6 7 8

Cyclomatic 2 1 1 2 2 2 3 1 14

NOA 6 4 4 5 17 8 8 4 56

NOAC=NOAJS 9 6 6 8 22 11 11 6 79

CNC 1 0.83 0.83 1 1 1 0.92 0.83 7.42

Diameter 8 6 6 7 19 10 10 6 72

Tabel menunjukkan hasil perhitungan kompleksitas proses bisnis pada

proyek TDP.

Tabel 3. 9 Manualiasi Mteric Kompleksitas Proses Bisnis pada TDP


Nilai 1 2 3 4 5 6 7 8

Cyclomatic 2 1 1 2 4 2 3 1 16

74


Nilai 1 2 3 4 5 6 7 8

NOA 6 4 4 5 19 8 8 4 58

NOAC=NOAJS 9 6 6 8 25 11 11 6 82

CNC 1 0.83 0.83 1 1.08 1 0.92 0.83 7.50

Diameter 8 6 6 7 21 10 10 6 74

Dimana kode proses bisnisnya yaitu:

1) Login

2) Profil Usaha

3) Mutasi Keluar

4) Penutupan

5) Permohonan Baru

6) Perpanjangan

7) Perubahan

8) Status perijinan

Langkah kedua, mengkonversi nilai kompleksitas masing-masing

proyek dalam bentuk range nilai agar menyesuaikan dengan 14 faktor

lainnya. Konversi nilai dilakukan dengan menggunakan metode FiveBox

yang ditemukan oleh Ferdinand (Ferdinand, 2006). Perhitungan Five Box

Method yaitu range nilai tertinggi dengan nilai terendah dari nilai

kompleksitas dibagi 5 (karena terdapat 5 skala) dan hasilnya sebagai range

nilai antar skala. Contoh pada metric Cyclomatic range nilai tertinggi yaitu

16 dan nilai terendahnya yaitu 14. Kedua nilai tersebut memiliki range

sebesar 2, kemudian untuk menentukan range nilai antar skala dihitung

dengan range/5 = 2/5 = 0.4. Nilai ini merupakan range antar skala 1

sampai 5. Hasilnya ditunjukkan pada kolom skala pada Tabel.

Tabel 3. 10 Manualisasi Konversi Kompleksitas Menjadi Skala

Metric Nilai

Tertinggi

Nilai

Terendah Range

Range

Skala Skala

Cyclomatic 16 14 2 2/5 = 0.4 14 – 14.4 = 1

75

Metric Nilai

Tertinggi

Nilai

Terendah Range

Range

Skala Skala

14.5 – 14.9 = 2

15 – 15.4 = 3

15.5 – 15.9 = 4

16 – 16.4 = 5

NOA 58 56 2 2/5 = 0.4

56 – 56.4 = 1

56.5 – 56.9 = 2

57 – 57.4 = 3

57.5 – 57.9 = 4

58 – 58.4 = 5

NOAC/JS 82 79 3 3/5 = 0.6

79 – 79.6 = 1

79.7 – 80.3 = 2

80.4 – 81 = 3

81.1 – 81.7 = 4

81.8 – 82.4 = 5

CNC 7.5 7.4 0.1 0.1/5 =

0.02

7.42 – 7.436 = 1

7.437 – 7.453 = 2

7.454 – 7.470 = 3

7.471 – 7.487 = 4

7.488 – 7.504 = 5

Diameter 74 72 2 2/5 = 0.4

72 – 72.4 = 1

72.5 – 72.9 = 2

73 – 73.4 = 3

73.5 – 73.9 = 4

74 – 74.4 = 5

Langkah ketiga yaitu menentukan masing-masing nilai kompleksitas

keempat proyek masuk pada skala 1, 2, 3, 4 atau 5. Contohnya pada metric

Cyclomatic, nilai TDId, IUI dan PP yaitu 14 sehingga ketiga proyek

tersebut termasuk dalam skala 1. Sedangkan proyek TDP dengan nilai 16

masuk pada skala 5. Tabel menunjukkan hasil nilai kompleksitas proses

bisnis per proyek

76

Tabel 3. 11 Manualisasi Nilai Kompleksitas Proses Bisnis per Proyek

Metric

Nilai

TDId, IUI, PP TDP

Cyclo 14 16

NOA 56 58

NOAC(JS) 79 82

CNC 7.42 7.50

Diameter 72 74

Berdasarkan Tabel skala proyek TDId, IUI, PP, dan TDP masing-

masing beserta nilai Total Degree Influence ditunjukkan pada Tabel

Tabel 3. 12 Skala per Proyel


TDI IUI PP TDP

1 Data Communication 5 5 5 5

2 Distributed data processing 4 4 4 5

3 Performance 4 3 5 4

4 Heavily used configuration 2 3 3 3

5 Transaction rate 1 1 0 1

6 On-line data entry 5 5 5 5

7 End-user efficiency 5 4 5 5

8 On-line update 4 3 4 3

9 Complex processing 3 4 3 4

10 Reusability 5 5 4 5

11 Installation ease 5 4 4 3

12 Operational ease 3 4 3 4

13 Multiple sites 5 5 4 5

14 Facilitate change 3 4 3 4

15 Business Process Complexity 1 1 1 5

Modified Total Degree of Influence

= 55 55 53 61

Meski menggunakan metric kompleksitas yang berbeda, namun kelima

metric memperoleh hasil yang sama pada keempat proyek. Peneliti

memilih menggunakan metric Cyclomatic dengan alasan yang telah

disebutkan pada subbab 2.1.4.

77

3. Menghitung Nilai Value Adjustment Factor (VAF)

Nilai Value Adjustment Factor diperoleh menggunakan persamaan [3].

Contoh perhitungan VAF pada proyek Tanda Daftar Industri (TDId)

setelah dilakukan modifikasi pada General System Characteristic yang

merubah nilai TDI yaitu:

= 55 * 0.01 + 0.65

= 1.2

Sehingga nilai VAF pada proyek Tanda Daftar Industri (TDId) yaitu

1.2. Nilai tersebut diperoleh dari Total Degree Influence dengan nilai 55

karena setelahh dimodifikasi faktor ke-15 masuk dalam skala 1. Hasil TDI

yang telahh dimodifikasi dikalikan dengan 0.01 dan dijumlahkan dengan

0.65.

4. Menghitung Adjusted Funtion Point (AFP)

Perhitungan nilai AFP serupa dengan Original Function Point, yaitu

diperoleh dengan menggunakan persamaan [1]. Contoh perhitungan AFP

pada proyek Tanda Daftar Industri (TDId) yaitu:

= 198 * 1.2

= 237.6

Sehingga nilai AFP atau ukuran dari proyek Tanda Daftar Industri

(TDId) yaitu 237.6 FP (Function Point).

3.2.3 Estimasi Biaya

Beberapa tahap dalam melakukan estimasi biaya yaitu menentukan aktivitas

proyek perangkat lunak yang dikembangkan, distribusi persentase per aktivitas,

effort per proyek, effort per aktivitas, pay rate masing-masingtim proyek, dan

menentukan cost per aktivitas. Langkahnya yaitu sebagai berikut:

1. Menghitung Effort per Proyek

Untuk mengubah nilai Function Point atau ukuran perangkat lunak

menjadi effort, nilai FPA harus dikalikan dengan Effort Rate (ER) yaitu

78

8.2 man-hours dengan menggunakan persamaan [4]. Contoh perhitungan

effort per proyek pada proyek Tanda Daftar Industri (TDId) yaitu:

Effort = FPA x ER

= 235.62 X 8.2

= 1932.084

Hasil perhitungan effort per proyek dari keempat proyek yaitu ditunjukkan

pada Tabel

Tabel 3. 13 Manualisasi Effort per Proyek

Nama Proyek Function

Point ER Effort

TDI 235.62 8.2 1932.084

IUI 253.47 8.2 2078.454

PP 250.38 8.2 2053.116

TDP 229.9 8.2 1885.18

2. Menentukan Effort per Aktivitas

Nilai effort per aktivitas digunakan untuk mengetaui aktivitas yang

digunakan untuk melengkapi proyek pengembangan perangkat lunak.

Dalam penelitian ini menggunakan daftar aktivitas yang disediakan oleh

Primandari (Primandari, 2015) beserta persentase distribusi effort per

aktivitasnya yang ditunjukkan pada Tabel

Tabel 3. 14 Manualisasi Distribusi Effort per Aktivitas

No Activity % Project Name (Person-hours)

TDI IUI PP TDP

Software Development phase

1 Requirements 1.17% 22.6 24.3 24.0 22.1

2 Specifications 6.75% 130.4 140.3 138.6 127.2

3 Design 5.57% 107.6 115.8 114.4 105.0

4 Implementation 55.65% 1075.2 1156.7 1142.6 1049.1

5 Integration

Testing 6.42% 124.0 133.4 131.8 121.0

6 Acceptance &

deployment 5.60% 108.2 116.4 114.97 105.6


7 Project

management 2.55% 49.3 53.0 52.4 48.1

79


TDI IUI PP TDP

8 Configuration

management 3.58% 69.2 74.4 73.5 67.5

9 Quality assurance 0.66% 12.8 13.7 13.6 12.4

10 Documentation 9.76% 188.6 202.9 200.4 183.99

11 Training &

support 0.62% 11.97 12.9 12.7 11.7

12 Evaluation &

testing 1.67% 32.3 34.7 34.3 31.5

Total 100.00% 1932.1 2078.5 2053.1 1885.2

Untuk memperoleh nilai effort per aktivitas yaitu dengan mengalikan

persentase effort per aktivitas dengan nilai effort per proyek. Contoh

perhitungan pada proyek TDId pada aktivitas requirement yaitu:

Effort per aktivitas = Disribusi Efforti (%) x Effort per Proyek

= 1.17% x 1932.084

= 22.6

(i) Aktivitas ke 1 – 12

Perhitungan tersebut berlaku hingga ke-12 aktivitas pada masing-masing

proyek dan jika dijumlahkan akan menghasilkan nilai yang serupa dengan

effort per proyek.

3. Pay Rate per Posisi Tim Proyek

Pay rate diperoleh dari pay rate yang diterapkan di suatu Negara. Pada

penelitian ini peneliti menggunakan pay rate yang dirilis oleh KellyService

(KellyService, 2013) dan Inkindo (Inkindo, 2013) untuk index region. Pay

rate untuk masing-masing posisi dalam tim proyek yaitu ditunjukkan pada

Tabel

Tabel 3. 15 Pay Rate per Tim Proyek

Position in

project team

Minimum

requirement

Person

Month Rate

(PMR)

Person

Week Rate

(PWR)

Person

Day

Rate

(PDR)

Person

Hours

Rate

(PHR)

Project

manager

minimal

undergraduate

and experience ≥

3 years

7,000,000 1,707,317 85,366 13,872

80

Position in

project team

Minimum

requirement

Person

Month Rate

(PMR)

Person

Week Rate

(PWR)

Person

Day

Rate

(PDR)

Person

Hours

Rate

(PHR)

System

analyst

minimal

undergraduate

and experience >

1 years

4,000,000 975,610 48,780 7,927

Software

Tester

Experience 1-2

years 4,000,000 975,610 48,780 7,927

Senior

Programmer

Experience 1-2

years 5,000,000 1,219,512 60,976 9,909

Junior

Programmer

Experience 1-2

years 3,000,000 731,707 36,585 5,945

Documenter Experience 1-2

years 2,000,000 487,805 24,390 3,963

Pada table merupakan gaji yang diperoleh dari setiap posisi dalam team

pengembang proyek. Gaji masing-masing team dibagi menjadi gaji per

bulan (PMR), per minggu (PWR), per hari (PDR) dan per jam (PHR) yang

dihitung menggunakan persamaan [5]. Contoh perhitungan pay rate untuk

posisi Project Manager yaitu Person Month Rate (PMR) dengan pay rate

Rp. 7.000.000. Untuk memperoleh Person Week Rate (PWR) dengan

persamaan [5] yaitu Rp. 7.000.000 / 4.1 = 1,707,317. Person Day Rate (PDR)

diperoleh dengan rumus PDR = (PMR / 22) x 1.1, sehingga untuk Project

Manager yaitu PDR = (1,707,317 / 22) x 1.1 = 85,366. Akhirnya Person Hour

Rate diperoleh dengan menggunakan formula PHR = (PDR / 8) x 1.3 [5],

sehingga PHR = 13,872 (ditunjukkan pada Tabel baris ke-1).

4. Cost Per Aktivitas

Cost atau biaya per aktivitas diperoleh dengan menggunakan persamaan

Effort per activitas x pay rate x index, dimana pay rate yang digunakan

berdasarkan pada PHR (Person Hour Rate)

Tabel 3. 16 Manualisasi Cost per Aktivitas

No Activities

Pay Rate

(IDR/hour)

index=1

Project ID (IDR)

TDI IUI PP TDP

Index 1.02 1.02 1.02 1.02

81

No Activities

Pay Rate

(IDR/hour)

index=1

Project ID (IDR)

TDI IUI PP TDP

Index 1.02 1.02 1.02 1.02


1 Requirements 52,020 1,199,451 1,290,318 1,274,588 1,170,332

2 Specifications 52,020 6,919,908 7,444,143 7,353,393 6,751,917

3 Design 52,020 5,710,205 6,142,797 6,067,911 5,571,582

4 Implementation 22,591 24,775,749 26,652,700 26,327,783 24,174,284

5 Integration

Testing 19,322 2,444,631 2,629,830 2,597,770 2,385,284

6 Acceptance &

deployment 19,322 2,132,388 2,293,933 2,265,968 2,080,622


7 Project

management 63,910 3,211,701 3,455,012 3,412,893 3,133,733

8 Configuration

management 52,020 3,670,114 3,948,153 3,900,022 3,581,017

9 Quality

assurance 19,322 251,317 270,356 267,061 245,216

10 Documentation 8,620 1,657,995 1,783,601 1,761,857 1,617,745

11 Training &

support 10,305 125,912 135,450 131,176 122,855

12 Evaluation &

testing 19,322 635,909 684,084 675,744 620,471

Total

52,735,280 56,730,377 56,036,165 51,455,059

Pay rate pada table merupakan pay rate dengan index = 1 yang

berdasarkan pada (Inkindo, 2013) merupakan payrate yang diterapkan di Jakarta,

sementara di provinsi lain pay rate harus dikalikan dengan index provinsi yang

sesuai. Karena proyek ini dikembangakan di Surabaya, maka index untuk provinsi

Jawa Timur yaitu 1.02. Contoh perhitungan aktivitas requirement pada proyek

TDId yaitu

Cost per Activities = Effort per activitas x pay rate (index=1) x index

= 22.6 x 52,020 x 1.02

82

= 1,199,451.

Perhitungan tersebut berlaku pada seluruh aktivitas pada masing-masing proyek.

Hasil dari perhitungan ini yaitu merupakan harga pokok produksi dari masing-

masing proyek perangkat lunak.

3.3 Timeline Penelitian

Penelitian ini rencananya akan dilakukan dalam kurun waktu kurang lebih

5 (lima) bulan, yaitu dari bulan Februari hingga Juni 2018. Rincian rencana

kegiatan penelitian ditunjukkan pada table 3.1:

Tabel 3. 17 Timeline Penelitian

Nama Kegiatan Februari Maret April Mei Juni

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

Identifikasi Topik

Penelitian

Studi Literatur

Penyusunan Latar

Belakang,

Perumusan

Masalah, Tujuan,

dan Batasan

Rancangan

Sistematika

metode penelitian

Pengumpulan

Data

Analisis Data

Implementasi

Pengujian

Penyusunan Hasil

dan pembahasan

Penyusunan

Kesimpulan

Pembuatan

Laporan

83

BAB IV

KONSEPTUAL MODEL

Pada bab ini menjabarkan model konseptual modifikasi metode function

point dengan kompleksitas proses bisnis. Metode function point fokus pada

pengukuran perangkat lunak, kemudian ditambahkan kompleksitas proses bisnis

pada 14 faktor kompleksitas function point. Sehingga, kompleksitas proses bisnis

menjadi faktor yang ke-15. Sedangkan proses bisnis lebih fokus pada aktivitas

kompleks yang ada didalamnya.

4.1 Konseptual Model

Konseptual model modifikasi function point dengan kompleksitas proses

bisnis berawal dari kerangka berpikir yang ditunjukkan pada gambar 4.1

Gambar 4. 1 Konseptual Model

84

Tahap-tahap untuk mendapatkan nilai dari function point yaitu menentukan

nilai UFP (Unadjusted Function Point) yang diperoleh dari pembobotan lima

komponen fungsional sistem yaitu EI (External Input), EO (External Output), EQ

(External Inquiry), ILF (Internal Logic File), dan EIF (External Interface File).

Langkah selanjutnya yaitu menentukan nilai AFP (Adjusted Function Point) yang

diperoleh dari perkalian UFP (Unadjusted Function Point) dengan VAF (Value

Adjustement Factor). Nilai VAF diperoleh dari nilai TDI (Total Degree Influence)

dikalikan dengan 0.01 dan jumlahkan dengan 0.65. Nilai TDI diperoleh dari

penjumlahan skor 14 faktor kompleksitas atau Geberal System Characteristic

(GSC). Pada penelitian ini GSC inilah yang akan dimodifikasi dengan

menambahkan kompleksitas proses bisnis dan menjadi faktor ke-15 dari GSC.

Namun berbeda dengan keempatbelas faktor lainnya, kompleksitas proses bisnis

dimodelkan menggunakan BPMN (Business Process Management Notation).

Sedangkan nilainya dihitung menggunakan metric komplekasitas seperti

Cyclomatic, NOA(C/JS), CNC dan Diameter. Hasil dari AFP merupakan nilai

dari Function Point. Kemudian nilai FP tersebut dikonversi dalam bentuk rupiah

agar didapatkan harga perangkat lunak yang dihitung dan dilakukan pengujian.

Pengujian yang dilakukan yaitu dengan membandingkan harga perangkat lunak

dengan Function Point, Modifikasi Function Point dan Actual Cost-nya.

4.2 Function Point

Perhitungan ukuran perangkat lunak secara keseluruhan menggunakan

metode function point. Bagian yang dimodifikasi atau dikalibrasi dengan

kompleksitas proses bisnis yaitu pada General System Characteristics (GSC).

Peneliti memodifikasi Function Point dengan menambahkan Kompleksitas proses

bisnis pada GSC (General System Characterictics) karena pembobotan atau

scoring level kompleksitas masih ditentukan secara subyektif oleh pakar,

pendekatan ini menjadi tidak akurat karena dipengaruhi oleh emosi, opini, dan

pengalaman pakar. Peneliti bermaksud mengevaluasi GSC secara kuantitatif yang

diharapkan dapat memberikan value bagi hasil perhitungan function point. Nilai

dari function point merupakan ukuran dan satuan ukuran dari perangkat lunak

85

yang dihitung serta merupakan titik awal dalam memperoleh hasil perhitungan

effort dan biaya.

4.3 Kompleksitas Proses Bisnis

Kompleksitas dikelola dengan memodelkan proses bisnis seperti peta

proses dan diagram. Pemodelan kompleksitas proses bisnis divisualisasikan

dengan menggunakan BPMN (Business Process Management Notation).

Kompleksitas suatu perangkat lunak berbeda dengan perangkat lunak lainnya

(Pradani, 2013). Selain itu, karena kompleksitas harus proporsional dengan effort

proyek berdasarkan dengan pendekatan: “semakin kompleks suatu perangkat

lunak semakin besar effort yang harus dikeluarkan” (Xiaa and Capretz, 2009)

maka tentu biaya yang dikeluarkan juga semakin besar. Kompleksitas

berpengaruh besar terhadap nilai suatu effort perangkat lunak yang dikembangkan

(Suharjito and Widodo, 2006) serta faktor kompleksitas kurang relevan sehingga

modifikasi diperlukan berdasarkan kebutuhan perangkat lunak (Sari and Pribadi,

2018). Oleh karena itu, FPA harus didukung dengan data tambahan untuk

memperkuat pengukuran perangkat lunak yang dikembangkan (Pratiwi, 2013).

Kompleksitas dari suatu proses bisnis menghasilkan kebutuhan yang

kompleks dalam pengembangan perangkat lunak (Yunis, Surendro, and

Telaumbanua, 2010). Oleh karena itu semakin besar atau kompleks kebutuhan

pengembangan perangkat lunak, maka semakin besar pula usaha dan biaya yang

dikeluarkan. Tentunya harga perangkat lunak yang dihasilkan, bernilai tinggi

sesuai dengan level kompleksitas proses bisnisnya. Menurut salah satu project

manager suatu softwarehouse, proses bisnis suatu organisasi berbeda satu dengan

yang lain, begitu pula kompleksitas proses bisnisnya. Perbedaan kompleksitas

proses bisnis tersebut mempengaruhi ukuran dari perangkat lunak yang

dikembangkan (Dwi Lanang, 2018).

4.4 Estimasi Harga

Estimasi biaya perangkat lunak meliputi satu atau lebih dari 1) Effort; 2)

Durasi Proyek dan 3) Biaya (Leung et al, 2002). Panduan untuk mengalokasikan

biaya dan sumber daya dalam perhitungan perangkat lunak dalam penelitian ini

terdapat tiga aktivitas.

86

Pertama, aktivitas berkesinambungan (Ongoing Activities) yang meliputi

Project Management ialah PM melakukan kegiatan yang berhubungan dengan

manajemen proyek meliputi memantau kemajuan proyek secara ketat, melaporkan

manajemen resiko, memperbarui jadwal proyek secara berkala, Configuration

Management ialah melakukan pemeliharaan, pengelolaan, pengendalian dan

pengembangan perangkat lunak. Idealnya kegiatan tersebut dilakukan dengan

menggunakan alat konfigurasi otomatis yang memperbarui status secara berkala,

Documentation ialah membuat buku manual instalasi, operasi atau template

standar dan Training & Support, pada fase ini tim pengembang membutuhkan

beberapa dukungan teknis dan pelatihan dalam memecahkan masalah teknis yang

mungkin terjadi guna meningkatkan efisiensi dan produktifitas. Membutuhkan

sekitar 21% dari total Effort. Biaya yang berkaitan dengan aktivitas ini disebut

biaya ongoing activity (𝐵 ).

Kedua, aktivitas yang berkaitan dengan kualitas dan pengujian (Quality

and Testing) meliputi Integration Testing ialah melakukan uji integrasi antara

modul, sistem dan komponen eksternal. Kemudian melakukan hasil analisis dan

menangani masalah yang terjadi. Milestone dari fase ini adalah perangkat lunak

terintegrasi, Quality Assurance ialah memastikan seluruh aktivitas yang terjadi

pada setiap fase telah sesuai dengan standar internal dan menghasilkan

deliverables yang benar dan Evaluation & Testing ialah melakukan kegiatan

evaluasi dan pengujian, termasuk kegiatan validasi dan verifikasi. Proses ini

dilakukan oleh tim pengembang. Membutuhkan sekitar 37% dari total usaha.

Biaya yang berkaitan dengan aktivitas ini disebut biaya kualitas dan pengujian

(𝐵𝑘 ).

Ketiga, aktivitas pengembangan perangkat lunak (Software Development)

meliputi analisis kebutuhan, perancangan, implementasi (coding phase), dan tidak

termasuk pengujian integrasi. Membutuhkan sekitar 42% dari total usaha. Biaya

yang berkaitan dengan aktivitas ini disebut biaya pembuatan perangkat lunak

(𝐵 𝑙) (Saleh, 2011).

87

Estimasi biaya pengembangan perangkat lunak dapat dihitung

menggunakan persamaan 4. Nominal gaji untuk setiap karyawan mengacu pada

Indonesia Salary Survey 2017 yang diterbitkan oleh KellyServices.co.id.

4.5 Pengujian

Pengujian dilakukan dengan evaluasi Gap (kesenjangan) / selisih antara

estimasi yang dihitung menggunakan function poin dan modifikasi function point

dengan realisasi/actual cost-nya. Dari ketika perhitungan tersebut kemudian

dipilih perhitungan mana yang lebih akurat dipandang dari segi usaha, durasi dan

biayanya.

88


89

BAB V

HASIL DAN PEMBAHASAN

Implementasi dalam bab ini merupakan tindak lanjut dari Konseptual

Model pada Gambar 4.1 dan selanjutnya akan dilakukan perhitungan Functioin

Point Analysis (FPA) dan bentuk modifikasinya. Kemudian dilakukan

perhitungan estimasi biaya dan pengujian yang dilakukan dengan membandingkan

selisih atau Gap antara FPA, Modified FPA, dan Actual Cost-nya.

5.1 Function Point

Tahap-tahap dalam perhitungan Function Point Analysis (FPA) yaitu sebagai

berikut menghitung UFP, TDI, VAF dan terakhir adalah AFP.

5.1.1 Perhitungan Unadjusted Function Point

Berdasarkan rumus perhitungan yang ditunjukkan pada Subbab 2.1.2.9,

berikut perhitungan aplikatif Unadjusted Function Point (UFP) untuk keempat

proyek perangkat lunak yang dibangun oleh perusahaan. Tabel 5.1 menunjukkan

rincian nilai penyusun UFP yaitu EI, EO, EQ, ILF, dan EIF untuk masing-masing

proyek pengembangan perangkat lunak.

Table 5. 1 Unadjusted Function Point

No Nama Proyek Jumlah Komponen

Nilai EI EO EQ ILF EIF

1 Tanda Daftar Industri 24 8 7 16 2 198

2 Ijin Usaha Industri 24 8 7 19 2 213

3 Persetujuan Prinsip 24 8 7 19 2 214

4 Tanda Daftar Perusahaan 20 8 6 16 2 190

Pada tabel 5.1 pada kolom nilai merupakan nilai dari UFP yang mana

perhitungannya lebih jelas dapat dilihat pada lampiran A. Untuk proyek Tanda

Daftar Industri menghasilkan nilai UFP sebesar 198, IUI sebesar 213, PP sebesar

214 dan TDP sebesar 190.

90

5.1.2 Perhitungan Total Degree Influences (TDI)

TDI (Total Degree Influence) adalah jumlah seluruh nilai dari 14 kriteria

General System Characteristics (GSC) yang merupakan skor sistem dari

perangkat lunak yang diukur. Berdasarkan perhitungan pada subbab 3.2, maka

hasil perhitungan TDI ditunjukkan pada tabel 5.2

Table 5. 2 Total Degree Influence

No GSC Nama Proyek

TDId IUI PP TDP















Total Degree Influence 54 54 52 56

Pada tabel 5.2 dapat dilihat bahwa nilai Total Degree Influence pada

masing-masing proyek yaitu: TDId=54, IUI=54, PP=52 dan TDP=56. Penilaian

GSC dilakukan oleh System Analyst proyek perangkat lunak. Sedangkan nilai

Total Degree Influence diperoleh dari menjumlakan nilai dari 14 faktor GSC.

5.1.3 Perhitungan Nilai AFP

Nilai dari AFP mengindikasikan nilai dari Function Point yang merupakan

ukuran dari proyek perangkat lunak yang diukur. AFP diperoleh dari perkalian

91

antara Value Adjusted Point (VAF) dan Unadjusted Function Point (UFP)

berdasarkan contoh perhitungan yang ditunjukkan pada Subbab 3.2. Nilai AFP

masing-masing proyek ditunjukkan pada tabel 5.3

Table 5. 3 Adjusted Function Point

No Nama Proyek VAF AFP

1 Tanda Daftar Industri 1.19 235.62

2 Ijin Usaha Industri 1.19 253.47

3 Persetujuan Prinsip 1.17 250.38

4 Tanda Daftar Perusahaan 1.21 229.9

Pada tabel 5.3 dapat dilihat nilai AFP dari masing-masing proyek. Nilai

AFP merupakan nilai akhir dari Function Point yang mana merupakan ukuran dari

proyek yang diestimasi. Nilai AFP pada masing-masing proyek yaitu

TDId=235.62, IUI=253.47, PP=250.38 dan TDP=229.9

5.2 Modified Function Point

Modifikasi pada metode function point yaitu dengan menambakan

kompleksitas proses bisnis pada 14 faktor General System Characteristic-nya

(GSC). Terdapat 8 proses bisnis pada proyek perijinan TDId, IUI, PP maupun

TDP. Keempat proyek ini memiliki proses bisnis yang sama dikarenakan keempat

proyek tersebut sama-sama proyek perijinan yang saling terintegrasi, namun

sedikit berbeda pada proyek TDP. Proses bisnis tersebut dimodelkan dengan

model BPMN (Business Process Management Notation) menggunakan aplikasi

Bizagi. Setiap proses bisnis, dalam menentukan kompleksitasnya dihitung

menggunakan metric kompleksitas yaitu Cycomatic, NOA(C/JS), CNC, dan

diameter. Berdasarkan contoh perhitungan pada subbab 3.2, nilai kompleksitas

proses bisnis keempat proyek ditunjukkan pada table 5.4 dan 5.5

Table 5. 4 Nilai Kompleksitas Proses Bisnis pada TDId, IUI, dan PP

Metric Nilai

Cyclomatic 14

NOA 56

92

Metric Nilai

NOAC=NOAJS 79

CNC 7.42

Diameter 72

Pada tabel 5.4 merupakan proses bisnis dari keempat proyek yang

memiliki proses bisnis yang sama. Meski memiliki proses bisnis yang serupa,

namun konten dalam proses bisnis pada masing-masing proyek tentu berbeda.

Selain itu, terdapat perbedaan pada proses bisnis dengan kode (5) atau

Permohonan Baru proyek TDP. Namun, untuk proses bisnis yang lain tetap sama

berlaku pada semua proyek Sedangkan proses bisnis dari proyek TDP ditunjukkan

pada tabel 5.5

Table 5. 5 Nilai Kompleksitas Proses Bisnis pada TDP

Metric Nilai

Cyclomatic 16

NOA 58

NOAC=NOAJS 82

CNC 7.50

Diameter 74

5.2.1 Mengkonversi Nilai Kompleksitas Proses Bisnis

Setelah memperoleh nilai kompleksitas pada masing masing metric, tahap

selanjutnya yaitu mengkonversi nilai kompleksitas tersebut dalam bentuk skala

indeks. Hal tersebut agar kompleksitas proses bisnis dapat menyesuaikan dengan

skala Likert pada 14 faktor pada GSC (General System Caracteristic). Hasil

konversi kompleksitas proses bisnis pada metode ini ditunjukkan pada table 5.6

Table 5. 6 Hasil Konversi Nilai Kompleksitas

Metric Indeks

Cyclomatic 14 – 14.4 = 1

14.5 – 14.9 = 2

93

Metric Indeks

15 – 15.4 = 3

15.5 – 15.9 = 4

16 – 16.4 = 5

NOA

56 – 56.4 = 1

56.5 – 56.9 = 2

57 – 57.4 = 3

57.5 – 57.9 = 4

58 – 58.4 = 5

NOAC/JS

79 – 79.6 = 1

79.7 – 80.3 = 2

80.4 – 81 = 3

81.1 – 81.7 = 4

81.8 – 82.4 = 5

CNC

7.42 – 7.436 = 1

7.437 – 7.453 = 2

7.454 – 7.470 = 3

7.471 – 7.487 = 4

7.488 – 7.504 = 5

Diameter

72 – 72.4 = 1

72.5 – 72.9 = 2

73 – 73.4 = 3

73.5 – 73.9 = 4

74 – 74.4 = 5

5.2.2 Menghitung Modified Function Point

Setelah memperoleh nilai kompleksitas proses bisnis dan indeksnya,

selanjutnya yaitu menerapkannya pada perhitungan function Point dengan

menginputkan nilai-nilai yang hasil modifikasi.

1. Nilai Total Degree Influence (TDI)

94

Nilai TDI diperoleh dari jumlah 14 faktor pada General System Characteristic

(GSC), namun karena dimodifikasi dengan menambahkan satu faktor lagi

sehingga menjadi 15 faktor GSC. Berdasarkan nilai kompleksitas dan indeks

yang telah ditentukan, hasilnya pada masing masing proyek ditunjukkan pada

tabel. Pada contoh perhitungan kompleksitas proses bisnis dalam subbab 3.2,

masing-masing proyek dihitung dengan menggunakan metric Cyclomatic,

NOA(C/JS), CNC dan Diameter memperoleh hasil yang sama pada keempat

proyek. TDI = 1; IUI = 1; PP = 1; dan TDP = 5

Table 5. 7 Modified TDI


TDId IUI PP TDP















15 Business Process Complexity 1 1 1 5

Modified Total Degree of Influence

= 55 55 53 61

Pada tabel 5.7 dapat dilihat hasil Total Degree Influence yang telah

dimodifikasi. Hasil TDI diperoleh dengan menjumlahkan 14 faktor dari GSC

ditambah dengan 1 nilai kompleksitas proses bisnis yang diperoleh dari

perhitungan sebelumnya. Nilai kompleksitas proses bisnis pada proyek

TDI=1, IUI=1, PP=1 dan TDP=5. Sehingga hasilnya menjadi: TDId=55,

IUI=55, PP=53 dan TDP=61.

2. Menghitung Adjusted Function Point

95

Sebelum menentukan nilai AFP, maka sebelumnya menghitung nilai UFP.

Pada tahap ini nilai UFP yang digunakan sama dengan perhitungan original

function point. Namun pada rumus, nilai TDI menggunakan nilai hasil

modifikasi, dan hasil nilai VAF dikalikan dengan nilai UFP untuk

memperoleh nilai AFP. Berdasarkan contoh perhitungan pada subbab 3.2,

sehingga hasil perhitungan AFP pada masing-masing proyek yaitu:

a. TDId

Proyek TDId menghasilkan nilai AFP sebesar 237.6. Perhitungan dengan

seluruh metric kompleksitas proses bisnis hanya berpengaruh incidental

yaitu bernilai 1 pada TDId. Sehingga semula bernilai 54, kini menjadi 55.

Sedangkan nilai AFP sebelumnya 235.62 kini menjadi 237.6

Table 5. 8 Modified AFP pada Proyek TDId

Nilai TDI (X) (+) Hasil

UFP VAF

55 0.01 0.65 1.2

198 1.2

Nilai VAF Modified

237.6

b. IUI

Proyek IUI menghasilkan nilai AFP sebesar 255.6. Perhitungan dengan


yaitu bernilai 1 pada IUI. Sehingga semula bernilai 54, kini menjadi 55.


Table 5. 9 Modified AFP pada Proyek IUI


UFP VAF

55 0.01 0.65 1.2

213 1.2

Nilai VAF Modified

255.6

c. PP

Proyek PP menghasilkan nilai AFP sebesar 252.52. Perhitungan dengan


yaitu bernilai 1 pada PP. Sehingga semula bernilai 52, kini menjadi 53.


96

Table 5. 10 Modified AFP pada Proyek PP


UFP VAF

53 0.01 0.65 1.18

214 1.18

Nilai VAF Modified

252.52

d. TDP

Proyek TDP menghasilkan nilai AFP sebesar 239.4. Perhitungan dengan

metric Cyclomatic, NOA(C/JS), dan diameter kompleksitas proses bisnis

berpengaruh kuat keseluruhan dengan bernilai 5 pada TDP. Sehingga

semula bernilai 56, kini menjadi 61. Sedangkan nilai AFP sebelumnya

229.9 kini menjadi 239.4 hasilnya ditunjukkan pada table 5.11

Table 5. 11 Modified AFP pada Proyek TDP


UFP VAF

61 0.01 0.65 1.26

190 1.26

Nilai VAF Modified

239.4

5.3 Estimasi Biaya

Setelah memperoleh nilai function point atau ukuran dari perangkat lunak

yang diestimasi, selanjutnya melakukan estimasi biaya dengan tahap: menghitung

nilai effort per proyek, nilai effort per aktivitas, menentukan gaji atau pay rate per

aktivitas, dan yang terakhir yaitu menghitung cost per aktivitas untuk memperoleh

harga pokok produksinya.

5.3.1 Nilai Effort

Tahap ini digunakan untuk memperoleh nilai effort dalam person-hour.

Nilai effort diperoleh dari perkalian nilai Function Point denan konstanta ER.

Dalam penelitian ini nilai konstanta ER yaitu = 8.2 man-hour. Berdasarkan contoh

perhitungan pada subbab 3.2, hasil nilai effort untuk masing-masing proyek


Table 5. 12 Nilai Effort per Proyek


Point ER Effort

TDId 235.62 8.2 1932.084

IUI 253.47 8.2 2078.454

PP 250.38 8.2 2053.116

97


Point ER Effort

TDP 229.9 8.2 1885.18

Pada tabel 5.12 dapat dilihat bahwa nilai effort masing-masing proyek yaitu

TDId=1932.048, IUI=2078.454, PP=2053.116, dan TDP=1885.18

5.3.2 Nilai Effort per aktivitas

Tahap ini digunakan untuk mengidentifikasi aktivitas yang dilakukan

dalam melengkapi proyek pengembangan perangkat lunak. Aktivitas yang

dibutuhkan untuk melengkapi proyek tergantung pada model pengembangan yang

digunakan. Dalam penelitian ini menggunakan daftar aktivitas yang disediakan

oleh Primandari (Primandari, 2015) beserta persentase distribusi effort per

aktivitasnya yang ditunjukkan pada table 5.13. Untuk memperoleh nilai effort per

aktivitasnya yaitu mengalikan effort per proyek dengan persentase effort per

aktivitas. Berdasarkan contoh perhitungan pada subbab 3.2, sehingga hasil effort

per aktivitas dapat dilihat pada table 5.13.

Table 5. 13 Nilai Effort per Aktivitas


TDId IUI PP TDP


1 Requirements 1.17% 22.6 24.3 24.0 22.1

2 Specifications 6.75% 130.4 140.3 138.6 127.2

3 Design 5.57% 107.6 115.8 114.4 105.0

4 Implementation 55.65% 1075.2 1156.7 1142.6 1049.1

5 Integration

Testing 6.42% 124.0 133.4 131.8 121.0

6 Acceptance &

deployment 5.60% 108.2 116.4 114.97 105.6


7 Project

management 2.55% 49.3 53.0 52.4 48.1

8 Configuration

management 3.58% 69.2 74.4 73.5 67.5

9 Quality assurance 0.66% 12.8 13.7 13.6 12.4

10 Documentation 9.76% 188.6 202.9 200.4 183.99

11 Training &

support 0.62% 11.97 12.9 12.7 11.7

98


TDId IUI PP TDP

12 Evaluation &

testing 1.67% 32.3 34.7 34.3 31.5

Total 100.00% 1932.1 2078.5 2053.1 1885.2

5.3.3 Pay Rate per Position

Pada tahap ini posisi menentukan pay rate atau gaji per aktivitas. Gaji

diperoleh dari standar gaji yang diterapkan di suatu negara. Pada penelitian ini

standar gaji yang digunakan yaitu KellyService Salary Guide (Kelly Services,

2013). Pada table 5.14 merupakan gaji yang diperoleh dari setiap posisi dalam

team pengembangan proyek. Gaji masing-masing team dibagi menjadi gaji per

bulan (PMR), per minggu (PWR), per hari (PDR) dan per jam (PHR) yang

dihitung menggunakan persamaan [5].

Table 5. 14 Pay Rate per Position

Position in

project team

Minimum

requirement

Person

Month Rate

(PMR)

Person

Week Rate

(PWR)

Person

Day

Rate

(PDR)

Person

Hours

Rate

(PHR)

Project

manager

minimal

undergraduate

and experience >

3 years

7,000,000 1,707,317 85,366 13,872

System

analyst

minimal

undergraduate

and experience >

1 years

4,000,000 975,610 48,780 7,927

Software

Tester

Experience 1-2

years 4,000,000 975,610 48,780 7,927

Senior

Programmer

Experience 1-2

years 5,000,000 1,219,512 60,976 9,909

Junior

Programmer

Experience 1-2

years 3,000,000 731,707 36,585 5,945

Documenter Experience 1-2

years 2,000,000 487,805 24,390 3,963

99

5.3.4 Cost per Aktivitas

Tahap ini digunakan untuk menentukan cost per aktivitas. Cost atau biaya

per aktivitas dihitung dengan Effort per activitas x pay rate x index, dimana pay

rate yang digunakan berdasarkan pada PHR (Person Hour Rate). Berdasarkan

contoh perhitungan pada subbab 3.2, hasil perhitungan cost per aktivitas dapat

dilihat pada table 5.15

Table 5. 15 Cost Per Aktivitas

No Activities

Pay Rate

(idr/hour)

index=1

Project ID (IDR)

TDId IUI PP TDP

Index 1.02 1.02 1.02 1.02


1 Requirements 52,020 1,199,451 1,290,318 1,274,588 1,170,332

2 Specifications 52,020 6,919,908 7,444,143 7,353,393 6,751,917

3 Design 52,020 5,710,205 6,142,797 6,067,911 5,571,582

4 Implementation 22,591 24,775,749 26,652,700 26,327,783 24,174,284

5 Integration

Testing 19,322 2,444,631 2,629,830 2,597,770 2,385,284

6 Acceptance &

deployment 19,322 2,132,388 2,293,933 2,265,968 2,080,622


7 Project

management 63,910 3,211,701 3,455,012 3,412,893 3,133,733

8 Configuration

management 52,020 3,670,114 3,948,153 3,900,022 3,581,017

9 Quality

assurance 19,322 251,317 270,356 267,061 245,216

10 Documentation 8,620 1,657,995 1,783,601 1,761,857 1,617,745

11 Training &

support 10,305 125,912 135,450 131,176 122,855

12 Evaluation &

testing 19,322 635,909 684,084 675,744 620,471

Total

52,735,280 56,730,377 56,036,165 51,455,059

Pay rate pada table 5.15 merupakan pay rate dengan index = 1 yang

berdasarkan pada (Inkindo, 2013) merupakan payrate yang diterapkan di Jakarta,

sementara di provinsi lain pay rate harus dikalikan dengan index provinsi yang

sesuai. Karena proyek ini dikembangakan di Surabaya, maka index untuk provinsi

Jawa Timur yaitu 1.02. Total nilai keseluruhan dari keempat proyek yaitu sebesar

100

216,956,881. Nilai total tersebut merupakan hasil dari estimasi dengan

menggunakan metode Function Point.

5.4 Estimasi Biaya Hasil Modifikasi

Estimasi biaya dari keempat proyek yang telah dimodifikasi dengan

menambahkan kompleksitas proses bisnis pada GSC (General System

Characteristic). Dengan tahap yang serupa dengan estimasi biaya sebelumnya,

namun nilai yang diolah yaitu nilai hasil modifikasi.

5.4.1 Nilai Effort Hasil Modifikasi

Nilai effort dari masing masing proyek yang telah dimodifikasi dengan

menambahkan kompleksitas proses bisnis, dimana kompleksitasnya dihitung

dengan menggunakan metric Cyclomatic, NOA(C/JS), CNC dan Diameter

hasilnya ditunjukkan pada tabel 5.16. Perhitungan effort pada tahap ini serupa

dengan perhitungan effort pada function point biasa. Namun effort yang

dihasilkan tentu lebih tinggi. Hal tersebut karena dipengaruhi oleh kompleksitas

proses bisnis yang ditambahkan pada GSC. Sehingga mempengaruhi jumlah dari

Total Degree Influence yang tentu saja nilai dari AFP menjadi lebih tinggi.

Table 5. 16 Nilai Effort Hasil Modifikasi

Nama

Proyek

Function

Point ER Effort

TDId 237.6 8.2 1948.32

IUI 255.6 8.2 2095.92

PP 252.52 8.2 2070.664

TDP 239.4 8.2 1963.08

Pada tabel 5.16 dapat dilihat bahwa hasil effort masing-masing proyek

memiliki effort yang lebih tinggi dari estimasi function point sebelum

dimodifikasi. Nilai effort yang lebih tinggi dipengaruhi oleh nilai AFP atau

ukuran masing-masing proyek yang lebih tinggi dari sebelum dimodifikasi. Hal

tersebut karena semakin tinggi ukuran atau nilai AFP suatu proyek, akan

mempengaruhi nilai effort yang tentu juga akan semakin tinggi.

5.4.2 Nilai Effort per aktivitas hasil modifikasi

Pada tahap ini juga menggunakan cara yang serupa dengan nilai effort per

aktivitas pada original function point. Karena effort per proyek juga semakin

101

besar, setelah di breakdown per aktivitas juga tentu lebih besar dari nilai effort per

aktivitas sebelum di modifikasi

Table 5. 17 Nilai Effort per Aktivitas Hasil Modifikasi


TDId IUI PP TDP


1 Requirements 1.17% 22.79534 24.52226 24.22677 22.96804

2 Specifications 6.75% 131.5116 141.4746 139.7698 132.5079

3 Design 5.57% 108.5214 116.7427 115.336 109.3436

4 Implementation 55.65% 1084.24 1166.379 1152.325 1092.454

5 Integration

Testing 6.42% 125.0821 134.5581 132.9366 126.0297

6 Acceptance &

deployment 5.60% 109.1059 117.3715 115.9572 109.9325


7 Project

management 2.55% 49.68216 53.44596 52.80193 50.05854

8 Configuration

management 3.58% 69.74986 75.03394 74.12977 70.27826

9 Quality

assurance 0.66% 12.85891 13.83307 13.66638 12.95633

10 Documentation 9.76% 190.156 204.5618 202.0968 191.5966

11 Training &

support 0.62% 12.07958 12.9947 12.83812 12.1711

12 Evaluation &

testing 1.67% 32.53694 35.00186 34.58009 32.78344

Total 100.00% 1948.32 2095.92 2070.664 1963.08

5.4.3 Cost per Aktivitas hasil modifikasi

Cost atau biaya per aktivitas hasil modifikasi dihitung dengan Effort per

activitas hasil modifikasi x pay rate x index. Hasil perhitungan cost per aktivitas

hasil modifikasi dapat dilihat pada table 5.18

102

Table 5. 18 Cost per Aktivitas Hasil Modifikasi

No Activities

Pay Rate

(idr/hour)

index=1

Project ID (IDR)

TDId IUI PP TDP

Index 1.02 1.02 1.02 1.02


1 Requirements

52,020

1,209,530

1,301,161

1,285,482

1,218,693

2 Specifications

52,020

6,978,058

7,506,699

7,416,242

7,030,922

3 Design

52,020

5,758,190

6,194,417

6,119,774

5,688,052

4 Implementation

22,591

24,983,949

26,876,672

26,552,806

25,173,221

5 Integration

Testing

19,322

2,465,174

2,651,929

2,619,974

2,483,849

6 Acceptance &

deployment

19,322

2,150,308

2,313,209

2,285,335

2,166,598


7 Project

management 63,910

3,238,691

3,484,046

3,442,063

3,263,226

8 Configuration

management 52,020

3,700,955

3,981,331

3,933,355

3,728,993

9 Quality

assurance 19,322

253,429

272,628

269,343

255,349

10 Documentation 8,620

1,671,928

1,798,589

1,776,916

1,684,594

11 Training &

support 10,305

126,970

136,589

134,943

127,932

12 Evaluation &

testing 19,322

641,252

689,832

681,520

646,110

Total

53,178,434

57,207,103

56,517,753

53,467,540

Nilai total cost per aktivitas ini mengindikasikan nilai perangkat lunak hasil

modifikasi FPA. Nilai masing-masing proyeknya yaitu: TDId=55,178,434;

IUI=57,207,103; PP=56,517,753; dan TDP=53,467,540. Sehingga total nilai

keempat proyek yaitu 220.370.829

103

5.5 Evaluasi Gap Biaya

Untuk menganalisis gap atau kesenjangan, peneliti mengacu pada

penelitian sebelumnya yang dilakukan oleh (Carrol, 2005). Dalam penelitian

tersebut, dikatakan bahwa pentingnya dilakukan evaluasi gap untuk mengetahui

sejauh mana kesenjangan antara estimasi yang telah dihitung dengan realisasi atau

actual cost. Berdasarkan grafik yang ditunjukkan pada gambar 5.1, dapat dilihat

visualisasi gap antara nilai actual dan nilai dari perhitungan function point.

Gambar 5. 1 Grafik Perbandingan Actual Cost dengan Function Point

Pada gambar dapat dilihat perbedaan actual cost dan function point dimana

grafik berwarna biru mengindikasikan actual cost sedangkan yang berwarna

oranye mengindikasikan function point. Proyek TDId, IUI, dan PP memiliki

perbandingan harga yang lebih besar pada function point. Berbeda pada proyek

TDP yang mana nilai actual lebih besar dari function point. Evaluasi Gap antara

realisasi dengan estimasi menggunakan Function Point ditunjukkan pada tabel

5.19

Table 5. 19 Evaluasi Gap Antara Actual Coast dengan FPA

No Nama Proyek Actual Cost Function Point Gap

(%)

0

10.000.000

20.000.000

30.000.000

40.000.000

50.000.000

60.000.000

70.000.000

80.000.000

90.000.000

100.000.000

TDI IUI PP TDP

Actual Cost

Function Point

104

No Nama Proyek Actual Cost Function Point Gap

(%)

1 TDId 44,300,000 52,735,280 16.00 %

2 IUI 47,080,000 56,730,377 17.01 %

3 PP 46,800,000 56,036,165 16.48 %

4 TDP 91,500,000 51,455,059 43.76 %

Pada tabel 5.19 dapat dilihat bahwa 3 proyek yaitu TDId, IUI, dan PP

memperoleh nilai yang lebih tinggi masing-masing dengan selisih 16.00%,

17.01% dan 16.48% dibandingkan realisasi atau actual costnya. Sedangkan pada

proyek TDP, nilai hasil estimasi lebih rendah dengan selisih 43.76% dari actual

costnya. Karena TDP memiliki selisih yang besar (>30%), dimungkinkan adanya

indikasi kebutuhan sumber daya yang lebih banyak. Dibandingkan ketiga proyek

yang lain dimana hanya memakan waktu 2 bulan, durasi penyelesaian proyek

TDP memerlukan waktu penyelesaian selama 4 bulan. Hal tersebut tentu jelas

terdapat beban biaya yang lebih besar pada proyek TDP.

Dalam menentukan durasi pengembangan proyek terdapat beberapa

pertimbangan seperti kemampuan tim pengembang, jenis perangkat lunak yang

dikembangkan, serta ukuran perangkat lunaknya. Indikasi lain yaitu berkaitan

dengan kemampuan manajer proyek dalam melakukan analisis biaya, karena

peneliti tidak mengetahui metode cost estimation yang diterapkan oleh perusahaan

dalam menentukan biaya masing-masing proyek perangkat lunak. Namun jika

ditotal, persentase gap nilai total antara realisasi (229.680.000) dengan hasil

estimasi function (216.956.881) yaitu sebesar 5.54 %. Sehingga dapat dikatakan

metode Function Point akurat karena memiliki persentase gap yang kecil dan

mendekati nilai aktualnya yaitu kurang dari 9%.

Berdasarkan grafik yang ditunjukkan pada gambar 5.2, dapat dilihat

visualisasi gap antara nilai dari perhitungan Function Point dan Modifikasi dari

Function Point. Pada gambar 5.2 dapat dilihat perbedaan actual cost dan function

point dimana grafik berwarna biru mengindikasikan Function Point sedangkan

yang berwarna oranye mengindikasikan Modifikasi dari Function Point. Pada

105

GAP analisis antara Aktual Cost dengan Function Point, Proyek TDId, IUI, dan

PP memiliki perbandingan harga yang lebih besar pada function point, sedangkan

pada proyek TDP nilai actual lebih besar dari function point. Namun berbeda pada

perbandingan nilai antara unction Point dan Modifikasi dari Function Point

dimana pada keempat proyek memiliki perbandingan nilai yang lebih besar pada

nilai Modified Function Point. Hal tersebut dikarenakan beberapa faktor, namun

faktor utama yang mempengaruhi yaitu nilai karena ukuran perangkat lunak yang

dihitung dengan modifikasi FPA lebih besar daripada FPA biasa. Semakin besar

ukuran suatu perangkat lunak tentu menhasilkan nilai nominal yang lebih besar.

Gambar 5. 2 Grafik Perbandingan Function Point dan Modified FPA

Gap analysis antara nilai hasil estimasi FPA dengan modifikasi dari FPA

ditunjukkan pada tabel 5.20

Table 5. 20 Evaluasi Gap Antara FPA dengan Modified FPA

No Nama Proyek Function Point Modified

Function Point

Gap

(%)

1 TDId 52,735,280 53,178,434 0.83 %

2 IUI 56,730,377 57,207,103 0.83 %

3 PP 56,036,165 56,517,753 0.85 %

48.000.000

49.000.000

50.000.000

51.000.000

52.000.000

53.000.000

54.000.000

55.000.000

56.000.000

57.000.000

58.000.000

TDI IUI PP TDP

Function Point

Modified Function Point

106

No Nama Proyek Function Point Modified

Function Point

Gap

(%)

4 TDP 51,455,059 53,467,540 3.76 %

Pada tabel 5.20 dapat dilihat bahwa hasil estimasi menggunakan FPA yang

telah di modifikasi memperoleh nilai yang lebih besar dari FPA aslinya. Hal

tersebut dipengaruhi oleh nilai kompleksitas proses bisnis yang ditambahkan.

Meskipun nilai kompleksitas diukur menggunakan 5 metric yang berbeda, namun

tetap memberikan hasil yang sama pada keempat proyek. Kompleksitas proses

bisnis berpengaruh sebesar 0.83% pada proyek TDId, IUI dan PP sedangkan pada

proyek TDP berpengaruh sebesar 3.76%. Hal tersebut dikarenakan ukuran proyek

yang lebih besar setelah dimodifikasi. Total biaya setelah dimodifikasi yaitu

senilai 220,370,829; jika dibandingkan dengan actual cost-nya memiliki selisih

gap sebesar 4.05%. Nilai gap tersebut lebih kecil dibandingkan nilai gap Function

Point tanpa modifikasi. Hal tersebut dapat dikatakan bahwa modifikasi function

point lebih akurat dibandingkan Original Function Point. Sehingga jelas bahwa

kompleksitas proses bisnis sangat penting ditambahkan dalam melakukan analisis

biaya perangkat lunak. Hal tersebut supaya perusahaan terhindar dari kerugian

karena tidak melibatkan faktor penting dalam pengukuran perangkat lunak.

Hasil analisis secara keseluruhan yaitu biaya yang dihasilkan dari

penelitian ini merupakan harga pokok produksi sedangkan biaya actual proyek

merupakan harga jual dari perangkat lunak. Sehingga dapat dikatakan bahwa

estimasi dengan function point sangat akurat karena dengan nilai 216.056.881

merupakan harga pokok produksi, belum merupakan nilai jual perangkat lunak.

Sedangkan modified function point yang telah menambahkan unsur penting dalam

estimasi pengukuran perangkat lunak yaitu kompleksitas proses bisnis, dapat

meminimalisir atau mengurangi kerugian dari biaya seharusnya yang ditakutkan

dialami oleh perusahaan.

107

BAB VI

PENUTUP

Bab penutup ini berisi kesimpulan dan saran untuk penelitan yang akan

datang. Sehingga diharapkan penelitian ini dapat terus dikembangkan

kedepannya.

6.1 Kesimpulan

Kesimpulan yang dapat diambil dari penelitian ini yaitu sebagai berikut:

1. Modifikasi metode Function Point dengan menambahkan kompleksitas proses

bisnis pada General System Characteric-nya menghasilkan konsep modifikasi

baru pada Function Point. Modifikasi ini dapat digunakan sebagai salah satu

alternative metode perhitungan estimasi biaya pengembangan perangkat

lunak. Selain itu modifikasi ini dapat dijadikan sebagai evaluasi dari metode

Function Point khususnya pada GSC.

2. Hasil evalusi gap dari total biaya aktual dan estimasi dengan function point

yaitu 5.54%, sedangkan antara biaya aktual dengan Modified Function Point

sebesar 4.05%. Dengan nilai gap yang lebih kecil, dapat disimpulkan bahwa

modified Function Point lebih akurat dibandingkan dengan Original Function

Point. Sehingga jelas bahwa kompleksitas proses bisnis sangat penting

ditambahkan dalam melakukan analisis biaya perangkat lunak. Hal tersebut

supaya perusahaan terhindar dari kerugian karena tidak melibatkan faktor

penting dalam pengukuran perangkat lunak.

3. Dalam mengestimasi biaya perangkat lunak total biaya actual cost, hasil

estimasi dengan function point dan modifikasi function point masing-masing

bernilai 229.680.000, 216.956.881, dan 220.370.829. Estimasi biaya yang

dihasilkan dari penelitian ini merupakan harga pokok produksi sedangkan

biaya actual proyek merupakan harga jual dari perangkat lunak. Sehingga

dapat disimpulkan bahwa metode function point sangat akurat dalam

mengestimasi biaya perangkat lunak. Sedangkan modified function point lebih

akurat lagi dibandingkan function point biasa, karena telah menambahkan

unsur penting dalam pengukurannya yaitu kompleksitas prose bisnis. Dalam

108

hal ini, perusahaan dapat terhindar dari kerugian jika menerapkan modified

function point dalam melakukan estimasi biaya perangkat lunak.

4. Kontribusi praktis yang dihasilkan yaitu implementasi modifikasi function

point dengan menambahkan kompleksitas proses bisnis. Implementasi ini

bertujuan sebagai pengujian awal yaitu membandingkan modifikasi function

point dengan aktual costnya.

5. Selain kontribusi praktis, dalam penelitian ini juga terdapat kontribusi teoritis,

yaitu munculnya konsep baru dalam estimasi biaya perangkat lunak. Manajer

proyek dapat mengetahui unsur penting yang perlu ditambahkan dalam

melakukan estimasi agar terhindar dari kerugian.

6.2 Saran

Proyek pengembangan perangkat lunak yang digunakan pada penelitian ini

berasal dari satu perusahaan saja. Oleh karena itu, penulis mempercayakan pada

hasil pemikiran manajer proyek dalam menentukan seluruh keputusan maupun

perincian aktivitas didalamnya. Sehingga tingkat kedetilan aktivitas perencanaan

dalam pengembangan perangkat lunak bergantung pada pengalaman manajer

proyek dalam mengestimasi biaya per aktivitasnya.

Disamping itu, jenis aktivitas yang digunakan merupakan tantangan

tersendiri. Karena jenis aktivitasnya diperoleh dari penelitian lain (Shaleh, 2011),

sehingga masih perlu dikaji kembali kevalidan distribusi persentase tiap

aktivitasnya terhadap aktivitas yang sesungguhnya dalam proses pengembangan

perangkat lunak.

109

DAFTAR PUSTAKA

A. M. Latva-Koivisto, “Finding a complexity for business process models,”

Helsinki University of Technology, Tech. Rep., Feb 2001.

A. P. Subriadi, Sholiq and P. A. Ningrum, "Critical Review of The Effort Rate

Value in Use Case Point Method for Estimating Software Development

Effort," Journal of Theoretical and Applied Information Technology, vol.

59, no. 3, pp. 735-744, 31 January 2014.

Al-hajri, M. A. et al. (2005) „Modification of standard Function Point complexity

weights system‟, 74, pp. 195–206. doi: 10.1016/j.jss.2003.12.033.

Albrecht, A. J. (1983) „Software Function , Source Lines of Code , and

Development Effort Prediction : A Software Science Validation‟, (6).

Almudimigh. (2007) „The role and impact of business process management in

enterprise systems implementation‟. doi: 10.1108/14637150710834604.

Boehm, B. and Abts, C. (1998) „This paper is an extension of the work done by

Sunita Chulani as part of her Qualifying Exam report in partial fulfillment

of requirements of the Ph.D. program of the Computer Science department

at USC [Chulani 1998].‟

Boghdady, Pakinam N., Badr, Nagwa L., Hashem, Mohamed, and Tolba MFT. A

Proposed Test Case Generation Technique Based on Activity Diagrams.

Int J Eng Technol. 2011;11(3):37-57.

Borade, J. G. (2013) „International Journal of Advanced Research in Software

Project Effort and Cost Estimation Techniques‟, 3(8), pp. 730–739.

Carrol, E. R., 2005. Estimation Software Based on Use Case Points. San Diego,

ACM, P. 257-265

Chouhan C, Shrivastava V, S Sodhi P. Test Case Generation based on Activity

Diagram for Mobile Application. Int J Comput Appl. 2012;57(23):4-9.

doi:10.5120/9436-3563.

Connel, Mc., 2006. Software Edtimation: Demystifying Black Art. Washington:

Microsoft Press.

110

Daniel D. Galorath and Michael W. Evans, Software Sizing, Estimation, and Risk

Management: when Performance is measured Performance Improves, 1st

ed., Auerbach Publications, 2006.

DTS, 2013. Spesifikasi Kebutuhan Perangkat Lunak SIM Disperdagin. Surabaya:

CV DTS

Dwi Lanang - Project Manager SAM Design. Wawancara pada tanggal 2 Maret

2018

Gencel C. and Demirors O., Measuring the Software Functional Size as a Vector

of Measures, 2nd ed., Boston PWS Publishing, 2008.

Gilb, T.1988.Principle Of Software Engineering, Addison-Wesley.

Hannus, Jouko (1994): Prosessijohtaminen. Ydinprosessien uudistaminen ja

yrityksen suorituskyky. 4. painos, HM&V Research Oy, Gummerrus

Kirjapaino Oy, Finland.

Inkindo, "Remuneration/Billing Rate and Direct Cost for Consultancy Services,"

Inkindo, Jakarta, 2013.

ISPA (2008) Parametric Estimating Handbook, The International Society of

Parametric Analysis, Fourth Edition. Available at:

http://www.ispacost.org/PEIWeb/cover.htm.

J. Cardoso, “How to measure the control-flow complexity of web processes and

workflows,” in Workflow Handbook 2005, L. Fischer, Ed.Lighthouse

Point, Florida, USA: Future Strategies Inc., 2005, pp. 199–212.

J. Cardoso, J. Mendling, G. Neumann, and H. A. Reijers, “A discourse on

complexity of process models,” in Proceedings of the 2006 international

conference on Business Process Management Workshops, Vienna,

Austria, ser. BPM‟06, S. D. e. a. J. Eder, Ed. Berlin, Heidelberg: Springer-

Verlag, 2006, pp. 117–128.

K. Saleh, "Effort and Cost Allocation in Medium to Large Software Development

Projects," International Journal of Computers, vol. 5, no. 1, pp. 74-79,

2011.

KellyServices, 2013. Indonesia Salary Guide | Kelly Services. [online] Available

at: http://kellyservices.co.id [diakses 20 Mei 2018]

http://www.ispacost.org/PEIWeb/cover.htm

http://kellyservices.co.id/

111

Kluza, K. and Nalepa, G. J. (2012) „Proposal of Square Metrics for Measuring

Business Process Model Complexity‟, Federated Conference on Computer

Science and Information Systems 2012, pp. 919–922.

Koistinen, Timo (1997): Usability Engineering in Developing a Business Process

Modelling Software. Master‟s Thesis, Department of Computer Science,

Helsinki University of Technology.

Latva-Koivisto, A. M. (2001) „Finding a complexity measure for business process

models‟, Complexity, pp. 1–26. doi: 10.1.1.25.2991.

Leung, et al., 2002. Software Cost Estimation.[pdf]. Hong Kong: The Hong Kong

Polytechnic University.

Li, et al., 2009. A Study of Project Selection and Feature Weighting for Analogy

Based Software Cost Estimation.[pdf]. Singapore: National University of

Singapore.

Longstreet, D. (2005) „Function Points Analysis Training Course‟, Longstreet

Consulting Inc. Acessed, 2, p. 15. Available at:

http://www.poli.usp.br/d/pmr2490/fp_training.pdf.

Marthaler et al., 2005. Function Point Counting pratices Manual. The

International Function Point Users Group.[pdf].

Ng‟ang‟a, E. and Tonui, I. (2015) „A Survey on Software Sizing for Project

Estimation International Journal of Advanced Research in‟, Ng’ang’a, E.,

& Tonui, I. (2015). A Survey on Software Sizing for Project Estimation

International Journal of Advanced Research in, (January)., (January).

Nguyen, V. (2010) „Improved Size and Effort Estimation Models for Software

Maintenance‟, (December), p. 237.

Nigam A, Nigam B, Kumar Vatsa D. Generating all Navigational Test Cases

using Cyclomatic Complexity from Design Documents for Mobile

Application. Int J Comput Appl. 2012;40(12):40-44. doi:10.5120/5020-

7354.

Pradani. (2013) „Kajian Metode Perhitungan Metrik Function-Point dan

Penerapannya pada Dua Perangkat Lunak yang Dipilih‟, 2(1), pp. 28–34.

http://www.poli.usp.br/d/pmr2490/fp_training.pdf

112

P. L. Primandari and Sholiq, "Effort Distribution to Estimate Cost in Small to

Medium Software Development Project with Use Case Points," in

Procedia Computer Science, 2015.

Pratiwi, D. (2013) „Implementation of Function Point Analysis in Measuring the

Volume Estimation of Software System in Object Oriented and Structural

Model of Academic System‟, 70(10), pp. 1–4.

R. George and T. Vogt, “Illustrative example of a function point analysis for the

NASA crew exploration vehicle guidance, navigation and control flight

software,” NASA: Johnson Space Center, 2008.

Raharja, I. M. S. and Sn, A. (2012) „PERBANDINGAN PROSES

PENGEMBANGAN PERANGKAT LUNAK‟, 2012(semnasIF), pp. 103–

109.

Raju, H. K. and Krishnegowda, Y. T. (2013) „Software Sizing and Productivity

with Function Points‟, 1(2). doi: 10.7763/LNSE.2013.V1.46.

Saleh, 2011. Guidelines for Effort and Cost Allocation in Medium to Large

Software Development Projects.[pdf]. Kuwait: Kuwait University.

Sari, R. and Pribadi, A. (2018) „ScienceDirect ScienceDirect A Modification

Complexity Factor in Function Points Method for Software Cost

Estimation Towards Public Service Application‟, Procedia Computer

Science. Elsevier B.V., 124, pp. 415–422. doi:

10.1016/j.procs.2017.12.172.

Smeds, R., Takala, T., Haho, P., Gröhn, M., Jalkanen, J., Nieminen, M., Hautala,

I. and Latva- Koivisto, A. (1999): Possibilities of Multimedia in Business

Process Modeling and Simulation. In Proceedings of the 4th International

Workshop on Games in Production Management, Ghent, Belgium

Suharjito dan Agus widodo, “perencanaan model estimasi biaya proyek perangkat

lunak”, Jurnal Perencanaan Iptek BPPT Des 2005

Tiwari, U. and Kumar, S. (2014) „Cyclomatic complexity metric for component

based software‟, ACM SIGSOFT Software Engineering Notes, 39(1), pp.

1–6. doi: 10.1145/2557833.2557853.

113

Vijay, J. F. (no date) „The Challenge of Introducing New Software Estimation

Techniques Using Design of Software‟, 1(1), pp. 25–39.

Xia, W. et al. (2009) „Updating weight values for function point counting‟,

International Journal of Hybrid Intelligent Systems, 6(January), pp. 1–14.

doi: 10.3233/HIS-2009-0061.

Yunis et al. (2010) „ARSITEKTUR BISNIS : PEMODELAN PROSES BISNIS

DENGAN‟, 2010(semnasIF), pp. 167–173.

Zapata F, Akundi A, Pineda R, Smith E. Basis path analysis for testing complex

system of systems. Procedia Comput Sci. 2013;20:256-261.

doi:10.1016/j.procs.2013.09.270.

114


115

LAMPIRAN A:

DATA UNTUK FUNCTION POINT

A.1 Data EI, EO, EQ

1. TDId

No. Use Case KET

1 Login EI

2 Logout EI

3 Menambah data pra-permohonan

TDId EI

4 Mengunggah dokumen persyaratan

TDId EI

5 Mengubah data permohonan TDId EI

6 Melihat detil data permohonan TDId EQ

7 Mencetak bukti permohonan TDId EO

8 Memberikan notifikasi via SMS EI

9 Men-generate nomor masuk

pendaftaran TDId EQ

10

Memverifikasi antara data pra-

permohonan TDId dengan dokumen

asli

EI

11 Menambah data pemeriksaan

lapangan EI

12 Mengubah data pemeriksaan

lapangan EI

13 Men-generate nomor Surat

Pernyataan Tugas EQ

14 Mencetak Surat Pernyataan Tugas EO

15 Mengunggah file hasil pemeriksaan

lapangan (BAP) EI

16 Memverifikasi antara BAP dengan

data permohonan TDId EI

17 Membuat draft Surat Keputusan

(SK) Perijinan TDId EI

18 Mencetak draft SK Perijinan TDId EO

19 Mengubah draft SK Perijinan TDId EI

20 Men-generate nomor SK Perijinan

TDId EQ

21 Mencetak SK Perijinan TDId EO

22 Memberikan status permohonan

TDId oleh Kepala Dinas EI

116

No. Use Case KET


TDId oleh Sekretaris Dinas EI


TDId oleh Kabid Industri EI


TDId oleh Kasi ILMEA/IKAHH EI

26 Memberi Isian Disposisi EI

27 Memberi Isian Eksposisi EI

28

Men-generate nomor keluar

berdasarkan hasil realisasi perijinan

TDId

EQ

29 Merekap data TDId per periode EQ

30 Mencetak laporan data 17 industri

yang masuk per periode EO

31

Mencetak laporan realisasi

penyelesaian perijinan TDId per

periode

EO

32 Merekap perijinan TDId per periode EQ

33

Mencetak surat keterangan

penolakan permohonan TDId per

periode

EO

34


persetujuan permohonan TDId per

periode

EO

35 Mengirim status permohonan TDId

via SMS EI

36 Memperpanjang perijinan TDId EI

37 Menambah pengguna EI

38 Mengubah profil pengguna EI

39 Menonaktifkan Pengguna EI

2. IUI

No. Use Case KET

1 Login EI

2 Logout EI

3 Menambah data pra-permohonan IUI EI

4 Mengunggah dokumen persyaratan IUI EI

5 Mengubah data permohonan IUI EI

6 Melihat detil data permohonan IUI EQ

7 Mencetak bukti permohonan IUI EO


117

No. Use Case KET


pendaftaran IUI EQ

10 Memverifikasi antara data pra-

permohonan IUI dengan dokumen asli EI

11 Menambah data pemeriksaan lapangan EI

12 Mengubah data pemeriksaan lapangan EI

13 Men-generate nomor Surat Pernyataan

Tugas EQ



lapangan (BAP) EI

16 Memverifikasi antara BAP dengan data

permohonan IUI EI

17 Membuat draft Surat Keputusan (SK)

Perijinan IUI EI

18 Mencetak draft SK Perijinan IUI EO

19 Mengubah draft SK Perijinan IUI EI

20 Men-generate nomor SK Perijinan IUI EQ

21 Mencetak SK Perijinan IUI EO

22 Memberikan status permohonan IUI

oleh Kepala Dinas EI


oleh Sekretaris Dinas EI


oleh Kabid Industri EI


oleh Kasi ILMEA/IKAHH EI



28 Men-generate nomor keluar

berdasarkan hasil realisasi perijinan IUI EQ

29 Merekap data IUI per periode EQ

30 Mencetak laporan 19 industri per

kategori EO

31 Mencetak laporan data 19 industri yang

masuk per periode EO

32 Mencetak laporan realisasi penyelesaian

perijinan IUI per periode EO

33 Merekap perijinan IUI per periode EQ

118

No. Use Case KET

34 Mencetak surat keterangan penolakan

permohonan IUI per periode EO

35 Mencetak surat keterangan persetujuan

permohonan IUI per periode EO

36 Mengirim status permohonan IUI via

SMS EI

37 Memperpanjang perijinan IUI EI




3. PP

No. Use Case KET

1 Login EI

2 Logout EI

3 Menambah data pra-permohonan PP EI


PP EI

5 Mengubah data permohonan PP EI

6 Melihat detil data permohonan PP EQ

7 Mencetak bukti permohonan PP EO



pendaftaran PP EQ

10


permohonan PP dengan dokumen

asli

EI

11 Menambah data pemeriksaan

lapangan EI

12 Mengubah data pemeriksaan

lapangan EI

13 Men-generate nomor Surat

Pernyataan Tugas EQ



lapangan (BAP) EI

16 Memverifikasi antara BAP dengan

data permohonan PP EI


(SK) Perijinan PP EI

119

No. Use Case KET

18 Mencetak draft SK Perijinan PP EO

19 Mengubah draft SK Perijinan PP EI


PP EQ

21 Mencetak SK Perijinan PP EO

22 Memberikan status permohonan PP

oleh Kepala Dinas EI


oleh Sekretaris Dinas EI


oleh Kabid Industri EI


oleh Kasi ILMEA/IKAHH EI



28



PP

EQ

29 Merekap data PP per periode EQ

30 Mencetak laporan data 20 industri

yang masuk per periode EO

31


penyelesaian perijinan PP per

periode

EO

32 Merekap perijinan PP per periode EQ

33


penolakan permohonan PP per

periode

EO

34


persetujuan permohonan PP per

periode

EO

35 Mengirim status permohonan PP via

SMS EI

36 Memperpanjang perijinan PP EI




4. TDP

No. Use Case KET

120

No. Use Case KET

1 Login EI

2 Logout EI

3 Menambah data pra-permohonan

TDP EI


TDP EI

5 Mengubah data permohonan TDP EI

6 Melihat detil data permohonan TDP EQ

7 Mencetak bukti permohonan TDP EO



pendaftaran TDP EQ

10


permohonan TDP dengan dokumen

asli

EI


(SK) Perijinan TDP EI

12 Mencetak draft SK Perijinan TDP EO

13 Mengubah draft SK Perijinan TDP EI


TDP EQ

15 Mencetak SK Perijinan TDP EO


TDP oleh Kepala Dinas EI


TDP oleh Sekretaris Dinas EI

18

Memberikan status permohonan

oleh Kabid Promosi dan

Pendaftaran Perusahaan

EI


oleh Kasi Pendaftaran Perusahaan EI



22



TDP

EQ

23 Merekap data perusahaan EQ

24 Mencetak laporan perusahaan per

kategori EO

121

No. Use Case KET

25


penyelesaian perijinan TDP per

periode

EO

26 Merekap perijinan TDP per periode EQ

27


penolakan permohonan TDP per

periode

EO

28


persetujuan permohonan TDP per

periode

EO

29 Mencetak (setidaknya) 15 jenis

laporan EO

30 Mengirim Status permohonan TDP

via SMS EI

31 Memperpanjang perijinan TDP EI




A.2 Data ILF dan EIF

1. Data ILF

Data ILF

TDId IUI PP TDP

Pengguna Online Pengguna Online Pengguna Online Pengguna Online

Pemohonan

Online

Pemohonan

Online

Pemohonan

Online

Pemohonan

Online

Data Perusahaan Data Perusahaan Data Perusahaan Data Perusahaan

Data Perijinan Data Perijinan Data Perijinan Data Perijinan

Data Pabrik Data Pabrik Data Pabrik Data Pabrik

Data Bahan Baku Data Bahan Baku Data Bahan Baku Data Kelurahan

Data Mesin Data Mesin Data Mesin Data Kecamatan

Data Kelurahan Data Kelurahan Data Kelurahan Data Legalitas

Perusahaan

Data Kecamatan Data Kecamatan Data Kecamatan Komoditi

Proses Komoditi Komoditi SIUP

Bidang SIUP SIUP Bidang

Komoditi Proses Proses Proses

122

Data ILF

TDId IUI PP TDP

SIUP Bidang Bidang Disposisi

Disposisi Disposisi Disposisi Data Pemegang

Saham

BAP Sumber Daya Sumber Daya Data

Kelembagaan

Pegawai

Data

Pengendalian

Pencemaran

Data

Pengendalian

Pencemaran

Data Kegiatan

Perusahaan

Data Tenaga

Kerja Asing

Data Tenaga

Kerja Asing

BAP BAP

Pegawai Pegawai

2. Data EIF

Data EIF

TDId IUI PP TDP

NIK Penduduk NIK Penduduk NIK Penduduk NIK Penduduk

Pemohon

Terintegrasi

Pemohon

Terintegrasi

Pemohon

Terintegrasi

Pemohon

Terintegrasi

123

A.3 Pembobotan pada EI, EO, dan EQ

1. TDId

EI DET FTR KET EO DET FTR KET EQ DET FTR KET

Login 2 1 low Mencetak bukti

permohonan TDId 1 2 low

Melihat detil data

permohonan TDId 12 1 low

Logout 1 1 low Mencetak Surat

Pernyataan Tugas 1 2 low

Men-generate nomor

masuk pendaftaran TDId 2 2 low

Menambah data pra-

permohonan TDId >15 2 high

Mencetak draft SK

Perijinan TDId 1 2 low

Men-generate nomor

Surat Pernyataan Tugas 2 2 low

Mengunggah dokumen

persyaratan TDId 5 >2 high

Mencetak SK Perijinan

TDId 1 2 low

Men-generate nomor SK


Mengubah data

permohonan TDId >15 2 high

Mencetak laporan data

17 industri yang masuk

per periode

17 2 ave

Men-generate nomor

keluar berdasarkan hasil

realisasi perijinan TDId 1 2 low

Memberikan notifikasi

via SMS 1 1 low

Mencetak laporan

realisasi penyelesaian

perijinan TDId per

periode

1 2 low Merekap data TDId per

periode

> 15 2 High

Memverifikasi antara

data pra-permohonan

TDId dengan dokumen

asli

>15 2 high

Menambah data

pemeriksaan lapangan 1 1 low

Mengubah data

pemeriksaan lapangan 2 2 low

124


Mengunggah file hasil

pemeriksaan lapangan

(BAP)

2 2 low


BAP dengan data

permohonan TDId

2 2 low

Membuat draft Surat

Keputusan (SK)

Perijinan TDId

4 1 low

Mengubah draft SK


Memberikan status

permohonan TDId

oleh Kepala Dinas

1 1 low

Memberikan status

permohonan TDId

oleh Sekretaris Dinas

1 1 low

Memberikan status

permohonan TDId

oleh Kabid Industri

1 1 low

Memberikan status

permohonan TDId

oleh Kasi

ILMEA/IKAHH

1 1 low

Memberi Isian

Disposisi 9 2 ave

Memberi Isian

Eksposisi 9 2 ave

125


Mengirim status

permohonan TDId via

SMS

1 1 low

Memperpanjang

perijinan TDId 1 2 low

Menambah pengguna 1 2 low

Mengubah profil

pengguna 11 2 ave

Menonaktifkan

Pengguna 2 2 low

2. IUI


Login 2 1 low

Mencetak bukti

permohonan IUI 1 2 low

Melihat detil data


Logout 1 1 low

Mencetak Surat

Pernyataan Tugas 1 2 low

Men-generate nomor

masuk pendaftaran IUI 2 2 low

Menambah data pra-

permohonan IUI >15 2 high

Mencetak draft SK

Perijinan IUI 1 2 low

Men-generate nomor


Mengunggah dokumen

persyaratan IUI 5 >2 high


IUI 1 2 low



Mengubah data

permohonan IUI >15 2 high

Mencetak laporan 19

industri per kategori 19 2 ave

Men-generate nomor


realisasi perijinan IUI 1 2 low

126



via SMS 1 1 low



per periode 19 2 ave

Merekap data IUI per

periode >15 2 high


data pra-permohonan

IUI dengan dokumen

asli >15 2 high

Mencetak laporan


perijinan IUI per

periode 1 2 low

Merekap perijinan IUI

per periode

>15 2 high

Menambah data


1 1 low

Mencetak surat

keterangan penolakan

permohonan IUI per

periode 1 2 low

Mengubah data


2 2 low

Mencetak surat

keterangan persetujuan

permohonan IUI per

periode 1 2 low



(BAP) 2 2 low


BAP dengan data


Membuat draft Surat

Keputusan (SK)


Mengubah draft SK


127


Memberikan status

permohonan IUI oleh

Kepala Dinas 1 1 low

Memberikan status

permohonan IUI oleh

Sekretaris Dinas 1 1 low

Memberikan status

permohonan IUI oleh

Kabid Industri 1 1 low

Memberikan status

permohonan IUI oleh

Kasi ILMEA/IKAHH 1 1 low

Memberi Isian

Disposisi 9 2 ave

Memberi Isian

Eksposisi 9 2 ave

Mengirim status

permohonan IUI via

SMS 1 1 low

Memperpanjang

perijinan IUI 1 2 low

Menambah pengguna >15 2 high

Mengubah profil

pengguna 12 2 ave

Menonaktifkan

Pengguna 1 2 low

128

3. PP


Login 2 1 low

Mencetak bukti

permohonan PP 1 2

low

Melihat detil data

permohonan PP 14 1 low

Logout 1 1 low

Mencetak Surat

Pernyataan Tugas 1 2

low

Men-generate nomor

masuk pendaftaran PP 2 2 low

Menambah data pra-

permohonan PP >15 2

high

Mencetak draft SK

Perijinan PP 1 2

low

Men-generate nomor


Mengunggah dokumen

persyaratan PP 5 >2

high


PP 1 2

low


Perijinan PP 2 2 low

Mengubah data

permohonan PP >15 2

high



per periode

20 2

high

Men-generate nomor


realisasi perijinan PP 1 2 low


via SMS 1 1

low

Mencetak laporan


perijinan PP per

periode

1 2

low

Merekap data PP per

periode

> 15 2 high


data pra-permohonan

PP dengan dokumen

asli

>15 2

high

Mencetak surat


permohonan PP per

periode 1 2 low

Merekap perijinan PP

per periode

>15 2 high

Menambah data

pemeriksaan lapangan 1 1

low

Mencetak surat


permohonan PP per

periode 1 2 low

Mengubah data

pemeriksaan lapangan 2 2

low

129




(BAP)

2 2

low


BAP dengan data

permohonan PP

2 2

low

Membuat draft Surat

Keputusan (SK)

Perijinan PP

4 1

low

Mengubah draft SK

Perijinan PP 4 2

low

Memberikan status

permohonan PP oleh

Kepala Dinas

1 1

low

Memberikan status

permohonan PP oleh

Sekretaris Dinas

1 1

low

Memberikan status

permohonan PP oleh

Kabid Industri

1 1

low

Memberikan status

permohonan PP oleh

Kasi ILMEA/IKAHH

1 1

low

Memberi Isian

Disposisi 9 2

ave

Memberi Isian

Eksposisi 9 2

ave

130


Mengirim status

permohonan PP via

SMS

1 1

low

Memperpanjang

perijinan PP 1 2

low


Mengubah profil

pengguna 11 2

ave

Menonaktifkan

Pengguna 1 2

low

4. TDP


Login 2 1 low

Mencetak bukti

permohonan TDP 1 2 low

Melihat detil data

permohonan TDP 12 1 low

Logout 1 1

low

Mencetak draft SK

Perijinan TDP 1 2 low

Men-generate nomor

masuk pendaftaran

TDP 2 2 low

Menambah data pra-

permohonan TDP >15 2

high


TDP 1 2 low

Men-generate nomor

SK Perijinan TDP 2 2 low

Mengunggah dokumen

persyaratan TDP 5 >2

high

Mencetak laporan

perusahaan per kategori

1 2 low

Men-generate nomor

keluar berdasarkan

hasil realisasi perijinan

TDP 2 2 low

Mengubah data

permohonan TDP >15 2

high

Mencetak laporan


perijinan TDP per 1 2 low

Merekap data

perusahaan > 15 2 high

131


periode


via SMS 1 1

low

Mencetak surat


permohonan TDP per

periode 1 2 low

Merekap perijinan TDP

per periode

> 15 2 high


data pra-permohonan

TDP dengan dokumen

asli

>15 2

high

Mencetak surat


permohonan TDP per

periode 1 2 low

Membuat draft Surat

Keputusan (SK)

Perijinan TDP

1 1

low

Mencetak (setidaknya)

15 jenis laporan 15 2 ave

Mengubah draft SK

Perijinan TDP 2 2

low

Memberikan status

permohonan TDP oleh

Kepala Dinas

1 1

low

Memberikan status

permohonan TDP oleh

Sekretaris Dinas

1 1

low

Memberikan status

permohonan oleh

Kabid Promosi dan

Pendaftaran

Perusahaan

1 1

low

Memberikan status

permohonan oleh Kasi

Pendaftaran

1 1

low

132


Perusahaan

Memberi Isian

Disposisi 9 2

ave

Memberi Isian

Eksposisi 9 2

ave

Mengirim Status

permohonan TDP via

SMS

1 1

low

Memperpanjang

perijinan TDP 1 2

low


Mengubah profil

pengguna 9 2

ave

Menonaktifkan

Pengguna 1 2

low

A.4 Pembobotan ILF dan EIF

1. ILF

Data ILF

TDId DET RET KET IUI DET RET KET PP DET RET KET TDP DET RET KET

Pengguna

Online 13 2 low

Pengguna

Online 12 1 low

Pengguna

Online 12 1 low

Pengguna

Online 12 1 low

133

Data ILF


Pemohonan

Online 12 7 ave

Pemohonan

Online 14 10 ave

Pemohonan

Online 14 10 ave

Pemohonan

Online 12 8 ave

Data

Perusahaan 22 3

ave

Data

Perusahaan 35 3

ave

Data

Perusahaan >15 3

ave

Data

Perusahaan >15 3 ave

Data Pabrik 8 2 low Data Bahan

Baku 10 1 low

Data Bahan

Baku 10 1 low

Data

Legalitas

Perusahaan 11 1 low

Data Bahan

Baku 10 1 low

Data

Pengendalia

n

Pencemaran

4 1 low Disposisi 10 1 low

Data

Pemegang

Saham 9 1 low

SIUP 3 1 low BAP 5 2 low

Data

Pengendalian

Pencemaran

4 1 low

Data

Kegiatan

Perusahaan 5 1 low

BAP 3 2 low BAP 4 1 low

2. EIF

Data EIF


NIK

Penduduk 1 1 low

NIK

Penduduk 1 1 low

NIK

Penduduk 1 1 low NIK Penduduk

1 1 low

Pemohon

Terintegrasi 8 1 low

Pemohon


Pemohon


Pemohon


134

A.5 Total Degree Influence

1. TDId

No General System

Characteristic Penjelasan Nilai

1

Data Communication

Berapa banyak fasilitas komunikasi

yang ada untuk membantu

mentransfer atau bertukar informasi

dengan aplikasi atau sistem?

5

2 Distributed data processing Bagaimana data terdisribusi dan

fungsi pemrosesan ditangani? 4

3 Performance Apakah pengguna memerlukan

respose time atau throughput? 4



perangkat keras saat ini dimana sistem

akan dieksekusi?

2

5 Transaction rate

Seberapa sering transaksi dieksekusi

setiap hari, setiap minggu, setiap

bulan, dan lain-lain?

1


dimasukkan secara online? 5

7 End-user efficiency Apakah aplikasi dirancang untuk

efisiensi enduser? 5

8 On-line update Berapa banyak ILF yang diperbaharui

oleh transaksi online? 4

9 Complex processing Apakah aplikasi memiliki extensive

logical atau mathematical processing? 3

10 Reusability



pengguna?

5

11 Installation ease Seberapa sulit konversi dan instalasi? 5

12 Operational ease

Seberapa efektif dan/atau otomatis

start-up, back up, dan prosedur

recovery?

3

13

Multiple sites

Apakah aplikasi dirancang,

dikembangkan dan didukung terutama

untuk diinstal pada multiple sites

untuk beberapa organisasi?

5



dikembangkan dan didukung untuk

memudahkan perubahan?

3

Total Degree Influence 54

135

2. IUI

No General System


1

Data Communication





5








akan dieksekusi?

3

5 Transaction rate




1









10 Reusability



pengguna?

5


12 Operational ease



recovery?

4

13

Multiple sites





5





4


136

3. PP

No General System


1

Data Communication





5








akan dieksekusi?

3

5 Transaction rate




0









10 Reusability



pengguna?

4


12 Operational ease



recovery?

3

13

Multiple sites





4





3


137

4. TDP

No General System


1

Data Communication





5








akan dieksekusi?

3

5 Transaction rate




1









10 Reusability



pengguna?

5


12 Operational ease



recovery?

4

13

Multiple sites





5





4


138

A.6 Unadjusted Function Point

1. TDId

Tipe Komponen

Level Kompleksitas

Low Average High

Total Count

Weighting

Factor Point Count

Weighting

Factor Point Count

Weighting

Factor Point

EI 17 3 51 3 4 12 4 6 24 87

EO 5 4 20 1 5 5 0 7 0 25

EQ 5 3 15 0 4 0 1 6 6 21

ILF 5 7 35 2 10 20 0 15 0 55

EIF 2 5 10 0 7 0 0 10 0 10


2. IUI

Tipe Komponen

Level Kompleksitas

Low Average High

Total Count

Weighting

Factor Point Count

Weighting

Factor Point Count

Weighting

Factor Point

EI 16 3 48 3 4 12 5 6 30 90

EO 7 4 28 2 5 10 0 7 0 38

EQ 5 3 15 0 4 0 2 6 12 27

ILF 4 7 28 2 10 20 0 15 0 48

EIF 2 5 10 0 7 0 0 10 0 10


139

3. PP

Tipe Komponen

Level Kompleksitas

Low Average High

Total Count

Weighting

Factor Point Count

Weighting

Factor Point Count

Weighting

Factor Point

EI 17 3 51 3 4 12 4 6 24 87

EO 7 4 28 0 5 0 1 7 7 35

EQ 5 3 15 0 4 0 2 6 12 27

ILF 5 7 35 2 10 20 0 15 0 55

EIF 2 5 10 0 7 0 0 10 0 10


4. TDP

Tipe Komponen

Level Kompleksitas

Low Average High

Total Count

Weighting

Factor Point Count

Weighting

Factor Point Count

Weighting

Factor Point

EI 13 3 39 3 4 12 4 6 24 75

EO 7 4 28 1 5 5 0 7 0 33

EQ 4 3 12 0 4 0 2 6 12 24

ILF 4 7 28 2 10 20 0 15 0 48

EIF 2 5 10 0 7 0 0 10 0 10


140

A.7 Nilai Adjusted Function Point (AFP)

1. TDId

Nilai VAF : TDI x 0.01 +

0.65

AFP : UFP x VAF


UFP VAF

54 0.01 0.65 1.19

198 1.19

Nilai VAF

235.62

2. IUI


0.65

AFP : UFP x VAF


UFP VAF

54 0.01 0.65 1.19

213 1.19

Nilai VAF

253.47

3. PP


0.65

AFP : UFP x VAF


UFP VAF

52 0.01 0.65 1.17

214 1.17

Nilai VAF

250.38

4. TDP


0.65

AFP : UFP x VAF


UFP VAF

56 0.01 0.65 1.21

190 1.21

Nilai VAF

229.9

141

LAMPIRAN B:

KOMPLEKSITAS PROSES BISNIS

B.1 Proses Bisnis

1. Login TDId, IUI, PP, dan TDP

2. Profil Usaha TDId, IUI, PP, dan TDP

142

3. Mutasi Keluar TDId, IUI, PP, dan TDP

4. Penutupan TDId, IUI, PP, dan TDP

143

5. Permohonan Baru TDP

6. Permohonan Baru TDId, IUI, dan PP

144

7. Perpanjangan TDId, IUI, PP, dan TDP

8. Perubahan TDId, IUI, PP, dan TDP

145

9. Status Perijinan TDId, IUI, PP, dan TDP

146


147

BIOGRAFI PENULIS

Penulis bernama lengkap Anggi Yhurinda Perdana Putri. Sebagian orang

memanggil Anggi atau Putri. Lahir dari rahim seorang ibu yang baik hati di

Banyuwangi pada tanggal 16 Mei 1993. Penulis mengenyam pendidikan formal

selama 2 tahun di TK Khadijah 119 di

Banyuwangi di usia 4 tahun. Kemudian

melanjutkan ke Sekolah Dasar selama 6 tahun

di SDN 2 Jajag Banyuwangi. Pendidikan

Menengah Pertama selama 3 tahun di SMPN

1 Cluring Banyuwangi. Melanjutkan ke

Sekolah Menengah Atas di R-SMA-BI 1 Giri

Banyuwangi pada tahun 2008 dengan jurusan

IPA. Hingga melanjutkan ke jenjang

Universitas di tahun 2011, yaitu di Program

Studi Teknik Informatika Universitas Brawijaya

Malang. Penulis berhasil menyelesaikan studi S1 pada tahun 2015 dengan judul

Skripsi “Pemodelan Sistem Pakar Diagnosa Penyakit Tanaman Kopi Arabika

dengan Metode Fuzzy K-Nearest Neighbor (F-KNN)”. Hingga pada tahun 2016

peneliti melanjutkan pendidikan ke jenjang magister di Jurusan Sistem Informasi

Institut Teknologi Sepuluh Nopember Surabaya. Pada penelitian tesis ini, penulis

mengambil konsentrasi Manajemen Sistem Informasi (MSI) dengan topik

Manajemen Investasi. Jika ada pertanyaan maupun kritik dan saran yang

membangun dapat disampaikan melalui email penulis [email protected].

Salam Hangat

Anggi Yhurinda Perdana Putri

mailto:[email protected].

GENERAL SYSTEM CHARACTERICTICS UNTUK ESTIMASI BIAYA ...

Documents

Transcript of GENERAL SYSTEM CHARACTERICTICS UNTUK ESTIMASI BIAYA ...