3.1.1.1. KELEBIHAN LOC

Kelebihan-kelebihan menggunakan baris kode (LOC) ini sebagai unit pengukuran perangkat lunak

meliputi :

LOC ini sudah umum digunakan dan dapat diterima secara universal

LOC ini mengijinkan adanya perbandingan matriks ukuran dan produktifitas antara

kelompok-kelompok pengembangan yang berbeda beda

LOC ini berhubungan secara langsung dengan produk akhir

LOC lebih mudah diukur terhadap penyelesaian proyek

LOC mengukur perangkat lunak dari sudut pandang pengembang - yaitu apa yang ia

kerjakan.

Teknik estimasi ini memungkinkan adanya aktifitas untuk kenaikan berkelanjutan - ukuran

perkiraan dapat dengan mudah dibandingkan dengan ukuran riil ketika sesudahnya

dilakukan analisa terhadap proyek tadi (seperti bagaimana keakuratan perkiraan,

mengapa ia bisa mengubah sekian persen?, apa yang bisa dipelajari dari sini untuk menilai

ukuran proyek berikutnya?, .. dan seterusnya).

3.1.1.2. KELEMAHAN LOC

Kelemahan-kelemahan menggunakan baris kode (LOC) adalah sebagai berikut :

LOC kesulitan untuk menaksir perangkat lunak baru diawal tahap siklus hidup

pengembangan

Instruksi program berbeda menurut jenis bahasa pemrograman, metoda-metoda disain,

dan dengan gaya dan kemampuan programmer

Tidak adanya organisasi standarisasi ( seperti ISO) untuk menghitung baris kode

Perangkat lunak melibatkan banyak biaya-biaya yang mungkin tidak dipertimbangkan

ketika melakukan pengukuran kode untuk menaksir biaya – terdapat " biaya-biaya tetap"

seperti biaya kebutuhan spesifikasi dan dokumen-dokumen pemakai yag tidak dimasukkan

dalam pengkodean.

Pemrogram mungkin akan menerima bayaran lebih untuk jumlah baris kode yang besar

jika pihak manajemen salah tanggap terhadap produktifitas mereka dan tidak sebaliknya

untuk pihak desainer, padahal kode program bukanlah yang paling esensi dari suatu

produk melainkan pencapaian fungsionalitas dan performansi.

Penghitungan LOC seharusnya membedakan antara kode yang dihasilkan dengan kode

berdasarkan fungsinya - karena ini lebih sulit yaitu menghitung utilitas, bukan hanya

sekedar "menghitung langsung" kode, yang sebenarnya bisa diperoleh dari daftar kode

compiler

LOC tidak dapat digunakan untuk normalisasi jika platform atau bahasa dibedakan

Hanya ada dua cara untuk memperkirakan jumlah LOC untuk perangkat lunak baru yang

akan dibangun yaitu pertama dengan menganalogikan kesamaan fungsional dengan

produk perangkat lunak yang telah ada dan kedua dengan opini pakar, keduanya adalah

metode yang kurang akurat

Sayangnya, produktifitas sering diukur dengan baris kode yang dihasilkan. Jika seorang

pemrogram bisa meningkatkan dari rata-rata 200 baris kode per bulan menjadi 250 baris kode

perbulan, manajer mengira bahwa produktifitasnya telah meningkat. Hal ini adalah persepsi yang

berbahaya yang sering mengakibatkan pemrogram tergoda untuk menghasilkan baris kode yang

lebih banyak per desainnya. Tidak hanya pengembang yang menilainya mempunyai produktivitas

yang lebih tinggi, tetapi ia juga dianggap menghasilkan kode yang bersih. Beberapa organisasi

menggunakan rumus ini untuk mengukur mutu:

Jumlah cacat / jumlah baris kode

Jika pembagi besar, maka kualitas kelihatannya dibuat tinggi. Pada umumnya tahap pengkodean

mengkonsumsi hanya 7 % dari total usaha dan maksimum sekitar 20 %. tetapi tentu saja kualitas

kode yang terpenting, bukan volume.

3.1.2. FUNCTION_POINT SEBAGAI UNIT PENGUKURAN

Metode Function Point ( FP) didasarkan pada gagasan di mana ukuran perangkat lunak akan

lebih baik diukur dalam kaitannya terhadap jumlah dan kompleksitas fungsi yang dikerjakannya

dibanding dengan banyaknya baris dari kode yang merepresentasikannya. Function point pertama

kali dikenalkan oleh A.J. Albrecht dari IBM yang ditulis di akhir 1970, untuk sistem yang berorientasi

transaksi. Capers Jones suatu korporasi dibidang Riset produktifitas perangkat lunak,

