Bagaimana menghitung Function Point?

kali ini kita akan membahas tentang Fungtion Point (FP). Kegunaan Function Point dapat diilustrasikan seperti membangun sebuah rumah, yaitu terdiri dari beberapa komponen pembentuk seperti pintu, atap, jendela, dan lainnya. Masing-masing komponen pasti mempunyai biaya yang harus dikeluarkan. Jadi, Function Point ini bertujuan untuk mengestimasi cost masing-masing komponen atau besarnya biaya pengembangan sebuah proyek. Kapan Function Point ini relevan untuk digunakan? Yaitu ketika history dari suatu pengembangan proyek sudah diketahui (dengan kata lain, proyek yang sama sudah pernah dibuat).

Pada dasarnya, dengan Function Point, kita dapat mengestimasi biaya pembuatan software. Apa tantangan untuk melakukan ini :

1. Harus mencari history/riwayat proyek yang serupa
2. Menentukan/mendefinisikan software system componenets (tahap requirement dan design)

Berikut ini adalah contoh cara menghitung Function Point :

Attend-Master adalah sistem absensi karyawan dasar yang direncanakan untuk melayani perusahaan kecil dan menengah yang mempekerjakan 10-100 karyawan. Sistem ini direncanakan akan memiliki interface untuk paket lain perangkat lunak perusahaan : Human-Master, yang melayani unit sumber daya manusia, dan Wage-Master, yang melayani masalah penggajian. Attend-Master direncanakan untuk menghasilkan beberapa laporan dan query online. Skema dari sistem perangkat lunak yang direncanakan ditemukan dalam diagram aliran data (DFD) yang ditunjukkan di bawah ini.

 Tahap 1: Perhitungan fungsi poin mentah
• Analisis sistem perangkat lunak seperti yang disajikan dalam DFD merangkum jumlah berbagai komponen: 
Number of user inputs –2
Number of user outputs –3
Number of user online queries –3
Number of logical files –2
Number of external interfaces –2
Tingkat kompleksitas (Simple/sederhana, Average/rata-rata atau Complex/kompleks) dievaluasi untuk setiap komponen, setelah perhitungan CFP dilakukan.

 

•Tahap 2: Menghitung relative complexity adjustment factor (RCAF) 

 

Tahap 3: Menghitung Number of Function Point (FP).
• Setelah menerapkan rumus tersebut, perhitungan dilakukan sebagai berikut:
• FP = CFP × [0,65 + 0,01 × RCAF) = 81 × (0,65 + 0,01 × 41) = 85.86

Mengontrol Proses Dokumentasi Penjaminan Kualitas Software

Pengembangan perangkat lunak dan proses pemeliharaan melibatkan produksi dan penggunaan banyak dokumen, beberapa sangat penting segera sementara yang lain mungkin menjadi penting untuk jaminan kualitas perangkat lunak selama siklus hidup sistem. Tujuan utama dalam mengelola dokumen yang harus dikontrol antara lain :

1. Untuk menjamin kualitas dokumen. 
2. Untuk menjamin kelengkapan teknis dan sesuai dengan struktur dokumen prosedur dan instruksi (penggunaan template, penandatanganan yang tepat, dll). 
3. Untuk menjamin ketersediaan masa depan dokumen yang mungkin diperlukan untuk perangkat lunak sistem pemeliharaan, pengembangan lebih lanjut, atau tanggapan terhadap pelanggan itu (tentatif) keluhan masa depan. 
4. Untuk mendukung penyelidikan penyebab kegagalan perangkat lunak dan untuk menetapkan tanggung jawab sebagai bagian dari tindakan korektif dan lainnya.

Quality Record adalah jenis khusus dari sebuah controlled dokumen (dokumen yang perlu dikontrol). Ini adalah dokumen yang ditargetkan untuk konsumen (customer-targeted) yang mungkin diperlukan untuk menunjukkan bahwa pengerjaan pengembangan perangkat lunak dengan persyaratan pelanggan dan operasi yang efektif dari sistem penjaminan kualitas perangkat lunak untuk seluruh proses pembangunan dan pemeliharaan.

Training dan Sertifikasi Staff

Ada sebuah perkataan bahwa mempertahankan staff yang berpengalaman dan handal merupakan kunci untuk mencapai kualitas pada fase pengembangan dan maintenance. Oleh karena itu, kita perlu melakukan training dan sertifikasi untuk staff-staff yang menempati posisi penting (core) dalam suatu organisasi. Untuk lebih jelasnya, tujuan dari training dan sertifikasi staff adalah :

