SOFTWARE QUALITY ASSURANCE

dokumen-dokumen yang mirip
SOFTWARE QUALITY ASSURANCE

Chapter 3 Software Quality Factors

Manajemen kualitas proyek (Project Quality Management)

SOFTWARE QUALITY ASSURANCE

BAB II LANDASAN TEORI. Sebenarnya tidaklah mudah mendefinisikan kualitas secara tepat. Konsep

ANALISIS KUALITAS PERANGKAT LUNAK TERHADAP SISTEM INFORMASI UNIKOM

Review Perangkat Lunak StarUML Berdasarkan Faktor Kualitas McCall

Review Perangkat Lunak StarUML Berdasarkan Faktor Kualitas McCall

Manajemen Kualitas TI

SPESIFIKASI KEGUNAAN (USABILITY) Chalifa Chazar Modul :

SOFTWARE QUALITY ASSURANCE

ANALISIS KUALITAS PERANGKAT LUNAK TERHADAP SISTEM INFORMASI STT WASTUKANCANA PURWAKARTA

ANALISA & PERANCANGAN SISTEM

SOFTWARE QUALITY ASSURANCE

KONTROL KUALITAS PADA PERANGKAT LUNAK

INTERAKSI MANUSIA & KOMPUTER. Chalifa Chazar Modul :

SOFTWARE QUALITY ASSURANCE

BAB II LANDASAN TEORI. Menurut Abdul kadir ( 2003:202) perangkat lunak (software) yaitu:

SOFTWARE QUALITY ASSURANCE

SOFTWARE QUALITY ASSURANCE

BAB II LANDASAN TEORI. mengidentifikasikan adanya lima perspektif kualitas yang biasa digunakan

PENGUJIAN KUALITAS SISTEM PAKAR DETEKSI KERUSAKKAN MESIN SEPEDA MOTOR NON MATIC DENGAN MENGGUNAKAN METODE MC CALL

BAB II LANDASAN TEORI. digunakan untuk memodelkan kebutuhan data dari suatu organisasi,

BAB III METODOLOGI PENELITIAN. Tahap Pengumpulan Data. Tahap Analisa. Tahap Implementasi. Tahap Pengujian. Gambar 3.1 Metodologi Penelitian

3/17/16 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

SOFTWARE QUALITY ASSURANCE

Testing dan Implementasi Sistem

14. PENGUJIAN PERANGKAT LUNAK Dasar-dasar Pengujian 14.2 Teknik Pengujian 14.3 Strategi Pengujian dan V&V

HALAMAN PENGESAHAN LAPORAN AKHIR

Enterprise Architecture Planning

BAB II TINJAUAN PUSTAKA DAN DASAR TEORI

Dosen : Dr. Ir. Arif Imam Suroso, M.Sc, CS. Disusun Oleh : Ednan Setryawan Wibowo P

Pendahuluan. Tes Implementasi System. Yahya Erdipasa, ST., M.Kom (candidate) Teknik Informatika

Kualitas Perangkat Lunak. Dasar Rekayasa Perangkat Lunak

PENGUJIAN SISTEM INFORMASI AKADEMIK MENGGUNAKAN MCCALL S SOFTWARE QUALITY FRAMEWORK

Chapter 11 Assuring the quality of software maintenance components

BAB III PEMBAHASAN. UKM menggunakan metode Waterfall yang terdiri dari tahap: analisis,

Enterprise Architecture Planning

Enterprise Architecture Planning

BAB V PENUTUP 5.1 Kesimpulan dan Rekomendasi usability

Tujuan Perkuliahan. PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Agenda. Definisi Software (Perangkat Lunak) Lunak) 23/09/2010

BAB III HASIL DAN PEMBAHASAN

Analisa Sistem Dan Desain

KOMPONEN PENILAIAN KUALITAS PERANGKAT LUNAK BERDASARKAN SOFTWARE QUALITY MODELS

ANALISA KEBERHASILAN SISTEM ERP STUDI KASUS : PT. AUTONETSYS INDONESIA

