Function Point

Function point (FP) adalah metode salah satu metode pengukuran volume software. Volume software dapat berguna untuk perencanaan sumber daya, biaya, dan durasi saat pengembangan software. Pengukuran volume software dilakukan berdasarkan pada skala kompleksitas pada software. Selain berguna untuk perencanaan sumber daya, biaya dan durasi, bagi pengembang, menghitung software berguna untuk mengevaluasi kualitas produk dengan cara membandingkan volume sistem dengan banyaknya error (Error-count) dalam software yang di kembangkan.

Keunggulan

Keunggulan  metode Function Point ini adalah kemampuannya untuk menyediakan perkiraan volume proyek dalam bentuk sumber daya pengembangan yang dibutuhkan, sebelum proyek tersebut berjalan. Penggunaan metode ini juga dapat mencegah atau mengurangi resiko dari kesalahan manajerial karena kesalah pahaman pada perencanaan biaya proyek.

Perhitungan

 Perhitungan metode ini didasarkan pada ukuran banyak dan kompleksitas fungsi yang diinginkan dalam proyek. Function point harus dihitung melalui dokumentasi requirement fungsional sistem. Metode ini terdiri dari banyak varian yaitu terdapat pada langkah atau tahapan yang ada maupun pada isi dari tiap tahapan. Berikut adalah tahapan-tahapan perhitungan

Langkah 1: Menghitung Crude Function Points (CFP)

Jumlah dari komponen fungsional sistem pertama kali diidentifikasi dan dilanjutkan dengan mengevaluasi kuantitasi bobot kerumitan dari tiap komponen tersebut. Perhitungan CFP melibatkan 5 komponen :

·         Jumlah macam apliaksi input

·         Jumlah macam aplikasi output

·         Jumlah macam aplikasi query online/ inquiry

·         Jumlah macam file/table logic yang terlibat

·         Jumlah macam interface eksternal

Langkah 2 Menghitung Relative Complexity Adjustment Factor (RCAF)

RCAF berfungsi untuk menghitung kesimpulan kompleksitas teknik dari suatu sistem software dari subjek prespektik yang berpengaruh. Subjek-subjek yang dinilai ialah sebagai berikut :

• ·         Kompleksitas kehandalan backup atau recovery
• ·         Kompleksitas komunikasi data
• ·         Kompleksitas pemrosesan terdistribusi
• ·         Kompleksitas kebutuhan kinerja
• ·         Kebutuhan lingkungan operasional
• ·         Kebutuhan knowledge pengembang
• ·         Kompleksitas updating file master
• ·         Kompleksitas instalasi
• ·         Kompleksitas aplikasi input, aoutput, query online, dan file
• ·         Kompleksitas pemrosesan data
• ·         Ketidak mungkinan penggunaan kembali kode-kode yang akan dibuat (non-reuseable)
• ·         Variaso organisasi pelanggan
• ·         Kemungkinan perubahan atau fleksibilitas
• ·         Kebutuhan kemudahan penggunaan

Penilaian dilakukan dengan skala pengukuran, berikut adalah contoh form perhitungan RCAF

Langkah 3 Menghitung Function Point

Setelah selesai perhitungan RCAF, langkah terakhir adalah menghitung nilai Function Point. Nilai FP  untuk sistem software yang diberi penilaian dihitung berdasarkan hasil dari tahap 1 dan 2 yang dimasukkan ke dalam persamaan berikut :

FP = CFP x (0.65 + 0.01 x RCAF)

Referensi :

M Dedi Iskandar, Kusrini, Implementasi Metode Function Point untuk Mengukur Volume Software

Requirement Traceability Matrix

Konsep dari matriks ini adalah agar kita dapat menelusuri tahap awal hingga akhir dari kebutuhan hingga pengimplementasian, dan dari tahap atas kebutuhan untuk di tes. Matriks ini adalah sebuah tabel yang menelusuri kebutuhan test yang kita butuhkan untuk memastikan bahwa kebutuhan tersebut telah terpenuhi. Jadi, tabel tersebut berisikan daftar dari kebutuhan, atribut yang bervariasi untuk setiap kebutuhan, serta status dari kebutuhan tersebut. Matriks tersebut menghubungkan tahap kebutuhan yang tinggi, spesifikasi desain, kebutuhan test, dan juga file kode.

Hal ini dibutuhkan untuk penjaminan kualitas dari software karena kita dapat memastikan kustomer dapat apa yang mereka minta. Traceability Matrix juga membantu tim pengembang untuk mencari tahu kenapa kode tertentu di implementasikan, dengan melihatnya dari kode ke kebutuhan.

 

Tujuan

•  Untuk memastikan bahwa kebutuhan telah di penuhi di tiap fase dari tahap pengembangan
• Setiap dokumen dapat di telusuri, test case dapat di telusuri pada spesifikasi kebutuhannya. Jika ada versi terbaru, lalu update, kita dapat menelusurinya dengan matriks ini