1. Untuk mengembangkan pengetahuan dan keterampilan staf baru yang diperlukan untuk melakukan tugas pengembangan dan pemeliharaan perangkat lunak pada tingkat efisiensi dan efektivitas yang memadai. Seperti pelatihan untuk memfasilitasi integrasi anggota tim baru.
2. Untuk menjamin kesesuaian dengan standar organisasi untuk produk perangkat lunak (dokumen dan koding) dengan mengirimkan style dan struktur prosedur bersamaan dengan instruksi kerja.
3. Untuk memperbarui pengetahuan dan keterampilan staf lama dalam menanggapi perkembangan organisasi, dan untuk menjamin efisiensi dan efektifitas pelaksanaan tugas serta kesesuaian dengan budaya organisasi, struktur, prosedur dan instruksi kerja.
4. Untuk menyampaikan pengetahuan seputar prosedur penjaminan kualitas software
5. Untuk memastikan bahwa kandidat untuk posisi kunci dalam hal pengembangan dan pemeliharaan software benar-benar berkualifikasi.

Pengimplementasian training dan sertifikasi staff yang sukses perlu memperhatikan aktivitas berikut yang harus dilaksanakan secara sistematis :

1. Tentukan persyaratan pengetahuan profesional untuk setiap posisi
2. Tentukan pelatihan profesional dan memperbarui kebutuhan
3. Merencanakan program pelatihan profesional
4. Merencanakan program memperbarui profesional
5. Tentukan posisi yang memerlukan sertifikasi
6. Rencana proses sertifikasi 
7. Memberikan pelatihan, memperbarui dan sertifikasi program
8. Lakukan tindak lanjut dari staf yang terlatih dan bersertifikat.

Biaya pada proses penjaminan kualitas software

Dalam menjamin kualitas perangkat lunak, pastinya akan diperlukan biaya. Cost of Software Quality management bertujuan untuk mengukur biaya yang dibutuhkan dalam membuat sebuah software (mengontrol biaya). Cost of software quality dibagi menjadi dua, yaitu Cost of Control dan Cost of Failure of Control.

Cost of control adalah biaya yang dibutuhkan untuk mencegah adanya error dan mendeteksi error. Cost of control dibagi menjadi Prevention cost dan Appraisal cost. Prevention Cost adalah biaya-biaya termasuk biaya investasi untuk infrastruktur kualitas, aktifitas, untuk menjaga kualitas. Sedangkan Appraisal Cost adalah biaya yang dibutuhkan untuk mendeteksi sebuah error pada software.

Cost of Failure of Control adalah biaya yang dikeluarkan karena kesalahan pengontrolan. Cost of Failure of Control dibagi menjadi dua yaitu Internal failure dan external failure. Internal failure cost adalah biaya-biaya termasuk biaya untuk memperbaiki error yang ditemukan saat design review, software test, dan acceptance test yang harus dilengkap sebelum software di deliver ke client. Sedangkan External failure cost adalah biaya yang dibutuhkan untuk memperbaiki error yang ditemukan client setelah software diinstal (complaint dari konsumen).

Manajemen Konfigurasi Perangkat Lunak

Tujuan manajemen konfigurasi pada penjaminan kualitas perangkat lunak :

1. Mengidentifikasi perubahan
2. Mengontrol perubahan
3. Memastikan perubahan diimplementasikan dengan benar
4. Melaporkan perubahan ke semua pihak yang bersangkutan

Baseline : sesuatu yang dilakukan pertama kali sebagai syarat untuk proses kedepannya
Basic Change Process, langkah-langkahnya :

1. Membuat change request
2. Menentukan apakah request diterima/ditolak
3. "Check out" perubahan yang diusulkan
4. Membuat perubahannya
5. Testing/review
6. Review Susunan/urutan perubahan
7. Mengidentifikasi independency

Template dan Checklist sebagai Alat Bantu Penjaminan Kualitas Software

Template dan Checklist dapat digunakan sebagai alat bantu dalam menjamin kualitas sebuah perangkat lunak. Berikut ini adalah penjelasan mengenai Apa itu template dan checklist beserta manfaatnya dalam hal membantu menjamin kualitas sebuah software.
Template adalah sebuah format yang dibuat oleh organisasi untuk menyajikan laporan/dokumen. Manfaat menggunakan template bagi Development team adalah:

