PROSES PERANGKAT LUNAK & METRIK PROYEK

Metrik perangkat lunak mengacu pada pengukuran perangkat lunak komputer. Pengukuran           digunakan           untuk   membantu       perhitungan,    kontrol kualitas, perkiraan produktivitas, & kontrol proyek, serta untuk membantu mengambil keputusan taktis pada saat proyek sudah berjalan.

Tujuan pengukuran perangkat lunak adalah:

·           Untuk menyatakan kualitas produk

·           Untuk menilai kualitas manusia yang terlibat dalam pembuatan produk.

·           Untuk menilai keuntungan pemakaian metode & alat bantu yang baru.

·           Sebagai dasar untuk melakukan perkiraan.

·           Untuk  membantu  penyesuaian  pemakaian  alat  bantu  yang  baru  atau pelatihan tambahan.

PENGUKURAN, METRIK, DAN INDIKATOR

Measure (mengukur):

Mengindikasikan kuantitatif dari luasan, jumlah, dimensi, kapasitas, atau ukuran dari atribut sebuah proses atau produk.

Measurement (pengukuran):

Kegiatan menentukan sebuah measure (pengukuran)

Metrics (metrik):

Ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen, atau proses memiliki atribut tertentu.

RPL mengumpulkan pengukuran & mengembangkan metrik sehingga diperoleh suatu indicator.

Indicator (indicator):

Sebuah metrik atau kombinasi dari metrik yang memberikan pengetahuan kedalam proses PL, sebuah proyek PL, atau produk itu sendiri.

Indikator memberikan pengetahuan yang memungkinkan manajer proyek atau perekayasa PL menyesuaikan proses, proyek, dan produk, untuk membuat semuanya menjadi lebih baik.

METRIK DALAM PROSES DAN DOMAIN PROYEK

Metric harus dikumpulkan sehingga indicator proses dan produk dapat dipastikan. Indicator proses memungkinkan sebuah organisasi rekayasa perangkat lunak memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung (misalnya paradigma, tugas-tugas rekayasa perangkat lunak, produk kerja, dan kejadian penting). Indicator proses memungkinkan manajer dan pelaksana memperkirakan apa yang harus dikerjakan dan yang tidak. Metric proses dikumpulkan di seluruh proyek dan pada perkembangan proses perangkat lunak jangka panjang.

Metrik harus dikumpulkan sehingga indikator proses dan indikator produk (proyek) dapat dipastikan.

Indikator proses memungkinkan:

1.      Sebuah organisasi rekayasa PL memperoleh pengetahuan tentang reliabilitas sebuah proses yang sedang berlangsung.

2.      Manajer & pelaksana memperkirakan apa yang harus dikerjakan dan yang tidak.

Indikator proyek memungkinkan manajer proyek PL:

1.    Memperkirakan status sebuah proyek yang sedang berlangsung.

2.    Menelusuri resiko-resiko potensial.

3.    Menemukan area masalah sebelum masalah ‘menjadi semakin kritis’.

4.    Menyesuaikan aliran kerja atau tugas-tugas.

5.    Mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja RPL.

METRIK PROSES

Satu-satunya cara yang paling rasional untuk meningkatkan proses adalah dengan mengukur atribut tertentu dari proses, mengembangkan serangkaian metric yang berarti berdasarkan atribut-atribut tersebut, dan kemudian menggunakan metric itu untuk memberikan indicator yang akan membawa pada sebuah strategi pengembangan.

Proses adalah factor yang dapat dikontrol dalam mengembangkan kualitas perangkat lunak serta unjuk kerja organisasional

Gambar 1 Determinan untuk kualitas dan efektivitas organisasional PL.