Progress Control

Progress control

View more presentations from ashamarsha.

Dokumentasi Kontrol

Sebuah dokumen adalah sesuatu yang vital bagi tim pengembang dan juga untuk pemeliharaan sistem software tersebut untuk pengelolaan masa sekarang dan yang akan datang. Oleh karena itu, persiapan, penyimpanan, pengambilan, dan pelepasan dikendalikan oleh prosedur dokumentasi. 

Tujuan

-        

• Untuk menjamin kualitas dari dokumen
• Untuk menjamin kelengkapan teknis dari dokumen, kepatuhan terhadap struktur dokumen dan penggunaan instruksi
• Untuk menjamin ketersediaan dokumen yang diperlukan untuk pengembangan dan pemeliharaan yang lebih lanjut pada software atau menanggapi keluhan dari kustomer.
• Untuk mendukung penyelidikan penyebab kegagalan perangkat lunak

 

Quality Record

 

Sebuah rekam kualitas adalah salah satu tipe spesial dari dokumentasi kontrol. Dokumen ini yang berisikan informasi-informasi yang berhubungan dengan prosedur atau instruksi kerja. Dokumen ini juga yang diperlukan kustomer karena menunjukan kepatuhan dengan persyaratan dari kustomer dan juga operasi yang efektif dari sistem software serta jaminan seluruh proses pembangunan dan pemeliharaan sistem.

Berikut adalah gambaran tentang jenis dokumen yang mungkin dikategorikan sebagai dokumen kontrol

Dokumentasi Prosedur Kontrol

Tools SQA yang mengatur penanganan dokumen dari perusahaan yang mengendalikan pembuatan sampai pelepasan akhir disebut dengan Dokumentasi Prosedur Kontrol.  Berikut adalah komponen-komponen dari prosedur tersebut :

Daftar Dokumentasi Kontrol

Kunci dari pengelolaan dokumentasi kontrol adalah daftar dokumentasi kontrol. Kontruksi yang tepat dari daftar ini didasarkan pada pembentukan otoritas untuk menerapkan konsep ini, apakah yang terkandung pada orang atau komite. Secara khusus, otoritas ini bertanggung jawab untuk :

•  Menentukan jenis dokumen untuk dikategorikan sebagai dokumentasi kontrol dan yang jenis dokumentasi kontrol harus diklasifikasikan sebagai kualitas reka
• Menentukan pakah tingkat kontrol untuk setiap jenis dokumen yang dikategorikan sebagai dokumen kontrol telah memadai
• Menindaklanjuti kepatuhan dengan daftar jenis dokumen kontrol
• Menganalisis hasil temuan lanjutan dan memulai pembaruan, perubahan, kepindahan dan penambahan yang diperlukan pada daftar jenis dokumentasi kontrol.

Persiapan Dokumentasi Kontrol

Kebutuhan dokumentasi yang terlibat dalam penciptaan dokumen baru atau revisi yang fokus pada kelengkapan dokumen yang ada, meningkatkan keterbacaan dan ketersediaan. Kebutuhan ini diwujudkan dalam dokumen:

•  Struktur
• Cara identifikasi
• Standar orientasi dan informasi referensi

Configuration Management

Configuration Management merupakan kegiatan untuk mengidentifikasi, mengorganisasi, kontrol modifikasi pada software yang sedang dibangun, berikut adalah penjelasannya menurut buku Galin

Configuration management

View more presentations from ashamarsha.

Staff Training and Certification

Training and Certification merupakan cara untuk melihat serta menjamin kualitas dari pegawai yang akan membuat software. Berikut adalah penjelasan dari buku Galin

Staff training and certification

View more presentations from ashamarsha.

Supporting Quality Devices

Dalam suatu proyek, seringkali terjadi perubahan formasi tim maupun banyaknya departmen maupun divisi yang terlibat. Karena itu, proses pendokumentasian proyek seringkali berbeda tiap departmen maupun dengan dokumen dari tim yang lama. Selain itu, seringkali dalam proyek kita lupa mengerjakan sesuatu yang penting sekali. Oleh karena itu, untuk mencegah hal-hal tersebut, kita dapat menggunakan 2 tools sederhana yang turut menjamin kualitas dari proyek yang kita kerjakan yaitu, Template dan Checklist.

 

Template

Template merupakan pola yang digunakan sebagai panduan. Ketika di terapkan di proyek, template mengacu ke pada format yang telah dibuat oleh sebuah unituntuk diterapkan ketikasi menyatukan laporan atau dokumen lainnya. Penerapan template pada sebuah proyek mungkin wajib di pakai bagi beberapa dokumen. Contoh template penamaan dokumen pada proyek adalah seperti pada penamaan chapter atau frame dengan urutan angka.

 