1. Memfasilitasi  proses menyiapkan dokumen
2. Dokumen yang dibutuhkan menjadi lebih lengkap penyajiannya
3. Menyamakan persepsi antar anggota team (integration)
4. Review proses pengembangan lebih menyeluruh dan lebih konsisten

Sedangkan manfaatnya untuk Review Team adalah untuk mempermudah pencarian lokasi informasi yang dibutuhkan jika ada maintenance.

Template, dalam organisasi, proses pembuatannya adalah seperti di bawah ini :

1. Preparing new Templates : Membuat daftar target pada template --> membuat draft --> mengkomunikasikannya ke anggota lain
2. Implementation of (New/Updated) templates : untuk mendorong anggota organisasi menggunakan suatu template, bisa mencamtumkan peraturan tersebut pada prosedur kerja/intruksi kerja
3. Updating templates : template diupdate jika ada saran perubahan dari user, adanya perubahan aktifitas suatu organisasi

Checklist adalah daftar item yang harus dilakukan / dilengkapi untuk melakukan suatu pekerjaan. Manfaat yang dapat diperoleh dari sebuah checklist untuk Development team adalah :

1. Membantu developer untuk mengetahui self-checks of document dan mendeteksi dokumen yang tidak lengkap
2. Membantu developer untuk mempersiapkan apa yang dilakukan kemudian

Manfaat checklist bagi Review team adalah untuk memastikan kegiatan sudah dilakukan.

Mengontrol Progres Pengerjaan Proyek

Jarang sekali pada saat pengerjaan sebuah proyek, proyek tersebut selesai sesuai dengan jadwal yang sudah ditetapkan. Pengerjaan proyek bisa lebih cepat maupun lebih lama. Oleh karena itu, Project Progress Control mempunyai peran untuk mengontrol progress pengerjaan proyek agar waktu yang dipakai sesuai dengan yang telah disepakati dan dijadwalkan di awal. Masalah yang terjadi dalam pengerjaan suatu proyek ini biasanya disebabkan oleh hal-hal seperti berikut :

1. Terlalu optimis dalam melakukan penjadwalan dan penganggaran.
2. Kurangnya profesionalitas dalam menggunakan perangkat lunak manajemen resiko.
3. Keterlambatan dalam mengidentifikasi masalah jadwal dan anggaran.

Masalah pertama dan kedua biasanya bisa dicegah dengan penggunaan contract review dan project planning tools. Sedangkan masalah ketiga bisa dicegah dengan menggunakan project progress control.

 

Project progress control sendiri memiliki komponen-komponen sebagai berikut :

1. Kegiatan pengendalian manajemen risiko
• Hal ini mengacu pada risiko pengembangan perangkat lunak yang diidentifikasi dalam tahap preproyek yang tercantum dalam contract review dan project plan. Kontrol dari manajemen risiko dimulai dengan persiapan penilaian berkala tentang keadaan risiko perangkat lunak dan hasil yang diharapkan. 
2. Kontrol jadwal proyek (schedule)
• Hal ini berkaitan dengan kesesuain proyek dengan jadwal yang telah disetujui sesuai dengan kontrak. Agar bisa mencapai target yang diinginkan pengembang harus bisa mengikuti milestone yang telah dibuat sebelumnya.
3. Kontrol sumber daya proyek (resource)
• Hal ini tentu saja berfokus pada sumber daya manusia yang profesional namun bisa juga berkaitan dengan aset yang lainnya.
4. Kontrol anggaran proyek (budget)
• Hal ini berkaitan dengan anggaran dan biasanya anggaran ini berkaitan dengan jadwal dari proyek yang diadakan. Semakin lama suatu proyek mengalami kemunduran maka anggaran yang dikeluarkan pun akan semakin besar. Anggaran yang biasanya dikeluarkan berkaitan dengan :
• Sumber daya manusia
• Fasilitas pengembangan dan pengujian
• Pembelian COTS perangkat lunak
• Pembelian perangkat keras
• Pembayaran subkontraktor

Testing

Testing Plan on Prezi

Apa itu Requirement Traceability Matrix?

Konsep Treaceability Matrix adalah untuk dapat melakukan penelusuran mulai dari persyaratan tingkat atas sampai implementasi, atau mulai dari persyaratan tingkat sampai proses pengujian.

