Quality Management Standards

Berikut adalah ruang lingkup yang ada pada quality management standards

-----Ruang lingkup standar penilaian juga ditentukan oleh tujuan penilaian, yang merupakan  untuk :

• Melayani pengembangan perangkat lunak dan pemeliharaan organisasi sebagai alat untuk penilaian mandiri kemampuan mereka untuk melaksanakan proyek-proyek pengembangan perangkat lunak.
• Berfungsi sebagai alat untuk perbaikan proses pembangunan dan pemeliharaan. Standar ini menunjukkan arah untuk perbaikan proses.
• Membantu organisasi pembelian menentukan kemampuan pemasok potensial.
• Panduan pelatihan asesor dengan menggambarkan kualifikasi dan kurikulum pelatihan program.

Prinsip yang diterapkan dalam ISO 9000-3, yaitu :

-----Fokus pada pelanggan

• Leadership : terkait dengan visi organisasi
• Melibatkan orang

-----Efisiensi dalam kegiatan dan sumber daya

• Pendekatan sistem pada manajemen : mengidentifikasi, memahami dan mengelola proses sebagai suatu sistem.

-----Melakukan perbaikan secara terus menerus

• Pendekatan faktual untuk pengambilan keputusan : pengambilan keputusan yang efektif.
• Saling mendukung hubungan pemasok : saling ketergantungan antara organisasi dan pemasoknya.

Keuntungan 

Keuntungan menggunakan Quality Management Standards yang sudah ada, yaitu :

• Kemampuan untuk menerapkan pengembangan perangkat lunak dan metodologi maintenance dan prosedur dari tingkat profesional tertinggi.
• Memiliki pemahaman yang sama dan koordinasi antara tim pengembang terutama antara tim pengembang dan tim maintenance.
• Adanya kerjasama yang baik antara pengembang perangkat lunak dan peserta eksternal dalam proyek.
• Pemahaman yang lebih baik dan kerja sama antara pemasok dan pelanggan, berdasarkan penerapan pengembangan dab standar maintenance sebagai bagian dari kontrak

Standar SQA dapat dibagi menjadi 2 bagian yaitu

1. Quality Management Standard

• Berfokus pada organisasi sistem SQA, infrastruktur dan persyaratan. Contohnya ISO 9000-3,  Capability Maturity Model (CMM)

2. Process Standard

• Berfokus pada metodologi untuk melakukan pengembangan perangkat lunak dan proyek maintenance.

Ada beberapa standart dalam SQA developer yaitu 

• IEEE (Institute of Electrical and Electronics Engineers) Computer Society
• ISO (International Organization for Standardization)
• DOD (US Department of Defense)
• ANSI (American National Standards Institute)
• IEC (International Electrotechnical Commission)
• EIA (Electronic Industries Association).

Cost of Software Quality

Kontrol manajerial atas biaya kualitas software dicapai dengan perbandingan angka kinerja aktual dengan :

• Mengontrol pegeluaran yang dianggarkan.
• Kegagalan biaya pada tahun sebelumnya.
• Biaya kualitas pada proyek sebelumnya.
• Biaya kualitas dari departemen lainnya.

Biaya kualitas perangkat lunak menyangkut semua biaya yang diadakan untuk mendapatkan kualitas guna menampilkan kualitas yang baik dari perangkat lunak yang dikembangkan. Berikut ini adalah tujuan dari cost of software quality :

• Sebagai evaluasi rencana untuk menambah atau mengurangi SQA atau untuk berinvestasi dalam infrastruktur SQA berdasarkan kinerja ekonomi terakhir.
• Sebagai kontrol organisasi yang dimulai untuk mencegah dan mendeteksi kesalahan perangkat lunak.
• Sebagai evaluasi kerusakan ekonomi dari kegagalan perangkat lunak sebagai dasar untuk merevisi anggaran SQA.

Classic Model

• Model ini mengklasifikasikan biaya yang berkaitan dengan kualitas produk menjadi dua kelas umum, yaitu :

Costs of control

• Biaya yang dikeluarkan untuk mencegah dan mendeteksi kegagalan dari perangkat lunak guna untuk mengurangi error ditingkat yang diterima.

Costs of failure of control