ANALISA PENGEMBANGAN MODEL KUALITAS BERSTRUKTUR HIRARKI DENGAN KUSTOMISASI ISO 9126 UNTUK EVALUASI APLIKASI PERANGKAT LUNAK B2B

Penerapan dan Evaluasi Aplikasi Sistem Informasi Fasilitas Umum Kota Prabumulih Berbasis Android

TUGAS UJIAN INDIVIDU MATA KULIAH SISTEM INFORMASI MANAJEMEN

Enterprise Architecture Planning

KONSEP MANAJEMEN PROYEK

Enterprise Architecture

PENTINGNYA PEMELIHARAAN SOFTWARE

Enterprise Architecture Planning

MEMASYARAKATKAN DAN MEMPEROLEH CONCERN AKAN SOFTWARE QUALITY, Sebagai FAKTOR PENDORONG PENERAPAN CMMI atau CMM-SW

APLIKASI KOMPUTER. Komponen Dasar Komputer & Sistem Operasi. Chalifa Chazar MN- APLIKASI KOMPUTER (MANAJEMEN)

Enterprise Architecture Planning

RENCANA PEMBELAJARAN

Munir, Dr. M.IT : Pengembangan Proyek Sistem 133

DAFTAR ISTILAH. Baseline testing Tipe pengujian untuk mengidentifikasi permasalahan performansi lebih awal.

Perangkat Keras pada mesin ATM Perangkat Lunak pada Mesin ATM Parameter dan Metode Pengukuran

BAB III PEMBAHASAN. untuk menampilkan ringkasan dari teks yang dimasukkan pengguna. Ringkasan

BAB I 1. PENDAHULUAN. dan efektifitas kerja. Perkembangan teknologi internet, sebagai contoh,

KUALITAS PERANGKAT LUNAK. Ni Wayan Sumartini Saraswati

URGENSI MAINTENANCE DALAM PENGEMBANGAN SOFTWARE SYSTEM

1. Pendahuluan 1.1 Latar Belakang

Chapter 2 What is Software Quality?

Testing & Implementa si Sistem -Pengenalan. Pertemuan ke - 1

BAB 5 FAKTOR PENGUJIAN

1.1 Latar Belakang BAB 1 PENDAHULUAN

MEMBANGUN WEBSITE KOMUNITAS IKATAN ALUMNI UNIVERSITAS SAHID SURAKARTA

Penyusunan Perangkat Kontrol Kualitas Perangkat Lunak Pada Aplikasi School Social Network (SSN) Berdasarkan ISO 25030

Enterprise Architecture Planning

Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

BAB III ANALISIS III.1 Analisis Perbandingan terhadap Sistem Lain

Web Engineering Mengenal Rekayasa Web. Husni Husni.trunojoyo.ac.id

Kualitas Software dan Pengujian

MANAJEMEN PROYEK PERANGKAT LUNAK PROYEK Proyek adalah suatu kegiatan mengkoordinasikan segala sesuatu dengan menggunakan perpaduan sumber daya

Pengukuran Perangkat Lunak. Pengantar

Software Requirements Specification (SRS) atau Spesifikasi Kebutuhan Perangkat Lunak (SKPL)

PERENCANAAN PROYEK PERANGKAT LUNAK

EVALUASI. Chalifa Chazar Modul :

BAB III METODOLOGI PENELITIAN

BAB 4 PROSES PERANGKAT LUNAK & METRIK PROYEK

REKAYASA PERANGKAT LUNAK

Model Analisa Perilaku Pengguna Software Berbasis Open Source di Perguruan Tinggi : Studi Kasus Software Akademik Sisfokampus

Resiko Perangkat Lunak. Project Management RISK ANALYSIS AND MANAGEMENT. Kategori Resiko (1) Kategori Resiko (2) Resiko Teknis (1)

TINJAUAN PUSTAKA. Pengujian adalah proses eksekusi program untuk menemukan kesalahan.

Jenis Metode Pengembangan Perangkat Lunak

ARTIKEL JURNAL SKRIPSI

Chapter 9 Software testing strategies

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

A. Pengembangan Software

5. Aktivitas generic dalam semua proses perangkat lunak antara lain adalah : a. Spesifikasi dan pengembangan b. Validasi dan evolusi c.