Pada gambar, proses berada di tengah-tengah sebuah segitiga yang menghubungkan tiga factor yang sangat besar pengaruhnya terhadap kualitas perangkat lunak dan unjuk kerja organisasional. Ketrampilan dan motivasi yang diperlihatkan manusia merupakan satu-satunya factor yang paling berpengaruh pada kualitas dan unjuk kerja tim. Teknologi yang menghuni proses juga berpengaruh. Segitiga proses juga berada di dalam sebuah lingkaran yang menggambarkan kondisi lingkungan yang menyangkut lingkungan pengembangan (seperti alat-alat Bantu CASE), kondisi bisnis (seperti batas waktu, aturan bisnis), dan karakteristik pelanggan (misalnya lancarnya komunikasi).

Kita mengukur reliabilitas proses perangkat lunak secara tidak langsung yaitu dengan mengambil serangkaian metric berdasarkan keluaran yang dapat diambil dari proses. Keluaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan perangkat lunak, cacat yang disampaikan dan dilaporkan oleh pemakai akhir, prduk kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan, konfirmasi jadwal, serta pengukuran yang lain.

Terdapat penggunaan privat dan public untuk tipe-tipe data proses yang berbeda, karena memang alamiah bila perekayasa perangkat lunak sensitive terhadap pemakaian metric yang dikumpulkan pada basis individual. Data-data tersebut juga harus bersifat pribadi bagi individu dan berfungsi sebagai indicator hanya untuk individu. Contoh metric yang bersifat pribadi terhadap individu menyangkut:

§  Nilai cacat oleh individu

§  Nilai cacat oleh modul

§  Kesalahan yang ditemukan selama pengembangan

Metric public biasanya mengasimilasi informasi yang secara orisinil bersifat pribadi bagi individu dan tim. Nilai cacat tingkat proyek, usaha, waktu calendar, dan data yang dikumpulkan dan dievaluasi dalam upaya menemukan indicator yang dapat mengembangkan unjuk kerja proses organisasional.

Maka dari itu diperlukan etika metric perangkat lunak ketika para manajer ingin melembagakan program metric proses:

§  Gunakan istilah umum dan kepekaan organisasi ketika menginterpretasikan data metric.

§ Berikan umpan balik regular kepada individu dan tim yang telah bekerja untuk mengumpulkan pengukuran dan metric.

§  Jangan menggunakan metric untuk menilai individu.

§  Bekerja dengan pelaksana dan tim untuk menentukan tujuan dan metric yang jelas yang akan dipakai untuk mencapainya.

§  Jangan pernah menggunakan metric untuk mengancam individu dan tim.

§  Metric data yang menunjukkan sebuah area masalah tidak boleh dianggap negative. Data-data itu hanya merupakan sebuah indicator bagi peningkatan proses.

§  Jangan tergoda pada sebuah metric dan kemudian mengabaikan metric penting yang lain.

Pada saat organisasi menjadi lebih nyaman dengan kumpulan dan manfaat metric proyek, deviasi dari indicator sederhana memberikan suatu cara kepada suatu pendekatan yang lebih teliti yang disebut statistical software process improvement (SSPI). Pada dasarnya SSPI menggunakan analisis kegagalan perangkat lunak untuk mengumpulkan informasi seputar semua kesalahan dan cacat yang terjadi pada saat sebuah aperangkat lunakikasi, system, atau produk dikembangkan dan dipakai.

Metrik proses digunakan untuk tujuan strategis. Cara untuk meningkatkan proses perangkat lunak:

·         Mengukur atribut tertentu dari proses.

·         Mengembangkan serangkaian metrik yang berarti.

·   Menggunakan metrik itu untuk memberikan indikator yang akan membawa kepada sebuah strategi pengembangan.

Mengukur reliabilitas proses PL secara tidak langsung yaitu dengan mengambil serangkaian metrik berdasarkan keluaran yang dapat diambil oleh proses.

Keluaran menyangkut:

·         Pengukuran kesalahan yang ditemukan sebelum pelepasan PL.

·         Cacat yang disampaikan & dilaporkan oleh pemakai akhir.

·         Produk kerja yang dikirim.

·         Usaha manusia yang dilakukan

·         waktu kalender yang digunakan

·         konfirmasi jadwal

·         dll