• Biaya kegagalan yang terjadi karena kegagalan dalam pencegahan dan mendeteksi kesalahan perangkat lunak.

Dari kedua kelas tersebut dibagi lagi menjadi dua, yaitu :

Costs of control

-----Prevention costs (Biaya pencegahan)

• Biaya ini termasuk investasi dalam infrastruktur mutu dan kualitas kegiatan yang tidak diarahkan untuk proyek atau sistem tertentu, yang umum bagi organisasi.

-----Appraisal costs (Biaya kajian)

• Biaya ini termasuk dalam kegiatan yang dilakukan untuk proyek atau sistem tertentu dari perangkat lunak dengan tujuan mendeteksi kesalahan dari perangkat lunak.

Costs of failure of control

-----Internal failure costs

• Biaya ini termasuk biaya untuk mengoreksi kesalahan yang telah terdeteksi oleh design review, pengujian perangkat lunak dan pengujian penerimaan (acceptance test) dan selesai sebelum perangkat lunak diinstal di lokasi pelanggan.

-----External failure costs

• Biaya ini termasuk biaya mengoreksi kegagalan yang terdeteksi oleh pelanggan atau tim maintenance setelah sistem perangkat lunak diinstall

Extended Model

Model ini adalah perluasan dari classic model, yang di dalamnya ditambahkan subclass, yaitu :

-----Managerial Preparation and Control Costs

• Biaya ini berhubungan dengan kegiatan yang dilakukan untuk mencegah atau mengurangi prospek kegagalan manajerial. Persiapannya meliputi hal-hal berikut :

1. Biaya melakukan contract review.
2. Biaya mempersiapkan project plan, termasuk quality plan.
3. Biaya periodik untuk memperbaharui project plan dan quality plan.
4. Biaya untuk melakukan kontrol kemajuan reguler dari upaya pengembangan perangkat lunak internal.
5. Biaya untuk melakukan kontrol kemajuan reguler dari kontribusi peserta eksternal untuk proyek.

------Managerial Failure Costs

• Hal ini bisa terjadi secara merata sepanjang keseluruhan program pengembangan perangkat lunak dimulai dari tahap pra-proyek. Berikut ini merupakan biaya kegagalan manajerial yang biasa terjadi :

1. Tidak adanya perencanaan biaya untuk sumber daya profesional lainnya.
2. Kompensasi yang dibayarkan kepada pelanggan akibat keterlamabatan penyelesaian proyek, akibat dari jadwal yang tidak realistis dalam proposal perusahaan.

Project Progress Control

Project Progress Control memungkinkan manajemen untuk mengawasi setiap proyek baik pada saat memulai, perubahan dan perbaikan dalam bagaimana proyek dilakukan.

Masalah umum terhambatnya proyek dikarenakan melebihi anggaran dan kekurangan anggaran , hal ini harus   selalu dikontrol , karena hal tersebut faktor utama terjadinya hambatan .

Penyebab masalah dalam projek :

• Terlalu optimis dalam melakukan penjadwalan dan penganggaran.
• Ketidakprofesionalan dalam menggunakan perangkat lunak manajemen resiko.
• 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

Komponen utama yang terdapat dalam progress control :

Pengendalian kegiatan Manajemen Risiko,

• Mengurangi resiko dengan menerapkan system manajemen resiko yang sistematis. Yaitu mengontrol dengan mereview laporan berkala dan mengevaluasi kemajuan informasi, yang mana memberikan pencapaian tujuan proyek secara fungsional dan teknis

Proyek jadwal kontrol, 

• berkaitan dengan proyek sesuai dengan jadwal yang disetujui dan dikontrak

Proyek kontrol sumber daya, 

• berfokus pada manusia yang profesional sumber daya komposisi, internal atau alokasi

Anggaran Proyek Pengendalian,

• Berdasarkan perbandingan biaya aktual dengan yang dijadwalkan, anggaran utama yang harus dikendalikan adalah:

1. Sumber daya manusia
2. Fasilitas pengembangan dan pengujian
3. Pembelian COTS perangkat lunak
4. Pembelian perangkat keras
5. Pembayaran subkontraktor

Staff Training and Certification

Tujuan dan proses staff training and certification yaitu , 

Tujuan staff training and certification