Sebuah Traceability Matrix adalah tabel yang digunakan untuk menelusuri kebutuhan untuk tes yang diperlukan untuk memverifikasi bahwa persyaratan tersebut terpenuhi. Sebuah Traceability Matrix yang baik akan memberikan kemudahan dalam melakukan penelusuran kedepan atau kebelakang, yaitu kebutuhan dapat ditelusuri mulai dari fase requirement sampai fase testing dan atau dari fase testing ke fase requirement. Matriks ini dapat menghubungkan kebutuhan pada tingkat yang lebih tinggi, spesifikasi desain, testing requirement, dan program (coding) itu sendiri. Karena berfungsi sebagai peta, menyediakan link yang diperlukan untuk menentukan mana informasi berada,  hal ini juga dikenal sebagai Requirement Traceability Matrix atau RTM.

 

RTM banyak digunakan untuk penjaminan kualitas sehingga developer dapat memastikan bahwa client mendapat apa yang mereka minta. Matriks Lacak juga membantu pengembang mencari tahu mengapa beberapa kode diimplementasikan seperti yang telah dilakukan, dapat dilakukan penelusuran muali dari coding sampai ke pendefinisian kebutuhan. Jika testing gagal, dimungkinkan untuk menggunakan RTM untuk melihat apa saja yang berhubungan dengan fase pendefinisiankebutuhan dan fase testing

Tujuan dari Requirement Traceability Matrix :

1. Untuk memastikan bahwa persyaratan yang sudah disetujui sudah tercakup dalam semua fase pengembangan: Mulai dari Software Requirement Specification (SRS), Pengembangan perangkat lunak, testing, lalu di-deliver kepada client.

2. Memastikan bahwa setiap dokumen harus dapat ditelusuri: Test case yang sudah dipersiapkan harus sesuai dengan spesifikasi kebutuhan yang sudah ditetapkan. Jika ada versi update, dokumen test case harus dapat ditelusuri dengan itu.

Komponen Penjaminan Kualitas Software pada Siklus Hidup Pengembangan Proyek

Siklus hidup proyek dapat dibagi ke dalam dua fase besar yaitu, siklus hidup fase pengembangan dan siklus hidup fase operasi-maintenance. Komponen penjaminan kualitas perangkat lunak, pada fase pengembangan dimaksudkan untuk mendeteksi error pada desain dan program (coding). Penjaminan pada fase ini dibagi ke dalam 4 sub kelas, yaitu :
a.    Formal design reviews
b.    Peer reviews
c.    Expert opinions
d.    Software testing

Sedangkan komponen penjaminan kualitas perangkat lunak pada fase operasi-maintenance dimaksudkan supaya fase pemeliharaan dilakukan dengan benar.

Ada banyak jenis metode pengembangan perangkat lunak yang dapat dilakukan oleh seorang developer, antara lain SDLC (Software Development Life-Cycle) Waterfall, Prototype, Increment, Agile, dan lain-lain. Setiap SDLC memiliki perlakuan berbeda untuk menjamin kualitas perangkat lunak yang dibuat karena setiap SDLC mempunyai tahap-tahap siklus yang berbeda. Aktivitas penjaminan kualitas akan berbeda pada setiap proyek dikarenakan faktor-faktor berikut ini :
1.    Faktor Proyek
a.    Besar kecilnya ruang lingkup proyek
b.    Tingkat kesulitas atau kompleksitas teknis
c.    Tingkat komponen perangkat lunak untuk digunakan kembali
d.    Tingkat besarnya biaya yang dikeluarkan jika proyek gagal
2.    Faktor Team
a.    Kualifikasi professional dari anggota tim
b.    Mitra tim yang mempunyai keahlian di bidang yang bersangkutan
c.    Ketersediaan anggota staff yang dapat membantu tim secara professional
d.    Prosentase anggota staff baru dalam sebuah tim (familiaritas)

Tiga aspek penjaminan kualitas produk perangkat lunak diulas dalam verifikasi, validasi, dan kualifikasi. Penjelasan untuk masing-masing aspek tersebut adalah sebagai berikut :
1.    Verifikasi : Proses evaluasi sistem atau komponen untuk menentukan apakah produk dari tahap pengembangan diberikan memenuhi kondisi yang dikenakan pada awal fase
2.    Validasi : Proses evaluasi sistem atau komponen selama atau pada akhir dari proses pembangunan untuk menentukan apakah itu memenuhi persyaratan yang ditentukan
3.    Kualifikasi : Proses yang digunakan untuk menentukan apakah sistem atau komponen cocok untuk penggunaan operasional