Gambar 3.1 Langkah-langkah penggunaan Metode Research and Development (R&D) menurut Sugiyono (2009:298)

Transkripsi:

SOFTWARE QUALITY ASSURANCE Software Quality Factors TKB5351 Penjaminan Mutu Perangkat Lunak Chalifa Chazar www.script.id chalifa.chazar@gmail.com

Fakta Orbiter Mars Crashes Kontraktor yg diberi tanggung jawab perencanaan sistem navigasi NASA memperoleh spesifikasi pembuat software. Tapi bukannya menggunakan sistem metrik, sang kontraktor malah melakukan pengukuran menggunakan satuan imperial. Akibatnya, pesawat ruang angkasa menabrak Mars & menelan kerugian lebih dari US$125 juta. Ariane 5 Flight 501 Mesin satelit ini jauh lebih cepat daripada model-model sebelumnya tetapi memiliki bug perangkat lunak yg tidak terasa sebelumnya. Satelit diluncurkan & setelah 36,7 detik mengudara, seketika rusak sendiri & berubah menjadi bola api yg megah. Biaya pembuatan satelit diperkirakan mencapai US$8 miliar dengan membawa muatan senilai US$500 juta dolar ketika hancur.

Fakta Black Monday Pada tahun 1987, sebuah investigasi menyebabkan pasar saham yg sedang naik tiba-tiba turun signifikan. Penyelidikan mempengaruhi pemegang saham untuk membuang saham mereka. Namun respon analisis komputer yg muncul, malah makin merusak sistem pasar modal. Akibatnya, nilai pasar jatuh dengan cepat & tidak ada pilihan selain untuk melikuidasi saham. EDS Fails Child Support System Kontraktor EDS menciptakan sistem teknologi informasi cukup kompleks yg dipesan CSA (Child Support Agency) / Badan Dukungan Anak di Inggris. Perangkat ini ternyata tidak kompatibel dengan restrukturisasi yg direncanakan, sehingga menyebabkan banyak kesalahan. Biaya kerugian diperkirakan sejak saat itu hingga sekarang mencapai US$1 miliar.

Semua proyek perangkat lunak memenuhi persyaratan dasar untuk perhitungan yang benar. Semua proyek perangkat lunak memiliki kinerja yang buruk pada area pemeliharaan (maintenance), kehandalan (reliability), penggunaan kembali perangkat lunak (software reuse), atau pelatihan (training). Buruknya kinerja proyek perangkat lunak yang dikembangkan adalah kurangnya persyaratan yang telah ditetapkan yang mencakup aspek-aspek penting dari fungsi perangkat lunak.

Kriteria Keberhasilan Software Berdasarkan konsep Manajemen Proyek, terdapat beberapa kriteria keberhasilan software : Pengerjaan proyek sesuai jadwal/tepat waktu. Biaya tidak melebihi pagu anggaran yang diperhitungkan. Sistem yang dihasilkan berjalan dengan baik dan sesuai dengan spesifikasi kebutuhan.

Dokumen spesifikasi kebutuhan (requirement document) merupakan satu elemen yang penting untuk mencapai kualitas perangkat lunak. Tantangan : Apa/bagaimana dokumen spesifikasi kebutuhan yang baik?

Kebutuhan Definisi Komprehensif terhadap kebutuhan/persyaratan Dibutuhkannya definisi kebutuhan yang komprehensif dari persyaratan yang akan mencakup semua atribut perangkat lunak dan aspek penggunaan perangkat lunak (termasuk aspek usability, reusability, maintainability, dan kepuasan pelanggan ). Atribut perangkat lunak, aspek pemeliharaan dan penggunaan dapat diklasifikasikan ke dalam konten yang disebut faktor kualitas. Klasifikasi persyaratan kualitas = menjadi faktor kualitas software

Faktor Kualitas Software Model classic faktor kualitas software, dikemukakan oleh McCall, terdiri dari 11 faktor (McCall, 1977). Model lainnya dikemukakan oleh Deutsch & Willis (1988) dan Evans & Marciniak (1987), merupakan pengembangan secara substansial dari model McCall.