• Untuk memperbarui pengetahuan dan keterampilan staf veteran dalam menanggapi perkembangan organisasi, dan untuk menjamin kinerja yang efisien dan efektif dari tugas serta kesesuaian dengan gaya organisasi dan struktur prosedur dan instruksi kerja.
• Untuk mengembangkan pengetahuan dan keterampilan staf baru untuk tugas pembangunan suatu software  dan pemeliharaan di tingkat efisiensi dan efektifitas.
• Untuk memastikan bahwa calon untuk pengembangan perangkat lunak kunci dan posisi pemeliharaan cukup berkualitas.
• Untuk menjamin kesesuaian dengan standard organisasi untuk produk software (dokumen dan kode) dengan metransmisi style dan struktur prosedur bersamaan dengan instruksi kerja
• Untuk mengirimkan pengetahuan tentang prosedur SQA.

Proses staff training and certification

• Menentukan professional knowledge requirements untuk setiap posisi
• Menentukan professional training dan meng-update kebutuhan
• Merencanakan program professional training
• Merencanakan program professional updating
• Menentukan posisi yang memerlukan sertifikasi
• Merencanakan proses sertifikasi
• Memberikan program training, updating, dan sertifikasi
• Melakukan tindak lanjut dari staf yang terlatih dan bersertifikat
• Menentukan professional knowledge requirements

Profesi 

• systems analyst
• Programmer
• software development team leader
• programming team leader
• software maintenance technician
• software tester
• software testing team leader

Pengetahuan yang dibutuhkan antara lain :

• software development tools ,programming language versions , knowledge of SQA topics, etc.
• Tentukan pelatihan profesional dan memperbarui kebutuhan
• ----Tiga jenis pelatihan :

1. Training, ditujukan bagi karyawan baru
2. Re-training, ditujukan bagi karyawan yang ditugaskan untuk posisi baru atau menerima tugas baru
3. Updating, ditujukan bagi anggota staff lama yang butuh pelatihan baru sesuai dengan apa yang jadi kebutuhan pada posisinya

Merencanakan proses sertifikasi 

Tujuan sertifikasi, adalah :

• Menyediakan framework untuk penyelidikan menyeluruh dari kandidat kualifikasi
• Mendemontrasikan kandidat yang berpengetahuan dan berkeahlian profesional

Kebutuhan sertifikasi

• Edukasi profesianal : akademik atau technical degrees
• Kursus pelatihan internal
• Profesional yang berpengalam dalam organisasi
• Evaluasi oleh kandidat atasan
• Demonstrasi pengetahuan dan keahlian dengan cara test atau proyek

Documentation Control

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.

Controlled documents

Sebuah dokumen yang saat ini penting atau mungkin menjadi penting untuk pengembangan dan pemeliharaan sistem perangkat lunak serta pengelolaan hubungansekarang dan masa depan dengan pelanggan.tujuan utama dari Controlled documents adalah :

Tujuan dari dokumentasi kontrol 

• 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

Dokumen pelanggan yang mungkin diperlukan untuk menunjukkan kepatuhan dengan customer requirements dan operasi yang efektif dari seluruh proses pembangunan dan pemeliharaan sistem software quality assurance.

Typical controlled documents (including quality records)

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 :

Typical components of documentation control procedures

The controlled documents list

Konstruksi 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 dokumen terkendali dan yang jenis dokumen terkontrol harus diklasifikasikan sebagai kualitas rekaman.
• Menentukan apakah tingkat kontrol yang memadai untuk setiap jenis dokumen dikategorikan sebagai dokumen terkendali.
• Menindaklanjuti kepatuhan dengan daftar jenis dokumen terkendali. Subjek ini dapat dimasukkan dalam rencana audit mutu internal.
• Menganalisis tindak lanjut temuan dan memulai pembaruan yang diperlukan, perubahan, kepindahan dan penambahan pada daftar jenis dokumen terkendali. Jenis dokumen yang paling dikendalikan adalah dokumen yang dibuat secara internal oleh organisasi itu sendiri. Meskipun demikian, sejumlah besar dokumen jenis eksternal, seperti dokumen kontrak dan risalah rapat komite bersama, juga termasuk dalam kategori ini.

Supporting Quality Devices