Kontribusi Template pada Kualitas Software 

Template cukup berguna untu tim pengembang dan juga untuk tim review. Untuk tim pengembang, template berguna untuk :
 • Memfasilitasi proses dari persiapan dokumen, dapat menyimpan waktu serta tenaga saat menyatukan struktur laporan.
• Meyakinkan bahwa dokumen yang disiapkan oleh pengembang telah komplit, seluruh subject yang terkait telah di definisikan di dokumen.
• Memberikan kemudahan integrasi kepada anggota tim yang baru, struktur dokumen yang standart memudahkan pencarian informasi bagi anggota tim baru.
 • Memudahkan mereview dokumen, struktur yang standart dan familiar memudahkan dalam mereview.

Sedangkan untuk tim review, template berguna untuk :
• Memudahkan pencarian lokasi dari informasi yang dibutuhkan untuk tugas pemeliharaan.

Dalam membuat template, tim pengembang menunjuk profesional untuk mengerjakannya. Tim ini, harus termasuk staff senior yang menjelaskan secara garis besar dari pengembangan software tersebut, kepala departmen software dan juga anggota unit jaminan kualitas software.

 

Checklist 

Checklist digunakan oleh pengembang software mengacu pada daftar item khusus yang dibuat untuk setiap jenis dokumen, atau bisa juga disebut dengan menu persiapan sebelum melakukan suatu kegiatan. Checklist direncanakan bersifat komprehensif jika tidak lengkap. Biasanya penggunaan checklist cenderung dianggap sebagai alat infrastuktur opsional. Contoh checklist :

 

 Kontribusi Checklist pada Kualitas Software  

Sama dengan template, checklist juga mempunyai manfaat bagi tim pengembang dan tim review.
Manfaat bagi tim pengembang :
• Membantu pengembang saat melakukan sendiri pemeriksaan dokumen atau kode software
• Membantu pengembang pada persiapannya melakukan tugas-tugas seperti menginstall software, mengaudit kualitas tampilan, dan lain-lain
Manfaat bagi tim review :
• Menjamin kelengkapan tinjauan dokumen oleh anggota tim review

Testing

Software testing merupakan salah satu tools dari SQA, berikut adalah penjelasan dari Software Testing menurut buku Galin

Software testing

View more presentations from ashamarsha.

SQA Architecture

SQA architecture

View more presentations from ashamarsha.

Software Quality Metrics

Software Quality Metrics terbagi menjadi 2 yaitu Product Metrics dan Process Metrics. Berikut adalah mind map dari Software Quality Metrics tersebut.

Referensi : Buku Galin

Software Quality Factors part 2

Berikut adalah revisi dari ulasan tugas akhir berdasarkan 2 dari 9 faktor yang mempengruhi kualitas software ..

Software quality factor2(2)

View more presentations from ashamarsha.

Penyebab Software Error

Manajemen Kualitas

oleh

Dian Lukitasari   -5209 100 038-

Rizka Marsa Pramadani -5209 100 044-

 

Terdapat 9 faktor yang menjadi penyebab error pada software, yaitu :

1.      Faulty requirement definition

2.      Client-developer communication failures

3.      Deliberate deviation from SW requirements

4.      Logical design errors

5.      Coding errors

6.      Non-compliance with documentation and coding instructions

7.      Shortcomings of the testing process

8.      Procedure errors

9.      Documentation errors

Berikut adalah penjelasan dari salah satu penyebab diatas berikut dengan studi kasus serta solusinya.

Faulty requirement definition merupakan error yang disebabkan oleh kesalahan dalam menganalisa kebutuhan dari klien. Dalam Faulty requirement definition, suatu software perlu diketahui dahulu apa yang dimaksud dengan software requirement. Berdasarkan sumber – sumber yang didapat. Software requirements berisikan kebutuhan dan kendala yang ditempatkan pada produk perangkat lunak yang memberikan kontribusi pada solusi dari beberapa masalah dunia nyata.

Berikut merupakan gambaran dari keseluruhan proses Software Requirement atau Analisa Kebutuhan Perangkat Lunak :

Setiap prosesnya perlu ada yang dilakukan agar analisa kebutuhan berjalan dengan baik dari awal sampai akhir pengerjaannya dan tidak terjadi kesalahan :

Perlu di perhatikan pula pada saat analisa kebutuhan. Ada 2 kebutuhan yang mempengaruhinya yaitu :

•   Kebutuhan fungsional yakni menggambarkan fungsi yang dijalankan oleh perangkat lunak

• Kebutuhan non fungisonal adalah sesuatu yang bertindak membatasi solusi. Kebutuhan non fungsional terkadang disenut sebagai batasan atau kebutuhan kualitas. Dan untuk lebih lanjut kebutuhan ini dapat diklasifikasikan ke dalam kebutuhan kinerja, kebutuhan pemeliharaan, kebutuhan keselamatan, kebutuhan keandalan, atau salah satu dari banyak jenis kebutuhan perangkat lunak