mengembangkan gagasan Albrecht ke suatu badan pengetahuan nasional. Pada tahun 1986, suatu

kelompok non profit, yang disebut The International Function Point User Group (IFPUG) dibentuk

untuk mengelola informasi matriksnya. Tahun 1987, pemerintah Inggris mengadopsi function point

yang dimodifikasi sebagai matriks baku untuk produktivitas perangkat lunak. Kemudian tahun 1994,

dikenalkan Latihan Manual Penghitungan Function Point versi 4.0 (Function Point Counting Practices

Manual Release 4.0) Standar IFPUG dan dirilis Petunjuk Pengukuran Perangkat lunak versi 1.0

(Guidelines to Software Measurement Release 1.0 ) Standard IFPUG.

Prinsip Function point :

Melengkapi unit standar dari pengukuran

Berdasarkan pada pandangan eksternal pemakai terhadap sistem

Pengukuran kerja produktif bersama dengan pengukuran usaha kerja akan

menghasilkan pengukuran produktifitas

Model estimasi yang mendasarkan pengukuran function-point untuk produktifitas

Tujuannya adalah membangun pengukuran relatif dari nilai fungsi hasil yang akan

diserahkan, terlepas dari teknologi atau pendekatan yang digunakan

Secara umum pendekatan dilakukan berdasar perhitungan (bobot yang

merefleksikan nilai tipe fungsi ) dari :

External input (data screen, ligt-pen, switch, transaksi dari aplikasi lain)

External output (screen report, terminal report, screen message, transaksi

untuk aplikasi lain)

Logical internal file (Data base, user table, message table, logical internal

table)

File atau struktur data

External interface file (share data base, logical internal file yang dapat

diakses dari / ke aplikasi lain)

External inquiry (user inquiry tanpa update file, help message and screen,

pemilihan menu screen)

Langkah-langkah :

Kumpulkan dokumen dari sudut pandang user

Klasifikasikan ke dalam 5 tipe fungsi

Siapkan lembar kerja untuk masing-masing fungsi

Gunakan faktor pembobotan untuk setiap fungsi

Jumlahkan ke dalam function Count (FC)

Gunakan nilai dari 0-5 untuk masing-masing dari 14 karakteristik (N)

Jumlahkan ke dalam Processing Complexity (CF)

Hitung AFP = FP x CF

Konversikan ke LOC

3.1.2.2. KEUNTUNGAN ANALISA FUNCTION POINT

Keuntungan-keuntungan memakai Analisa Function Point sebagai unit pengukuran, meliputi:

Dapat diaplikasikan diawal tahap siklus hidup pengembangan sistem – Pengukuran besar

proyek bisa dilakukan dalan tahap kebutuhan dan tahap desain dari siklus hidup

Tidak tergantung pada bahasa pemrograman, tehnologi dan teknik, kecuali untuk

penyesuaian-penyesuaian di akhir tahap

Function poin menyediakan suatu relasi terhadap usaha yang dapat dipercaya ( jika

penentuan fungsi pengukuran benar)

para pemakai dapat lebih mudah memahami ukuran besaran ini. mereka dapat lebih siap

memahami dampak dari suatu perubahan di dalam kebutuhan fungsional

produktifitas proyek yang ditulis dalam beberapa bahasa dapat diukur

Function point menyediakan sautu mekanisme untuk melacak dan memonitor jejak

jangkauan.

Function point dapat digunakan untuk sistem graphical user interface (GUI), untuk sistem

client/ server, dan pengembangan berorientasi obyek

Function point dapat dihitung oleh user setepat teknisi

KEUNTUNGAN ANALISIS FEATURE POINT

Keuntungan dari analisis Feature Point yang paling utama sama halnya dengan analisis Function

Point, dengan tambahan pendekatannya lebih baik dalam hal menaksir ukuran di penilaian ukuran

dari sistem yang lebih algoritmik.

KELEMAHAN ANALISIS FEATURE POINT

Kelemahan utama analisis Feature Point adalah subjektifitas dari penggolongan kompleksitas

algoritma.

OBJECT POINT

Menghitung " object points" untuk menentukan ukuran perangkat lunak adalah suatu pendekatan

yang dikembangkan untuk teknologi berorientasi obyek. Diselenggarakan pada suatu tingkatan yang

lebih makro dibanding function points, yaitu menilai satu obyek untuk masing-masing kelas yang

unik, seperti suatu tampilan, laporan output, dan seterusnya. Sisa dari proses adalah sama dengan

Function Point dan Feature Point, tetapi faktor konversi berbeda.

MENJADI LEBIH AKURAT DENGAN REUSABILITY