Untuk mendapatkan software yang berkualitas dan efisien , disini terdapat beberapa tools dalam penjaminan kualitas software yang dimana dapat mempermudah dalam mendokumentasian perangkat lunak , terdapat 2 tools yang umum digunakan dalam penjaminan kualitas software yaitu 

• Template
• Checklist

Template 

Template adalah sebuah format dokumen yang berbentuk seperti daftar isi yang dibuat oleh organisasi atau unit agar dapat diterapkan ketikan akan melakukan komplisasi laporan atau beberapa jenis dokumen lainnya.

Kontribusi dan tantangan template dalam menjamin kualitas software 

Template ini dapat dlihat kegunaannya dari 2 sudut pandang yaitu dari sudut pandang tim pengembang dan tim review.

Dalam tim pengembang template berguna untuk,

• Memfasilitasi dalam proses penyusunan dan penyimpanan dokumen.
• Dokumen yang disiapkan lebih lengkap
• Menyediakan kemudahan  integrasi pada tim yang baru 
• Memudahkan dalam tahap review karena sudah ada standart pada masing-masing struktur.

Dalam tim review template berguna untuk,

• Memudahkan mendapatkan informasi yang dibutuhkan untuk melakukan maintenance pada software atau perangkat lunak.

Tantangan dalam menggunakan template, dapat dilihat dari sisi keuntungan dan kerugian yang ada.

Keuntungan 

• Suatu organisasi dapat cenderung menghemat sumber daya internal mereka 

Kerugian 

• Perbaikan template harus dilakukan oleh tim profesioanal 
• Tidak semua tim dalam suatu organisasi mengetahui keberadaan template.

Peran unit SQA dalam suatu organisasi

Unit SQA biasanya bertanggung jawab untuk mempersiapkan template yang profesional dari jenis laporan yang lebih umum dan dokumen yang diperlukan staf organisasi

Dalam template pengorganisasian, unit SQA melakukan :

• Mempersiapkan template baru
• Implementasi template baru atau meng-update
• Memperbaharui template

Checklist 

Checlist merupakan daftar item yang khusus dibuat untuk semua jenis dokumen atau list-list kegiatan yang dapat mengukur dan memeriksa ke komplitan dari sebuah aktivitas, tujuan dari checklist ini adalah menyediakan daftar item agar dapat di verifikasi 

Kontribusi dan tantangan Checklist dalam menjamin kualitas software 

Chehklist ini dapat dlihat kegunaannya dari 2 sudut pandang yaitu dari sudut pandang tim pengembang dan tim review.

Dalam tim pengembang template berguna untuk

• Membantu developers dalam persiapan mereka untuk tugas-tugas (misalnya instalasi perangkat lunak di situs pelanggan)
• Membantu developers melakukan pemeriksaan sendiri pemeriksaan dokumen atau kode perangkat lunak sebelum penyelesaian dan menemukan bagian yang tidak lengkap

Dalam tim review checklist berguna untuk, 

• Membantu mengefisienkan waktu dalam melakukan aktifitas review pada sebuah perangkat lunak 
• Dapat menjamin kelengkapan dokumen review yang dilakukan tim review

Peran unit SQA dalam suatu organisasi

Dalam suatu organisasi, persiapan dan pembaharuian checklist seperti promosi penggunaanya biasanya ditugaskan pada unit SQA, unit SQA dilakukan :

• Persiapan checklist baru
• Promosi penggunaan checklist
• Meng-updatechecklist

Software Configuration Management  (SCM)

Pengertian

Serangkaian aktifitas penelusuran dan pengendalian yang dimulai ketika proyek dimulai sampai software tidak dioperasikan lagi atau tools manajemen konfigurasi yang dipakai untuk menyimpan versi komponen sistem, membangun sistem dari komponen, dan memantau rilis versi sistem ke pelanggan beserta hasil laporannya.

Tujuan SCM

• Mengidentifikasi perubahan
• Mengontrol perubahan
• Memastikan perubahan yang telah diimplementasikan

Output yang dihasilkan dari manajemen konfigurasi 

• Program komputer untuk sumber dan dieksekusi
• Dokumen untuk praktisi teknis dan pemakai
• Data yang diisi kedalam program dan keluaran dari program

 Yang mendasari berubahan dalam manajemen konfigurasi adalah 