Pada saat organisasi menjadi lebih nyaman dengan kumpulan & manfaat metrik proses, derivasi dari indikator sederhana memberikan suatu cara kepada suatu pendekatan yang lebih teliti yang disebut SSPI (Statistical Software Process Improvement).

SSPI menggunakan analisis kegagalan PL untuk mengumpulkan informasi seputar semua kesalahan & cacat yang terjadi pada saat sebuah aplikasi, sistem, atau produk dikembangkan dan dipakai.

Kesalahan:

Ketidaksempurnaan pada sebuah produk kerja yang ditemukan oleh perekayasaan PL. Sebelum PL itu disampaikan kepada pemakai akhir.

Cacat:

Ketidaksempurnaan pada sebuah produk kerja yang ditemukan oleh perekayasaan PL. Setelah PL itu disampaikan kepada pemakai akhir.

Analisis kegagalan bekerja dengan cara sebagai berikut:

1.         Semua kesalahan & cacat dikategorikan dari awal

2.         Biaya untuk mengkoreksi setiap kesalahan & cacat dicatat.

3.         Jumlah kesalahan & cacat dari setiap kategori dihitung dan ditata dalam urutan naik.

4.         Biaya keseluruhan dari kesalahan & cacat dalam setiap kategori dihitung.

5.         Data resultan dianalisis untuk menemukan kategori yang menelan biaya besar.

6.    Rencana dikembangkan untuk memodifikasi proses guna mengeliminasi kelas kesalahan & cacat yang paling membutuhkan banyak biaya.

Gambar 3 Grafik tulang ikan analisa proses pengembangan perangkat lunak

Berdasarkan langkah 1&2 diatas, ditemukan ada 8 penyebab kerusakan dan sumbernya :

 

·         Sumber spesifikasi/persyaratan :

a.     Logic 20%

b.    Penanganan data 10,5%

c.     Standar 6,9%

Sumber desain:

a.       Spesifikasi 25,5%

·         Sumber kode :

a.                   Interface perangkat lunak 6,0%

b.                  Interface perangkat keras 7,7%

c.                   Pemeriksaan kesalahan 10,9%

d.                  Interface pemakai 11,7%

 

 

METRIK PROYEK

Metrik Proses digunakan untuk tujuan strategis. Pengukuran proyek perangkat lunak bersifat taktis, yaitu bahwa metrik proyek dan indikator yang berasal dari pengukuran digunakan oleh manajer proyek dan tim perangkat lunak untuk mengadaptasi aliran kerja proyek dan aktivitas teknis.

Pada saat kerja teknis dimulai, metrik proyek mulai memiliki arti. Nilai produksi yang disajikan dalam bentuk halaman dokumentasi, jam kajian, titik-titik fungsi, dan deretan sumber yang disampaikan diukur, dan kesalahan yang ditemukan selama masing-masing tugas rekayasa perangkat lunak kemudian ditelusuri. Selagi perangkat lunak berjalan dari spesifikasi ke perancangan, metrik teknik dikumpulkan untuk memperkirakan kualitas desain serta memberikan indikator yang akan mempengaruhi pendekatan yang akan diambil untuk memunculkan kode dan modul serta pengujian integrasi.

Tujuan metrik proyek:

1.      Untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yang diperlukan untuk menghindari penundaan serta mengurangi masalah & resiko potensial.

2.      Untuk memperkirakan kualitas produk pada basis yang berlaku, dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas.

Pada saat kualitas meningkat, kesalahan menjadi minimal, dan selagi kesalahan semakin berkurang, jumlah kerja ulang yang dibutuhkan selama proyek berlangsung juga berkurang. Dengan demikian, pembiayaan proyek secara keseluruhan dapat berkurang.

Model yang lain dari metrik proyek mengusulkan bahwa setiap proyek seharusnya mengukur:

·         Input (pengukuran sumber daya yang dibutuhkan untuk melakukan pekerjaan).

·         Output (pengukuran kemampuan penyampaian atau produk kerja yang diciptakan selama proses rekayasa perangkat lunak).

·         Hasil (pengukuran yang menunjukkan efektivitas kemampuan penyampaian).