Merencanakan Proses Pengembangan Software dan Penjaminan Kulitasnya

Perencanaan, sebagai sebuah proses, pastinya mempunyai beberapa tujuan yang masing-masing tujuan tersebut dimaksudkan untuk mempersiapkan fondasi atau dasar yang kokoh untuk melakukan kegiatan berikut ini :
a.    Menjadwalkan aktivitas pengembangan proyek agar berjalan sesuai dengan waktu dan budget yang ditentukan
b.    Merekrut sumber daya manusia yang handal dan menempatkannya sesuai dengan jobdesc masing-masing
c.    Menyelesaikan masalah resiko yang terjadi dalam proses pengembangan
d.    Mengimplementasikan aktivitas penjaminan kualitas software yang diperlukan
e.    Menyediakan data-data yang dibutuhkan manajemen untuk mengontrol proyek

Perencanaan pengembangan software memiliki beberapa elemen. Berikut ini adalah elemen-elemen perencanaan pengembangan proyek yang disesuaikan dengan masing-masing komponen proyek ;
a.    Project Products
Perencanaan pengembangan untuk komponen ini termasuk membuat desain dokumen (tentang tanggal penyelesaian proyek, kapan produk harus diserahkan kepada klien), merencanakan seperti apa produk yang akan dibuat, dan merencanakan proses training.
b.    Project Interfaces
Untuk antar muka proyek meliputi merancang antar muka dengan paket-paket software atau hardware yang sudah ada sekarang, juga antar muka antara tim pengembang lain yang bekerja dalam sistem yang sama.
c.    Project methodology and development tools
Merencanakan metodologi dan alat-alat apa yang diperlukan selama proses pengembangan software
d.    Software development standard and procedures
Daftar prosedur atau tata cara pengembangan software harus sudah didefinisikan supaya proses pengerjaan proyek dapat terarah dan mudah dimonitoring
e.    The mapping of the development process
Elemen ini merencanakan tentang memetakan proses pengembangan terkait dengan menyediakan definisi yang detail untuk masing-masing fase proyek dan mendifinisikan input dan output proyek tersebut.
f.    Project milestones
Merencanakan proses mana yang ditetapkan sebagai milestone (proses penting yang harus diselesaikan untuk dapat memulai proses lain)
g.    Project staff organization
Membuat rencana struktur organisasi, siapa yang akan menjadi team leader, berapa sumber daya manusia yang dibutuhkan, dan menentukan posisi yang sesuai dengan skill masing-masing anggota tim.
h.    Development facilities
Merencanakan fasilitas pengembangan apa saja yang dibutuhkan termasuk hardware, software, ruang kerja, alat-alat pengembangan, dan lainnya.
i.    Development risks
Setiap mengerjakan suatu proyek, pasti selalu ada risiko yang menyertai. Tim proyek harus dapat memprediksikan risiko apa yang akan muncul nantin ya, bagaimana cara menanggulangi risiko yang akan muncul, dan mengestimasi budget yang kira-kira perlu dikeluarkan untuk menanggulangi risiko tersebut.
j.    Control methods
Pihak manajemen harus dapat membuat rencana bagaimana caranya proyek tersebut terus dimonitoring dan dikontrol.
k.    Project cost estimation
Merencanakan budget dapat ditinjau dari dana yang sudah diajukan sebelumnya di proposal, lalu direview kembali dan dinegosiasikan dengan pihak-pihak lain yang terkait.

Perencanaan penjaminan kualitas software memiliki beberapa elemen. Berikut ini adalah elemen-elemen perencanaan penujaminan kualitas proyek yang dapat disesuaikan dengan jenis proyek yang akan dikerjakan:
a.    Quality goals
b.    Planned review activities
c.    Planned software tests
d.    Planned acceptance test for externally developed software
e.    Configuration management

The Software Quality Assurance Architecture

Dalam penjaminan kualitas sebuah perngkat lunak, terdapat banyak komponen-komponen yang harus diperhatikan agar proses penjaminan kualitas perangkat lunak memperoleh hasil yang diinginkan sebelum software tersebut disampaikan kepada klient. Seperti yang telah kita tahu bahwa setiap proses pengerjaan proyek, setiap fase memiliki lama waktu pengerjaan yang berbeda dan membutuhkan biaya yang berbeda pula. Berdasarkan gambar dibawah ini, fase Eksekusi (Execution) membutuhkan waktu paling banyak dan membutuhkan biaya paling besar. Oleh karena itu, perlu memperhatikan beberapa proses supaya waktu dan biaya proyek tidak membengkak dan kualitas yang diharapkan..