• Kondisi pasar
• Tuntutan pelangan
• Reorganisasi/perubahan struktur tim pengembang
• Redefenisi sistem atau produk

Configuration Management (CM)

Versi baru perangkat lunak dibuat karena ada perubahan:

• Sistem operasi yang berbeda pada mesin;
• Adanya perubahan pada kemampuan (menawarkan kemampuan yang berbeda

Kaitan-kaitan CM untuk memanajemen  pengembangan perangkat lunak meliputi: 

• Penggantian sistem pada sebuah aktifitas tim yang bertujuan untuk mengontrol biaya dan melibatkan membuat perubahan pada sistem.
• Melibatkan standar dan prosedur pengembangan aplikasi untuk memenej pengembangan perangkat lunak.
• Merupakan bagian dari proses manajemen kualitas.
• Hubungan CM, sistem perangkat lunak disebut juga baselines sebagai titik awal untuk mengembangkan lebih lanjut.
• Merupakan sebuah konsep manajemen konfigurasi perangkat lunak untuk mengontrol perubahan selama perubahan masih dapat dibenarkan

Standarisasi  CM 

• CM selalu berdasarkan kepada standar yang diaplikasikan didalam sebuah organisasi.
• Standar didefenisikan bagaimana item-item diidentifikasikan, bagaimana perubahan dikendalikan dan bagaimana memenej versi yang baru.
• Standar external yang mungkin mempengaruhi seperti: standar IEEE.
• Beberapa standar menerapkan proses pengembangan seperti model air terjun (waterfall), standar CM yang baru membutuhkan pengembangan yang evolusioner.

Software Implementation dan Testing

Hasil Rancangan detil yang ditranslasikan ke dalam suatu bahasa pemrograman, proses translasi dilanjutkan bila suatu kompiler menerima source code sebagai masukan dan mengkasilkan object code yang akan diterjemahkan menjadi machine code.

Software testing  adalah aktivitas-aktivitas yang bertujuan untuk mengevaluasi atribut-atribut atau kemampuan sebuah program atau sistem dan penentuan apakah sesuai dengan hasil yang diharapkan

Testing adalah proses pemeriksaan program dengan tujuan tertentu dalam menemukan kesalahan sebelum diserahkan ke pengguna.Software testing adalah bertujuan menjalankan dan mengevaluasi sebuah perangkat lunak secara manual maupun otomatis untuk menguji apakah perangkat lunak sudah memenuhi  persyaratan atau belum  untuk menentukan perbedaan  antara hasil yang diharapkan dengan hasil sebenarnya

•       Verification:

–      “Apakah kita membangun produk dengan benar?”

–      Software seharusnya sesuai dengan spesifikasinya. Gunakan proses software yang bagus.

•       Validation:

–      “Apakah kita membangun produk yang benar?”

–      Software seharusnya melakukan apa yang pengguna benar-benar butuhkan

Program testing

             Dapat menunjukan keberadaan kesalahan tapi BUKAN ketidakadaan kesalahan yang lain

Test yang sukses adalah sebuah test yang menemukan satu atau lebih kesalahan, Seharusnya digunakan bersama dengan verification statik untuk memberikan V&V sepenuhnya

Tujuan dari dilakukan testing pada software

• Menilai apakah perangkat lunak yang dikembangkan telah memenuhi kebutuhan pemakai.
• Menilai apakah tahap pengembangan perangkat lunak telah sesuai  dengan metodologi yang digunakan.
• Membuat dokumentasi hasil pengujian yang menginformasikan kesesuaian perangkat lunak yang diuji dengan spesifikasi  yang telah ditentukan
• Untuk meningkatkan kualitas
• Untuk Verification & Validation (V&V) 
• Untuk estimasi reliability

Strategi yang digunakan

1. Pengujian unit  program

         Pengujian difokuskan pada unit terkecil dari suatu modul program. Dilaksanakan dengan menggunakan driver dan stub. Driver adalah suatu program utama  yang berfungsi mengirim  atau menerima data  kasus uji dan mencetak hasil dari modul yang diuji. Stub adalah modul yang menggantikan  modul sub-ordinat dari modul yang diuji


          2.Pengujian integrasi

        Pengujian terhadap unit-unit program  yang saling berhubungan (terintegrasi) dengan fokus  pada masalah interfacing. Dapat dilaksanakan secara top-down integration atau bottom-up integration

         3.Pengujian validasi

        Pengujian ini dimulai jika pada tahap integrasi tidak ditemukan kesalahan. Suatu validasi dikatakan sukses  jika perangkat lunak berfungsi pada suatu cara yang diharapkan oleh pemakai


        4.Pengujian sistem

Pengujian yang dilakukan sepenuhnya pada sistem berbasis komputer.

–        Recovery testing

Pengujian dilakukan dimana sistem diusahakan untuk gagal, kemudian diuji normalisasinya.

–        Security testing

Dilakukan untuk menguji mekanisme proteksi

–        Stess testing     

Pengujian yang dirancang untuk menghadapkan suatu perangkat lunak kepada situasi Yang tidak normal.

Teknik Pengujian

Ada banyak teknik pengujian yang dapat digunakan untuk menguji perangkat lunak,seperti :

1. Pengujian Black Box
2. Pengujian White Box

Pengujian dengan black Box
                   Digunakan untuk menguji fungsi-fungsi khusus dari perangkat lunak yang dirancang
Kebenaran perangkat lunak yang diuji hanya dilihat berdasarkan keluaran yang dihasilkan dari data atau kondisi masukan yang diberikan untuk fungsi yang ada tanpa melihat bagaimana proses untuk mendapatkan keluaran tersebut.

                             Dari keluaran yang dihasilkan, kemampuan program dalam memenuhi kebutuhan pemakai dapat diukur sekaligus dapat diiketahui kesalahan-kesalahannya

Beberapa jenis kesalahan yang dapat diidentifikasi :

• Fungsi tidak benar atau hilang
• Kesalahan antar muka
• Kesalahan pada struktur data (pengaksesan basis data)
• Kesalahan inisialisasi dan akhir program
• Kesalahan performasi.

Pengujian white box
                 digunakan untuk mengetahui cara kerja suatu perangkat lunak secara internal.
Pengujian dilakukan untuk menjamin operasi-operasi internal sesuai dengan spesifikasi yang telah ditetapkan dengan menggunakan struktur kendali dari prosedur yang dirancang

     
       Pelaksanaan pengujian white box :

•  Menjamim seluruh independent path dieksekusi paling sedikit satu kali. Independent path adalah jalur dalam program yang menunjukkan paling sedikit satu kumpulan proses ataupun kondisi baru
• Menjalani logical decision pada sisi dan false
•  Mengeksekusi pengulangan (looping) dalam batas-batas yang ditentukan
• Menguji struktur data internal 

Software  Quality faktor

Faktor-faktor yang dapat mempengaruhi kualitas software dibagi menjadi 2kategori:

            1.Faktor-faktor yang dapat diukur secara langsung(misalkan:error)
            2.Faktor  yang dapat diukur secara tidak langsung (misalkan: usability dan maintainability)

Menurut McCall terdapat 3 aspek penting dari suatu produk software ,yaitu: karakteristik operasional,kemampuan perubahan ketika software sudah berjalan,dan kemampuan beradaptasi terhadap lingkungan baru.

Ada beberapa macam faktor yang mempengaruhi kualitas software menurut McCall yaitu ,

• Correctness (kebenaran)
•  Reliability (Keandalan)
•  Efficiency (efisiensi)
•  Integrity (Integritas)
•  Usability
•  Maintainability
•  Flexibility
•  Testability
• Portability
•  Reusability
•  Interoperability

Software Quality Assurance 

Tujuan  (SQA) adalah untuk menghasilkan suatu produk perangkat lunak (software) yang berkualitas tinggi. SQA merupakan salah satu aktivitas yang harus dijalani dalam suatu proses pengembangan software.

SQA meliputi beberapa konsep sebagai berikut:

1. Pendekatan kualitas manajemen,

2. Teknologi rekayasa perangkat lunak yang efektif (metode dan tools yang digunakan),

3. Tinjauan teknis secara formal yang diaplikasikan melalui proses pengembangan software,

4. Strategi uji coba software yang multitier,

5. Kontrol terhadap dokumentasi software dan perubahannya,

6. Prosedur untuk memastikan pemenuhan standar pengembangan software, jika software tersebut diaplikasikan, dan

7. Mekanisme pengukuran dan laporan.

Faktor Kualitas

• Correctness : besarnya program dapat memuaskan spesifikasi & objektivitas dari misi pelanggan
• Reliability : besarnya program dapat diharapkan memenuhi fungsi2 yg dikehendaki
• Efficiency : jumlah sumber2 & kode yg dibutuhkan program utk menjalankan fungsi2
• Integrity : besarnya pengontrolan pengaksesan oleh seseorang yg tidak mempunyai otorisasi terhadap perangkat lunak atau data
• Usability : effort (usaha) yg dibutuhkan utk mempelajari, mengoperasikan, menyiapkan input & mengintepretasi kan output program
• Maintainability : usaha yg dibutuhkan utk menempatkan & menetapkan suatu kesalahan pada program
• Flexibility : usaha yg dibutuhkan utk memodifikasi program yg dioperasikan
• Testability : usaha yg dibutuhkan utk menguji program utk menjamin tlh dijalankannya program yg diharapkan
• Portability : usaha yg dibutuhkan utk mentransfer program dari lingkungan sistem perangkat lunak dan perangkat keras ke lingkungan lain
• Reusability : besarnya program dpt digunakan oleh aplikasi lain
• Interoperability : usaha yg dibutuhkan utk memasang-kan satu sistem dgn yg lain

Pengukuran Kualitas Perangkat Lunak

• Auditability : mudah utk dicek mengenai konfirmansi standar
• Accuracy : presisi komputasi & pengontrolan
• Communication commonality : derajat pengunaan interface, protokol & bandwidth yg standar
• Completeness : derajat pencapaian implementasi full dari fungsi2 yg dibutuhkan
• Conciseness : kepadatan program dalam lines of code
• Consistency : penggunaan teknik dokumentasi & perancangan yg seragam
• Data commonality : penggunaan struktur & tipe data standar
• Error tolerance : akibat yg timbul pada saat program menemui kesalahan
• Execution efficiency : kinerja waktu eksekusi pada program
• Expandability : derajat dimana perancangan terprosedur, data & arsitektur dapat diperluas
• Generality : kelonggaran aplikasi dari komponen program
• Hardware independence : derajat dimana per. Lunak dipisahkan dari per. keras atau yg mengoperasikannya
• Instrumentation : derajat dimana program memonitor operasinya sendiri & mengindentifikasikan kesalahan2 yg timbul
• Modularity : kemandirian fungsional dari komponen program
• Operability : kemudahan pengoperasian program
• Security : ketersediaan mekanisme yg mengontrol atau memproteksi program & data
• Self-documentation : derajat dimana source code menyediakan dokumentasi yg berarti
• Simplicity : derajat dimana program dapat dimengerti dengan mudah
• Software system independence : derajat dimana program berdiri sendiri dari fitur bhs pemrograman, karakteristik sistem pengoperasian & batasan lainnya yg tdk standar
• Traceability : kemampuan utk menelusuri representasi perancangan atau komponen program aktual, kembali ke kebutuhan
• Training : derajat dimana per. lunak dapat membantu pengguna yg baru dalam mengaplikasikan sistem

Software Quality Metrics

Task 2.2: Analisa TA dengan Software Quality Factor

[gigya src="http://prezi.com/bin/preziloader.swf" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="550" height="400" bgcolor="#ffffff" flashvars="prezi_id=ockcqc4cnmbl&lock_to_path=0&color=ffffff&autoplay=no&autohide_ctrls=0"]

Task 2.1: The 9 Causes of Software Errors: Coding Errors

Ada dua cara untuk menyediakan perangkat lunak bebas dari kesalahan. Yang pertama adalah untuk mencegah masuknya kesalahan di tempat pertama. Dan yang kedua adalah untuk mengidentifikasi bug mengintai dalam kode Anda, mencari mereka, dan menghancurkan mereka. Jelas, metode pertama lebih unggul. Sebagian besar dari kualitas perangkat lunak berasal dari melakukan pekerjaan yang baik untuk mendefinisikan persyaratan untuk sistem Anda sedang membangun dan merancang solusi perangkat lunak yang akan memenuhi kebutuhan tersebut. Pengujian berkonsentrasi pada mendeteksi kesalahan-kesalahan yang menyelinap masuk meskipun upaya terbaik Anda untuk menjaga mereka.

Tapi apa sebenarnya yang menyebabkan sehingga dapat terjadi error pada software?

Menurut Buku Galin, ada sembilan penyembab terjadinya error pada software. Salah satunya akan kami bahas disini, yaitu kesalahan yang disebabkan oleh “Coding Error” atau kesalahan dalam pengkodean/ngoding.

Coding error dapat terjadi bila :

1. Terjadi salah paham dengan dokumen desain.
Dalam mengerjakan sofware, para programmer pastinya telah melakukan tahap-tahapan seperti menggali kebutuhan klien dan membuat desain softwarenya sebelum langsung melakukan koding. Dalam dokumen desain sudah ada seperti diagram-diagram yang akan menjadi tuntunan kita dalam mengkonversikan kebutuhan tadi kedalam koding. Biasanya salah memahami apa yang dimaksud dalam dokumen desain akan menimbulkan kesalahan dalam software, yang terjadi awalnya error dalam melakukan logika kode, lalu menjadi sebuah kesalahan software yang mengakibatkan salahnya fungsi yang diinginkan, dan akhirnya jika fungsinya sudah salah maka software tersebut dikatakan gagal.

2. Kesalahan bahasa dalam bahasa pemogramman
 Setiap bahasa pemogramman memiliki strukturnya sendiri dan juga cara penulisannya pun berbeda untuk tiap bahasa pemogramman. biasanya terjadi error, jika kita belum sepenuhnya mengerti tata cara penulisan bahasa pemogramman tertentu. seperti misalnya dalam java, setiap kita mengakhiri suatu koding, akan diakhiri dengan tanda semicolon (;), jika kita lupa memakai tanda semicolon maka akan terjadi error.

3. Kesalahan dalam memilih data

Database juga dapat menjadi salah satu penyebab error dalam mengkode, misalnya kita ingin membuat database pelanggan, dalam tabel pelanggan ada atribut nama dan tanggal lahir. jika dalam atribut nama kita menggunakan data tipe yang kurang tepat seperti misalnya integer, tentu saja kita tidak dapat menuliskan huruf didalam database tersebut.

Cara mengatasi error:

·     Pastikan bahwa kode berikut standar yang ditetapkan gaya, struktur, dan dokumentasi. Meskipun bahasa seperti C membiarkan Anda menjadi super-kompak dan karenanya super jelas dalam coding Anda, jangan lupa bahwa manusia (bahkan mungkin Anda) mungkin harus bekerja dengan kode itu lagi suatu hari. Kejelasan kode biasanya lebih disukai daripada keringkasan.

·   Pastikan bahwa kode sedang benar diuji dan terintegrasi, dan bahwa revisi yang dibuat di modul kode diidentifikasi dengan benar.

·   Lihat bahwa menulis kode mengikuti jadwal yang ditentukan. Mungkin tidak akan; pelanggan berhak mengetahui hal ini dan untuk mengetahui dampak pada waktu pengiriman.

·         Pastikan bahwa tinjauan kode ditahan sesuai jadwal.

Contoh Studi Kasus:

Pada tahun 2010, perusahaan automobile toyota menarik produknya Toyota Prius Hybrid dari pasar sebanyak 160.000 unit, ini terjadi karena lampu peringatan yang ada pada mobil tersebut menyala sendiri. dan juga mesin bensinnya terulur secara tidak terduga. awalnya mereka mengira bahwa itu adalah kesalahan hardware atau mesinnya. Akan tetapi ternya kesalahan tersebut disebabkan oleh Bug pada softwarenya, yang terjadi karena kesalahan programming pada kodenya.

Dan karena error tersebut sudah terjadi, maka dengan terpaksa langkah awal yang dilakukan adalah menarik produk-produknya yang telah beredar di pasar. Lalu memperbaiki bug yang ada.

Referensi :

1. The 9 Causes of Software Error, Galin

2. http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all

3. http://www.mactech.com/articles/mactech/Vol.06/06.11/SoftwareErrors/index.html

Oleh :

Putu Bagus Sugosha (5209100149)

Made Yudi Pradita (5209100018)

Task 1: The Software Quality Challenge