Pengukuran proyek PL bersifat taktis, yaitu bahwa metrik proyek & indikator yang berasal dari pengukuran digunakan oleh manajer proyek dan Tim PL untuk mengadaptasi aliran kerja proyek & aktifitas teknis.

Selagi sebuah proyek berjalan, pengukuran usaha dan waktu kalender yang digunakan dibandingkan dengan perkiraan awal (dan jadwal proyek). Manajer proyek menggunakan data tersebut untuk memonitor & mengontrol kemajuan.

Selagi PL berjalan dari spesifikasi ke perancangan, metrik teknik dikumpulkan untuk memperkirakan kualitas desain serta memberikan indikator yang akan mempengaruhi pendekatan yang akan diambil untuk memunculkan kode & modul serta pengujian integrasi (integrated test).

PENGUKURAN PERANGKAT LUNAK

Pengukuran langsung dari proses rekayasa perangkat lunak menyangkut biaya dan usaha yang diaperangkat lunakikasikan. Pengukuran langsung dari produk menyangkut deretan kode (LOC) yang diproduksi, kecepatan eksekusi, ukuran memori, dan cacat yang dilaporkan pada sejumlah periode waktu. Pengukuran tidak langsung dari produk menyangkut fungsionalitas, kualitas, komperangkat lunakeksitas, efisiensi, reliabilitas, kemampuan pemeliharaan, dsb.

Pengukuran perangkat lunak dibedakan menjadi dua yaitu :

·         Pengukuran langsung (direct)

o   Metrik Size-Oriented

·         Pengukuran tidak langsung (indirect)

o   Metrik Function-Oriented

o   Metrik Function Point

Yang diukur pada pengukuran langsung adalah:

·         Biaya

·         Pengaruh

·         Jumlah baris perintah (LOC) yang diproduksi

·         Kecepatan eksekusi

·         Ukuran memori

·         Kesalahan

Yang diukur pada pengukuran tidak langsung adalah:

·         fungsi

·         kualitas

·         kompleksitas

·         efisiensi

·         keandalan

·         kemampuan pemeliharaan

Metrik Size-Oriented

Metrik perangkat lunak size-oriented ditarik dengan normalisasi kualitas dan atau pengukuran produktivitas dengan mempertimbangkan ukuran perangkat lunak yang dihasilkan.

Parameternya adalah ukuran dari software yang dihasilkan. Dapat dilakukan jika ada record atau catatan dari organisasi. Perlu diperhatikan bahwa yang record yang diperlukan adalah keseluruhan aktivitas rekayasa perangkat lunak. Misalnya tabel di bawah ini adalah pengumpulan dari data-data record yang ada dari sebuah organisasi:

Proyek	LOC	Usaha	Dolar	halaman	Kesalahan	cacat	Manusia
alpha	12,100	24	168	365	134	29	3
betha	27,200	62	440	1224	321	86	5
gamma	20,200	43	314	1050	256	64	6

Produktivitas = KLOC / usaha

Kualitas = kesalahan / KLOC

Biaya = biaya / KLOC

Dokumentasi = halaman / KLOC

Dimana LOC (line of code) menunjukkan jumlah baris kode yang dibuat pada masing-masing proyek, misalnya pada kolom pertama, proyek aplha dibuat dengan 12100 baris kode dalam 365 halaman, dikembangakan dengan usaha 24 orang per bulan dengan biaya $168000. Lalu ditemukan kesalahan sebanyak 134 pada proyek sebelum direlease, 29 cacat setelah direlease pada pelanggan, dan ada 3 orang yang bekerja pada pengembangan proyek perangkat lunak alpha.

Untuk pengembangan dari metrik ini, dapat dibuat metrik size oriented baru yang sederhana untuk tiap proyek, misal: kesalahan per baris kode (dihitung ribuan), cacat per baris kode (ribuan), dokumentasi per baris kode (ribuan), kesalahan per usaha, baris kode per usaha, biaya per halaman dokumentasi, dsb.