Berikut ini adalah gambar tentang Arsitektur Penjaminan Kualitas Software. Dalam Arsitektur Penjaminan Kualitas Software, ada beberapa komponen untuk menentukan kualitas software. Sistem Penjaminan Kualitas Perangkat Lunak dapat diklasifikasikan ke dalam 6 kelas, yaitu :

1. Pre-Project components : untuk memastikan bahwa perjanjian atau kesepakatan sudah didefinisikan dengan jelas dan sudah mempertimbangkan kebutuhan sumber daya, jadwal, dan anggaran.
2. Components of project life cycle activities assessment : Sikulus hidup proyek dibagi menjadi dua fase, Fase pengembangan dan fase pengoperasian-pemeliharaan.
3. Components of infrastructure error prevention and improvement : tujuan utama dari komponen ini adalah untuk menghilangkan atau paling tidak mengurangi tingkat error berdasarkan pengalaman organisasi dalam hal penjaminan kualitas software
4. Components of software quality Management : dimaksudkan untuk beberapa tujuan, menjadi kontrol dalam proses pengembangan dan kegiatan pemeliharaan dan pengenalan tindakan manajerial support awalyang terutama mencegah atau meminimalkan jadwal, kegagalan anggaran, dan outcome
5. Componenets of standardization, certification, and SQA system assessment : tujuan dari komponen pemanfaatan pengetahuan profesional internasional, peningkatan koordinasi sistem kualitas organisasi dengan organisasi lain, dan penilaian pencapaian dari kualitas sistem berdasarkan skala umum
6. Organizing for SQA - the human components : semua sumber daya manusia yang berhubungan dengan penjaminan kualitas software termasuk manajer, personil testing, anggota komite, SQA unit dan praktisi, dan lain-lain.

Software Quality Metrics

Software Quality Metrics adalah sebuah pengukuran kuantitatif terhadap sesuatu yang dijadikan sebagai atribut dalam menentukan kualitas suatu perangkat lunak (Software). Ada dua klasifikasi software quality metrics, yaitu Process metrics (pengukuran yang berhubungan dengan proses pengembangan software) dan Product metrics (pengukuran yang berhubungan dengan pemeliharaan software). Berikut ini adalah klasifikasi software quality metrics secara lebih rinci :

1. Process Metrics
• Software process quality metrics
• Error density metrics
• Software volume measures
• Errors counted measures
• Error severity metrics
• Software process timetable metrics
• Error removal effectiveness metrics
• Software process productivity metrics
2. Product Metrics

• HD quality metrics

• HD calls density metrics
• Metrics of the severity of the HD issues raised
• HD success metrics

• HD productivity and effectiveness metrics
•  HD productivity metrics
•  HD effectiveness metrics
• Corrective maintenance quality metrics
• Software system failures density metrics : berhubungan dengan kebutuhan untuk melakukan perbaikan perangkat lunak berdasarkan kegagalan sistem yang ditemukan pada saat pengoperasian software
• Software system failures severity metrics : berhubungan dengan tingkat keparahan kegagalan sistem yang dilakukan oleh tim maintenance
• Failures of maintenance services metrics : untuk mengukur jika pemeliharaan jtidak dapat menyelesaikan perbaikan kegagalan pada waktu tertentu
• Software system availability metrics : berhubungan dengan tingkat gangguan
  yang dialami pelanggan karena layanan dari sistem perangkat lunak tidak tersedia atau hanya sebagian yang tersedia
• Software corrective maintenance productivity and effectiveness metrics

Sembilan(9) penyebab software error dan Faktor Kualitas Software: Hal yang perlu diketahui dalam menjamin kualitas software

Ada 9 penyebab error saat pengembangan software. Sembilan penyebab error tersebut adalah sebagai berikut :

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

Salah satu penyebab software error adalah coding error. Coding error adalah salah satu penyebab kesalahan pada pengembangan software yang terjadi karena developer salah menerjemahkan dokumen desain software ke dalam sebuah bahasa pemrograman, salah memasukkan data, salah menggunakan tools, dan lainnya. 

Studi Kasus : 