Menganalisa kebutuhan merupakan hal yang paling utama dalam mengembangkan software. Dikarenakan analisa kebutuhan yang tidak tepat akan menghasilkan perangkat lunak yang tidak berguna karena dianggap tidak memenuhi yang diinginkan klien. Kurang hati-hati dan pelaksanaan yang tidak teliti, sehingga mengakibatkan terjadinya kesalahan analisa kebutuhan sungguh menimbulkan banyak kerugian. Dengan diperolehnya kebutuhan yang jelas dan benar sesuai dengan apa yang dimaksud oleh klien, menunjukkan langkah awal yang baik, yang akan membantu ketika kita melanjutkan kepada tahap berikutnya dalam pembuatan perangkat lunak.

Ada 3 faktor yang harus dipenuhi ketika melakukan analisa kebutuhan ini yaitu :

1.      Lengkap,

2.      Detail,

3.      dan Benar.

Lengkap berarti semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisa. Sedangkan detail maksudnya adalah berhasil mengumpulkan informasi yang rinci sampai hal-hal yang kecil. Semua data dari analisa kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang difikirkan oleh pihak yang melakukan analisa.

Studi Kasus 

Suatu perusahaan software developer bernama PT Matahari bergerak dibidang software untuk POS (Point of Sale) yang digunakan di Toko-toko dan supermarket untuk transaksi dengan para pembeli dan juga untuk manajemen keluar masuk barang, dan pelaporannya. Sebuah supermarket Panama menginginkan komputerisasi di bisnis retail yang dijalankannya dengan memesan software tersebut ke PT Matahari. PT Matahari menawarkan software yang sudah dibuatnya dan banyak dipakai di beberapa supermarket dan mendemokan software tersebut pada pihak customer supermarket Panama. Ternyata ada beberapa system atau fitur yang tidak ada seperti yang diharapkan oleh customer dan fitur tersebut sangat diperlukan dalam operasi bisnis di supermarket Panama. Salah satunya adalah fitur diskon pembelian. PT Matahari menggunakan persentase dalam system diskon pembelian. Dari pihak supermarket Panama menggunakan system rupiah dalam sistem diskon pembelian karena pemberian diskon hanya diberikan pada pembeli-pembeli tertentu yang memenuhi syarat dan pertimbangan manajemen. Supermarket Panama juga menginginkan ada sistem pelaporan berupa grafik sehingga mudah dalam mengambil keputusan bisnis selanjutnya. Pihak customer menginginkan pelaporan harus sistematis, menarik, dan mudah untuk diambil kesimpulan.

Dari permasalahan tersebut diatas, perlunya requirement elicitation untuk mengindentifikasi kebutuhan costumer. Untuk mengubah fitur diskon pembelian dari sistem persen ke rupiah mungkin sudah jelas, dan terdefinisi dengan baik, dan relative mudah untuk dimengerti oleh pihak software developer. Namun untuk fitur pelaporan yang menarik, sistematis dan mudah untuk diambil kesimpulan merupakan permasalahan cenderung abstrak. Dan ini mungkin pekerjaan ini memerlukan beberapa kali revisi karena tidak sesuai dengan kebutuhan customer.

Solusi :

Sebaiknya pihak developer mencari aspek-aspek apa saja yang diinginkan dalam sistem pelaporan dan manajemen bisnis retail dan mendefinisikannya dalam requirement specification untuk ditetapkan sebagai acuan pembuatan software yang bisa dipahami oleh kedua belah pihak. Requirement specification ini digunakan sebagai batasan pekerjaan yang harus dikerjakan oleh software developer, sehingga ketika tahap testing, customer tidak lagi menuntut jika customer ternyata masih merasa ada requirement yang terlupakan pada software tersebut. Permintaan agar software tersebut menarik dan mudah dipahami sebaiknya developer mendesain GUInya terlebih dahulu sebelum memulai coding. Jika GUI sudah disetujui maka akan digunakan sebagai acuan untuk proyek pembuatan software. Namun sebaiknya pihak developer masih tetap fleksibel untuk melayani jika customer meminta perubahan pada desain atau requirement specification yang sudah ditetapkan bersama dengan pertimbangan tertentu misalnya, pihak customer harus mengganti biaya revisi.

Referensi :

http://teguh8581.wordpress.com/tag/requirement-engineering/

http://suryainformation.wordpress.com/2010/05/23/analisis-kebutuhan-dalam-rekayasa-perangkat-lunak/

http://s2informatics.wordpress.com/2007/06/19/studi-kasus-software-development/

(http://www.slideshare.net/yaqinov/kebutuhan-perangkat-lunak)