Metrik ini tidak dapat diterima secara universal karena adanya kontroversi pada penggunaan baris kode sebagai titik ukur. Sebagian yang setuju pada pengukuran LOC menganggap bahwa LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer comment yang ada).

Sedangkan sebagian yang tidak setuju bahwa LOC dijadikan suatu tolak ukur kebanyakan disebabkan alasan ambiguitas dari cara menghitung LOC itu sendiri. Dalam masa-masa awal bahasa pemrograman Assembly, hal ini tidak menjadi suatu masalah karena dalam 1 baris aktual program merupakan 1 baris instruksi, tetapi dalam bahasa pemrograman tingkat tinggi, dimana pada masing-masing bahasa, untuk menyelesaikan suatu masalah dengan algoritma yang sama pun LOC nya sudah berbeda-beda. Bahkan dalam satu bahasa pemrograman yang sama, untuk menyelesaikan masalah yang sama, LOC nya bisa berbeda jauh tergantung dari algoritma yang digunakan. Hal ini yang membuat banyak sekali kontroversi mengenai LOC sebagai tolak ukur dari sebuah software.

Metrik size-oriented tidak diterima sebagai cara terbaik untuk mengukur proses pengembangan perangkat lunak. Sebagian besar berkisar di seputar pemakaian LOC.

Metrik Function-Oriented

Metric perangkat lunak function-oriented menggunakan sebuah pengukuran fungsionalitas yang disampaikan oleh aperangkat lunakikasi sebagai suatu nilai normalisasi. Function point ditarik dengan menggunakan sebuah hubungan empiris berdasarkan pengukuran langsung domain informasi perangkat lunak yang dapat dihitung serta perkiraan kompleksitas perangkat lunak.

Normalisasi dilakukan pada fungsionalitas pada aplikasi, tetapi untuk melakukan hal ini, fungsionalitas harus diukur dengan pengukuran langsung yang lain karena fungsionalitas tidak dapat diukur secara langsung. Maka pengukuran dapat dilakukan dengan pengukuran function point. Function point didapat dari penarikan hubungan empiris berdasarkan pengukuran domain informasi software dan perkiraan kompleksitas software.

Domain informasi yang biasa digunakan ada 6 karakteristik, yaitu:

·         Jumlah input pemakai: setiap input pemakai yang memberikan data yang berorientasi pada aplikasi yang jelas pada perangkat lunak (harus dibedakan dari penelitian yang dihitung secara terpisah) misal: tipe transaksi.

·         Jumlah output pemakai: setiap output pemakai yang memberikan informasi yang berorientasi pada aplikasi kepada pemakai. Pada konteks ini output mengacu pada laporan.

·         Layar, tampilan kesalahan, dsb. Jenis data individual pada laporan tidak dihitung terpisah. Misal: report type.

·         Jumlah penyelidikan pemakai: input online yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk output online.

·         Jumlah file: setiap master logika (pengelompokan data logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file terpisah).

·         Jumlah interface eksternal: semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informasi ke sistem yang lain.

Sekali data telah dikumpulkan, maka nilai kompleksitas dihubungkan dengan masing-masing penghitungan dengan tabel perhitungan sebagai berikut:

Metode pendekatan yang digunakan dapat disebut: Function Point (FP).

Parameter Pengukuran	Jumlah	Sederhana	Rata-Rata	Kompleks	Faktor Pembobotan
Jumlah input pemakai	X	3	4	6	=
Jumlah output pemakai	X	4	5	7	=
Jumlah penyelidikan pemakai	X	3	4	6	=
Jumlah file	X	7	10	15	=
Jumlah interface eksternal	X	6	7	10	=
Total					=

Dalam hal ini faktor pembobotan setiap faktor sudah menjadi standar dan tidak dapat diubah- ubah, tetapi dalam penentuan kriteria suatu perangkat lunak pada salah satu parameter pengukuran adalah sederhana, rata-rata atau kompleks ditentukan oleh organisasi atau perkeyasa perangkat lunak yang melakukan penghitungan itu sendiri. Tetapi meskipun begitu perkiraan kompleksitas tetap bersifat subyektif.