•  Kasus ini merupakan kasus nyata yang pernah dilakukan oleh kami sendiri pada saat mengerjakan proyek pembutan perangkat lunak beberapa bulan yang lalu. Masalah yang terjadi adalah program yang kami buat sudah tidak ada error yang muncul dan tidak ada notifikasi error saat dicomplie. Tetapi data yang dimasukkan ke dalam form Barang yang dibeli tidak bisa masuk ke database.

• Setelah ditelusuri, ternyata developer (kami) salah mendefinisikan tipe data di codingan dan row yang ada di database kurang satu atribut lagi 

 Hal yang dilakukan untuk mengatasi permasalahan tersebut adalah dengan merubah tipe data sesuai dengan requirement dan menambah satu atribut / kolom Barang_beli di database. Setelah itu, untuk mencegah timbulnya permasalahan yang sama, developer melakukan penelusuran kepada codingan-codingan di class lain.

Documentation error juga merupakan salah satu penyebab software error. Yang dimaksud dengan documentation error adalah kesalahan menjelaskan desain pernagkat lunak, tampilan, atau user manual. Selanjutnya adalah Non-compliance with documentation and coding instruction. Faktor yang ini sebenarnya mempunyai keterkaitan dengan Documentation error. Maksud dari Non-compliance with documentation and coding instruction adalah ketidakpatuhan software developer terhadap dokumen requirement atau diagram aktivitas. Terkadang developer mengerti maksud requirement yang dibutuhkan tetapi tidak cukup baik untuk menjelaskan dalam laporan. Bisa juga hal ini dikarenakan developer yang merasa sudah mengerti apa yang harus dilakukan sehingga developer tersebut tidak menggunakan dokumen yang ada sebagai panduan.

Studi Kasus 2 :
Studi kasus ini diambil dari tugas akhir yang berjudul :

 RANCANG BANGUN SISTEM INFORMASI E-KATALOG PENGADAAN MOBIL INSTANSI PEMERINTAH

SPSE saat ini hanya mampu melakukan pengadaan dengan sistem tender/lelang. Sedangkan sebagian Pengadaan Barang/Jasa akan lebih efisien dan cepat jika dilakukan dengan sistem pembelian langsung (e-purchasing). Jadi dengan adanya software ini akan menjadikan pengadaan barang/jasa lebih efisien, yaitu mempermudah pihak LKPP dalam menstandarisasi spesifikasi barang yang masuk ke dalam E-Katalog, mempermudah pihak Panitia Pengadaan untuk melakukan pembelian langsung melalui E-Purchasing dan mempermudah proses verifikasi para penyedia barang.

Efficiency : Kebutuhan efisiensi berkaitan dengan sumber daya perangkat keras atau hardware yang dibutuhkan untuk menjalankan semua fungsi dari sistem software dengan keseuaian terhadap semua kebutuhan. Sumber daya hardware utama yang dipertimbangkan adalah kapasitas memproses dari komputer tersebut, kapasitas penyimpanan data, dan kapabilitas komunikasi data.

Kesimpulan :
Jadi, menurut kami, software ini sudah efisien, karena spesifikasi minimal yang di butuhkan gampang di temui.

Correctness adalah sejauh mana suatu software memenuhi spesifikasi dan mission yang sudah ditetapkan sebelumnya(dokumen SKPL). 
(Source : http://www.scribd.com/doc/45660350/44/KRITERIA-PENJAMINAN-KUALITAS-SOFTWARE )

Kesimpulan :
Dari ketiga test case yang dipaparkan di dalam buku TA menyatakan bahwa Use case tersebut sudah terbukti benar jika dilihat dari segi Correctness-nya. Tetapi tidak semua use case ditampilkan hasil test case nya. oleh karena itu, pembuktian Correctness hanya terbatas pada pada ketiga use case tersebut (Tambah katalog, Rubah detail katalog, dan Penambahan ATPM)

Powered by :

1. Onny Fortunela  (5209100159)
2. Nurul Fakhria     (5209100097)

Tantangan Manajemen Kualitas : Quality Management Challenges

Saat Anda mendengar tentang Tantangan Manajemen Kualitas,  apa hal pertama yang terlintas di benak Anda? Berikut ini adalah penjelasan mengenai tantangan manajemen kualitas yang diambil dari buku  Software Quality Assurance karangan Daniel Galin beserta studi kasus untuk memudahkan memahami materi.

Quality Management Challenges on Prezi