Kita dapat memperoleh hitungan yang lebih akurat jika kita melihat lebih dekat pada karakteristik

penggunaan ulang perangkat lunak dan proses. Kembali ke contoh, langkah yang pertama adalah

menentukan proses dan kemudian menentukan persen dari total usaha yang digunakan pada setiap

langkah pengembangan kode yang baru.

3.1. ESTIMASI DURASI DAN BIAYA PROYEK

Inisialisasi perkiraan usaha dan jadwal (jangka waktu) perangkat lunak terjadi pada tahap awal siklus

hidup proyek. Setelah kita mengestimasi ukuran perangkat lunak, Proses berikutnya menaksir usaha,

jadwal, dan biaya. ( lihat Gambar 11-2). Estimasi ini direkam dalam rencana proyek; oleh karena itu,

kompetensi proyek yang ketiga, pendokumentasian rencana, adalah suatu keahlian yang termasuk

ke dalam bidang ini. Estimasi adalah juga matriks yang harus dipelihara sebagaimana progress

kemajuan proyek.

Teknik Pengembangan Produk

4. Mengevaluasi alternatif-alternatif proses - Estimasi menggunakan sedikitnya dua teknik.

8. Memilih metoda dan alat bantu (tool) - Estimasi adalah suatu metoda dengan satu rangkaian

langkah-langkah proses; ada banyak alat bantu yang tersedia untuk mendukung proses, baik secara

manual ataupun otomatis.

9. Proses penyatuan - Semua model estimasi dapat dikalibrasi untuk mencerminkan suatu

lingkungan organisasi.

Keahlian Manajemen Proyek

13. Pendokumentasian rencana - Dekomposisi tugas-tugas produk dan proyek menurut perkiraan

ukuran, usaha, dan biaya, dan kemudian pada akhirnya bermuara pada jadwal proyek. Semuanya

terwakili dalam rencana manajemen proyek perangkat lunak ( SPMP). Estimasi resiko

didokumentasikan dalam suatu rencana resiko yang terpisak atau sebagai suatu segmen bagian di

SPMP .

14. Estimasi biaya dan

15. Estimasi usaha - memprediksi besar usaha.

18.Penjadwalan - dari usaha yang diketahui juga dapat mengarah ke penjadwalan,

19. Memilih matriks - Unit ukuran adalah suatu matriks. Ketika matriks terpilih (berupa ukuran,

waktu usaha yang diperkirakan [ jam, hari, minggu], durasi jadwal yang diperkirakan, biaya yang

diperkirakan), mereka akan dirujuk secara konsisten selama proyek itu. Mereka akan digunakan

untuk membandingkan estimasi dalam rencana terhadap hasil aktualnya.

Keahlian Manajemen Orang

Adalah sesuatu yang sukar untuk mendaftar kompetensi tiap orang secara terpisah karena hampir

semua dari mereka dibutuhkan dalam hampir tiap-tiap aktivitas pengembangan perangkat lunak.

Dengan mengestimasi usaha, jadwal dan biaya, maka dengan adanya daftar keahlian orang

terutama sekali akan sangat membantu dalam hal:

24. Penanganan kekayaan intelektual

25. Pengkondisian rapat-rapat yang efektif

26. Interaksi dan komunikasi

27. Kepemimpinan

28. Manajemen perubahan

29. Bernegosiasi dengan sukses

31. Presentasi secara efektif

3.2.1. Pemodelan Estimasi Empiris dengan COCOMO (Constructive Cost Model)

Pada perencanaan pengembangan perangkat lunak diperlukan suatu model perhitungan

( estimation model) dengan menggunakan rumusan-rumusan yang diturunkan secara empiris untuk

memprediksi data-data yang diperlukan pada setiap tahapannya.

Melalui " usaha" dalam proses estimasi perangkat lunak, ini berarti jumlah usaha manusia,

atau pekerja, yang akan dibutuhkan untuk melaksanakan suatu tugas. Ini dapat diukur dalam

beberapa unit, sepanjang unit tersebut dijaga konsisten. Beberapa, standard defacto adalah staff /

jam ( orang / jam), staff / hari ( orang/ hari), atau, paling umum, mengorganisirnya dalam staff/bulan

( orang/bulan).

Salah satu dari topik yang utama di sini adalah alat bantu (tool) untuk mengestimasi usaha-

jadwal- biaya, yang disebut COCOMO (COnstructive COst MOdel).

Model sumber terdiri dari paling sedikit satu persamaan empiris untuk berusaha

memprediksi berbagai hal misalnya :

Kemajuan proses pengembangan (dalam satuan orang – bulan)

Lamanya proyek

Ukuran staf