Penghitungan metrik function point:

-     Jumlah input pemakai. Setiap input pemakai yang memberikan data yang berorientasi pada aperangkat lunakikasi yang jelas pada perangkat lunak dihitung. Input ini harus dibedakan dari penelitian yang dihitung secara terpisah.

-    Jumlah output pemakai. Setiap output pemakai yang memberikan informasi yang berorientasi pada aperangkat lunakikasi kepada pemakai dihitung. Pada konteks ini output mengacu pada laporan, layar, tampilan kesalahan, dsb. Jenis data individual pada sebuah laporan tidak dihitung secara terpisah.

-  Jumlah penyelidikan pemakai. Sebuah penyelidikan didefinisikan sebagai input on-line yang mengakibatkan munculnya beberapa respon perangkat lunak yang cepat dalam bentuk sebuah output on-line. Setiap penyelidikan yang jelas dihitung.

-    Jumlah file. Setiap file master logika (yaitu pengelompokan data secara logis yang menjadi suatu bagian dari sebuah database yang besar atau sebuah file yang terpisah) dihitung.

-   Jumlah interface eksternal. Semua interface yang dapat dibaca oleh mesin yang digunakan untuk memindahkan informas ke sistem yang lain dihitung.

FP dihitung dengan melengkapi tabel di bawah ini:

FP = jumlah total x [0,65 + 0,01 x jumlah (fi)]

Jumlah (fi) didapat dari jumlah range jawaban dari 14 pertanyaan berikut:

1.      Apakah sistem membutuhkan backup & recovery yang reliable?

2.      Apakah komunikasi data dibutuhkan?

3.      Apakah fungsi pemrosesan didistribusikan?

4.      Apakah kinerja penting?

5.      Apakah sistem akan berjalan pada lingkungan operasional yang sudah ada yang paling banyak digunakan?

6.      Apakah sistem membutuhkan entry data online?

7.      Apakah entry data online membutuhkan ada transaksi input terhadap layar atau operasi ganda?

8.      Apakah file master diperbarui secara online?

9.      Apakah input, output, file, atau in query kompleks?

10.  Apakah pemrosesan internal kompleks?

11.  Apakah kode didesain untuk dapat dipakai kembali?

12.  Apakah desain melibatkan konversi dan instalasi?

13.  Apakah sistem didesain untuk instalasi ganda dalam organisasi berbeda?

14.  Apakah aplikasi didesain untuk memfasilitasi perubahan & mempermudah pemakai untuk menggunakannya?

Range jawaban (skala) untuk pertanyaan diatas antara 0 s/d 5:

0     : tidak berpengaruh

1     : kurang penting

2     : cukup penting

3     : rata-rata

4     : penting

5     : sangat penting

Sekali function points telah dihitung, maka poin-poin tersebut digunakan dengan cara analog dengan LOC untuk normalisasi pengukuran produktivitas, kualitas perangkat lunak serta atribut-atribut yang lain:

- Kesalahan per FP

- Cacat per FP

- $ per FP

- Halaman dokumentasi per FP

- FP per person-month

(Dimana untuk mendapatkan data-data untuk kesalahan, cacat, dolar, dsb dapat diambil dari data-data pada tabel record pada metrik size-oriented).

Contoh:

Pada proyek alpha (tabel record metrik size oriented) sudah dihitung bahwa jumlah input pemakainya ada 18 buah, jumlah output pemakai: 6 buah, jumlah penyelidikan pemakai 22 buah, jumlah file 45 buah, jumlah interface eksternal 20 buah, dengan asumsi bahwa jumlah input pemakai rata-rata, jumlah output pemakai sederhana, jumlah penyelidikan pemakai rata-rata, jumlah file kompleks, jumlah interface eksternal sederhana. Semua karakteristik pada perangkat lunak ini moderat. Hitung $ per FP nya!

Jawab:

Jumlah total = (18 x 4) + (6 x 4) + (22 x 4) + (45 x 15) + (20 x 6) = 979

Fi = 14 x 2 = 28