Model McCall Model McCall mengklasifikasikan 11 faktor software. kualitas Kemudian, faktor tersebut dikelompokan menjadi 3 kategori : Product operation factors : Correctness, Reliability, Efficiency, Integrity, Usability Product revision factors : Maintainability, Flexibility, Testability Product transition factors : Portability, Reusability, Interoperability

Model McCall

Product Operation Factors Correctness Persyataran correctness didefinisikan kedalam daftar kebutuhan output perangkat lunak. Beberapa dimensi umum : Target output (keluaran) Akurasi hasil keluaran Kelengkapan output informasi Informasi terbaru (up-to-date) Ketersediaan informasi Standar dan pedoman yang dibutuhkan

Product Operation Factors (2) Reliability Reliability berhubungan dengan penyediaan layanan yang berurusan dengan kegagalan. Menentukan tingkat maksimum kegagalan yang diijinkan dari perangkat lunak. Efficiency Efficiency berhubungan dengan sumber daya perangkat keras (hardware) yang diperlukan untuk melakukan semua fungsi.

Product Operation Factors (3) Integrity Integrity berhubungan dengan sistem keamanan perangkat lunak. Pencegahan akses masuk pihak yang tidak berwenang. Usability Usability berhubungan dengan lingkup sumber daya yang dibutuhkan untuk mengoperasikan perangkat lunak dan prose pelatihan.

Product Revision Factors Maintainability Maintainability berhubungan dengan menentukan upaya yang dibutuhkan untuk mengidentifikasi alasan dari kegagalan perangkat lunak, alasan untuk perbaikan dan verifikasi keberhasilan (setelah perbaikan). Flexibility Kemampuan dan upaya untuk mendukung kegiatan pemeliharaan, seperti perubahan/penambahan perangkat lunak, untuk meningkatkan layanan dan beradaptasi dengan lingkungan teknis. Testability Berhubungan dengan pengujian informasi sistem berjalan sesuai operasionalnya.

Product Transition Factors Portability Kemampuan beradaptasi perangkat lunak terhadap lingkungan lainnya yang terdiri dari hardware yang berbeda, sistem operasi yang berbeda, dan lainnya. Reusability Berhubungan dengan penggunaan kembali modul-modul perangkat lunak untuk penggunaan masa depan. Interoperability Berhubungan dengan fokus untuk menciptakan antarmuka dengan perangkat lunak lain seperti firmware.

Alternative Model The Evans and Marciniak factor model (Evans and Marciniak, 1987). The Deutsch and Willis factormodel (Deutsch and Willis, 1988). Perbandinganmodel-model tersebut: Kedua model alternatif tersebut mengabaikan salah satu faktor Model McCall yaitu faktor testability. Model Evans dan Marciniak terdiri dari 12 faktor yang dikategorikan menjadi 3 kategori Model Deutsch and Willis terdiri dari 15 faktor yang dikategorikan menjadi 4 kategori

Alternative Model Terdapat 5 faktor baru yang ditambahkan oleh kedua model alternatif, yaitu: Verifiability (by both models) Expandability (by both models) Safety (by Deutsch and Willis) Manageability (by Deutsch and Willis) Survivability (by Deutsch and Willis).

Perbandingan Model

Dari hasil perbandingan 2 faktor tambahan yaitu expandability dan survivability, sebenarnya memiliki kemiripan dengan model McCall yaitu faktor flexibility and reliability. faktor testability pada model McCall, juga dapat dikategorikan sebagai faktor maintainability. Sehingga dapat dikatakan bahwa faktor yang baru hanya 3 faktor, yaitu safety, manageability dan survivability. Namun, jika kategori tersebut dijabarkan, maka terlihat adanya perbedaan antara model-model tersebut.

Pebandingan Model

Dokument Spesifikasi Persyaratan Suatu proyek dapat berjalan berdasarkan 2 dokumen spesifikasi persyaratan/kebutuhan, yaitu: Dokument persyaratan client Dokument pernyaratan tambahan oleh pengembang (developer)

</TERIMA KASIH> Chalifa Chazar, S.T, M.T Email: chalifa.chazar@gmail.com script.id Copyright @2016