Jumlah baris kode program

Selanjutnya Basili membagi kelas-kelas model sumber ke dalam empat jenis model yaitu :

Model static single-variable

Model static multivariable

Model dynamic multivariable

Model theoritical

3.2.2 Model COCOMO

Cocomo dikemukakan oleh Barry Boehm dan merupakan model perhitungan perangkat lunak secara

hirarkis yang mengambil bentuk antara lain :

Model 1 : BASIC COCOMO

Adalah model static single valued yang menghitung kemajuan dan biaya pengembangan

perangkat lunak sebagai fungsi dari ukuran program yang dalam hal ini dinyatakan

dalam perhitungan jumlah baris kode program

Model 2 : INTERMEDIATE COCOMO

Model ini menghitung kemajuan pengembangan perangkat lunak sebagai fungsi dari ukuran

program dan kumpulan komponen biaya lainnya yang termasuk penilaian subyektif dari

produk, perangkat keras, personil dan komponen proyek lainnya.

Model 3 : ADVANCE COCOMO

Model ini menggabungkan semua karakteristik dari versi Intermediate Cocomo dengan

tambahan penilaian dari komponen biaya yang berpengaruh pada tiap tahapan dari

pengembangan perangkat lunak (analisis, desain, pengkodean, implementasi dan

pemeliharaan).

Cocomo dapat diaplikasikan ke dalam 3 kelas dari proyek pengembangan perangkat lunak

berdasarkan kompleksitas sistem dan lingkungan pemrograman yaitu :

Mode Organic

Mode ini diterapkan pada kelas proyek untuk pengembangan perangkat lunak yang

sederhana dan tidak terlalu besar. Tim pengembang bisa berupa tim kecil yang biasa

bekerja sama dan telah berpengalaman dalam pengembangan aplikasi. Kebutuhan

perangkat lunak yang dikembangkan biasanya bersifat fleksibel.

Mode Semi-Detached

Mode ini diterapkan pada kelas proyek yang agak kompleks dan melibatkan personil

dalam tim yang agak besar. Personil bisa berasal dari berbagai bidang dan tingkatan

pengalaman yang bervariasi. Dengan demikian tingkat pemenuhan kebutuhan yang

beragam pula.

Mode Embedded

Mode ini diterapkan pada kelas proyek yang rumit. Dalam mode ini terdapat hubungan

yang sangat kuat antara perangkat lunak, perangkat keras dan batasan operasi yang

harus dipenuhi sistem, seperti dalam pengembangan perangkat lunak pengatur lalu

lintas pesawat udara

3.4. Keuntungan dari COCOMO

Keuntungan dari COCOMO meliputi:

- data aktual " backfitted" dari banyak program real dapat menyediakan satu set COCOMO yang

konstan dan faktor penyesuaian yang cocok terhadap suatu organisasi yang baik.

- merupakan suatu proses yang dapat berulang.

- metoda mengijinkan jika ada tambahan dari faktor penyesuaian yang unik yang berhubungan

dengan suatu organisasi.

- metode ini cukup serbaguna untuk mendukung "mode dan tingkatan" berbeda.

- bekerja baik pada proyek-proyek yang tidak secara dramatis berbeda dalam ukuran,

kompleksitas, atau proses.

- kalibrasi sangat tinggi, berdasar pada pengalaman sebelumnya.

- metode ini terdokumentasi secara menyeluruh

- mudah menggunakan

3.5. Kelemahan COCOMO

Kelemahan-kelemahan COCOMO meliputi:

- mengabaikan kebutuhan volatility ( tetapi suatu organisasi bisa menambahkan ini sebagai suatu

faktor penyesuaian yang ekstra dalam menghitung EAF).

- mengabaikan dokumentasi dan kebutuhan yang lain. " mengabaikan atribut keahlian pelanggan,

kerjasama, pengetahuan, dan responsifitas.

- menyederhanakan secara berlebihan dampak dari isu keamanan.

- mengabaikan isu keselamatan perangkat lunak.

- mengabaikan lingkungan pengembangan software itu.

- mengabaikan level perubahan personil.

- mengabaikan banyak isu perangkat keras.

- semua level tergantung pada estimasi ukuran - ketelitian ukuran mengendalikan keakuratan

usaha, waktu pengembangan, susunan kepegawaian, dan perkiraan produktivitas.

- penilaian yang didasarkan pengalaman mungkin mempunyai cacat oleh karena keusangan dari

data historis yang digunakan atau karena memori penaksir dari proyek yang yang lampau

mempunyai cacat.

- tergantung pada pengetahuan dari pengarah biaya dan/atau jumlah waktu digunakan pada

setiap tahap.