FP = 979 x (0,65 + (0,01 x 28)) = 910,47

$ Pada proyek alpha: 168000

$ Per FP = 168000 / 910,47 = $184,52

Hasil dari contoh kasus diatas masih berupa suatu angka mentah, untuk dapat dilihat apakah angka ini termasuk baik atau tidak harus diperbandingkan dengan perhitungan lain, misalnya $ per FP dari proyek beta atau gamma, atau proyek dari organisasi lain.

Sebenarnya banyak sekali metrik-metrik yang digunakan untuk mengukur perangkat lunak, misalnya metrik FP yang diperluas (biasanya diaplikasikan dalam dunia bisnis) tetapi belum sempat dibahas disini.

Lima faktor penting yang mempengaruhi produktivitas perangkat lunak menurut Basili dan Zelkowitz:

1.    faktor manusia

2.    faktor masalah

3.    faktor proses

4.    faktor produk

5.    faktor sumber daya

Faktor – faktor untuk mengukur kualitas perangkat lunak (4 metrik kualitas):

1.         Cara yang benar. Program harus beroperasi dengan benar. Cara yang benar adalah tingkat dimana perangkat lunak melakukan fungsi-fungsi yang ditentukan. Ukuran yang paling umum adalah cacat per KLOC, dimana cacat didefinisikan sebagai kurangnya kesesuaian (yang telah terbukti) dengan persyaratan.

2.         Maintanabilitas. Merupakan kemudahan dimana program dapat dikoreksi jika ditemukan kesalaha, diadaptasi jika lingkungannya berubah, atau diperkuat jika pelanggan menginginkan perubahan kebutuhan. Metrik time-oriented sederhana adalah rata-rata waktu untuk berubah-ubah (MTTC), waktu yang diperlukan untuk menganalisis perubahan yang diperlukan, desain modifikasi yang tepat, mengimperangkat lunakementasikan perubahan, mengujinya, dan mendistribusikan perubahan kepada semua pemakai. Rata-rata, program yang dapat dipelihara akan mempunyai MTTC lebih rendah (untuk tipe perubahan ekivalen) daripada program yang tidak dapat dipelihara.

3.         Integritas. Mengukur kemampuan sistem untuk menahan serangan (baik kebetulan maupun sengaja) terhadap sekuritasnya. Serangan dapat dilakukan pada semua komponen perangkat lunak: program, data, dan dokumen.

4.         Untuk mengukur integritas, ada dua atribut tambahan yang harus ditentukan: ancaman dan sekuritas. Ancaman adalah probabilitas (yang dapat diestimasi atau berasal dari bukti-bukti empiris) bahwa serangan tipe tertentu akan terjadi dalam suatu periode waktu yang ditentukan. Sekuritas adalah probabilitas probabilitas (yang dapat diestimasi atau berasal dari bukti-bukti empiris) bahwa serangan tipe tertentu akan dipukul mundur. Integritas sistem kemudian ditentukan sebagai:

integritas = Σ [1-ancaman*(1-sekuritas)], dimana ancaman dan sekuritas adalah jumlah dari masing-masing jenis serangan.

5.         Usebilitas. Merupakan usaha untuk mengukur user-friendliness dan dapat diukur dalam empat karakteristik:

·       Ketrampilan fisik dan atau intelektual untuk mempelajari sistem.

·       Waktu yang diperlukan untuk menjadi cukup efisien dalam menggunakan sistem.

·       Peningkatan bersih dalam produktivitas (dalam pendekatan jika sistem diganti) yang diukur ketika sistem digunakan oleh seseorang yang cukup efisien.

·       Penilaian subyektif (kadang-kadang diperoleh melalui kuisioner) dari sikap pemakai terhadap sistem.

Faktor – faktor yang mempengaruhi biaya pengembangan PL:

1.    Kemampuan programmer dan tenaga kerja

2.    Kekompleksan produk

3.    Ukuran produk

4.    Waktu yang tersedia

5.    Keandalan yang diperlukan

6.    Teknologi yang dipergunakan