Komponen SQA pada Project Life Cycle

Disini saya hanya akan menunjukkan gambar untuk komponen SQA pada project life cycle. Untuk keterangan gambarnya sudah saya jelaskan pada blog ini juga pada bab sebelumnya.

SQA Standards

Tujuan :

1. Penggunaan pengetahuan profesional internasional

2.Perbaikan koordinasi dengan kualitas sistem organisasi lain

3.Evaluasi profesional dan pengukuran pencapaian kualitas sistem organisasi

• Standar manajemen kualitas : ISO 9001 & ISO 9000-3
• Sttandar proses proyek : IEEE 1012 & ISO / IEC 12207

Testing

Definisi testing perangkat lunak :

• Menurut Myers (1979)

Proses menjalankan program dengan maksud menemukan kesalahan

• Menurut IEEE (1990)

1. Proses sistem operasi atau komponen menurut kondisi tertentu, pengamatan atau pencatatan hasil dan mengevaluasi beberapa aspek sistem atau komponen
2. Proses analisis item PL untuk mendeteksi perbedaan antara kondisi yang ada dengan yang diinginkan dan mengevaluasi fitur item PL

Definisi lanjut

Proses formal yang ditentukan oleh tim testing yang meliputi unit PL, beberapa unit PL terintegrasi atau seluruh package PL yang ditentukan oleh program yang berjalan di komputer. Seluruh tes saling terkait dan adanya prosedur testing dan kasus testing.

Tujuan testing perangkat lunak :

• Tujuan langsung

1. Identifikasi dan menemukan beberapa kesalahan yang mungkin ada dalam PL yang diuji
2. Setelah PL dibetulkan, diidentifikasi lagi kesalahan dan dites ulang untuk menjamin kualitas level penerimaan
3. Membentuk tes yang efisien dan efektif dengan anggaran dan jadwal yang terbatas

• Tujuan tidak langsung

Mengumpulkan daftar kesalahan untuk digunakan dalam daftar pencegahan kesalahan (tindakan corrective dan preventive)

Strategi testing perangkat lunak :

• Big bang testing : menguji perangkat lunak keseluruhan, sekali untuk semua package yang ada
• Incremental testing : menguji perangkat lunak per bagian dalam modul (unit testing), dilanjutkan dengan menguji integrasi tiap modul (integration test), selanjutnya seluruh package diuji (system testing)

Incremental testing dibentuk dari dua dasar strategi :

1. Top-down

• Modul pertama yang diuji : modul utama (tertinggi)
• Modul terakhir yang diuji : modul pada level paling rendah
• Keuntungan : memperlihatkan keseluruhan fungsi program (semua modul lengkap)
• Kerugian : sulit menyiapkan potongan program dan menganalisis hasil tes

2. Bottom-up : kebalikan top-down

• Keuntungan : relatif mendorong performance
• Kerugian : menghambat program sebagai suatu keseluruhan modul

Pengelompokan berdasarkan konsep testing :

1. Black box (functionality) testing : mengidentifikasi kesalahan yang berhubungan dengan kesalahan fungsionalitas PL yang tampak dalam kesalahan output
2. White box (structural) testing / glass box testing : memeriksa kalkulasi internal path untuk mengidentifikasi kesalahan

Definisi menurut IEEE :

1. Black box testing : 

• Testing yang mengabaikan mekanisme internal sistem atau komponen dan fokus semata-mata pada output yang dihasilkan yang merespon input yang dipilih dan kondisi eksekusi
• Testing yang dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional tertentu

2. White box testing :

• Testing yang memegang perhitungan mekanisme internal sistem atau komponen
• White box testing memiliki empat kategori :

a) Data processing and calculations correctness test : melakukan pengecekan data processing untuk setiap kasus tes

Pendekatan yang digunakan :

• Path coverage : rencana tes yang mencakup semua kemungkinan path, di mana coverage diukur dengan berapa % path dicover
• Line coverage : rencana tes yang mencakup semua baris kode program, di mana coverage diukur dengan berapa % line dicover

Correctness test & path coverage

• Path yang berbeda dalam modul PL akan dibentuk oleh pilihan kondisional statementseperti IF-THEN-ELSE / DO WHILE / DO UNTIL.
• Untuk full line coverage, tiap line dieksekusi min 1 kali selama proses testing, contoh : Imperial Taxi Service (ITS) taximeter ada 24 test case

b) Software qualification test

c) Maintainability test

d) Reusability test

Cara Menghitung FP

Metode Function Point digunakan untuk memperkirakan ukuran proyek, yang dapat dilakukan sebagai berikut:

1. Tahap 1: Perhitungan crude function points (CFP)

Metode ini berkaitan dengan lima jenis berikut komponen sistem perangkat lunak:

• Jumlah input user - aplikasi masukan berbeda, tidak termasuk masukan untuk pertanyaan online.
• Jumlah output user - aplikasi keluaran yang berbeda seperti batch diproses laporan, daftar, faktur pelanggan dan pesan kesalahan (tidak termasuk secara online query).
• Jumlah permintaan pengguna online - aplikasi online yang berbeda, di mana output mungkin dalam bentuk cetakan atau tampilan layar.
• Jumlah file logis - file yang berhubungan dengan tipe yang berbeda dari data dan dapat dikelompokkan dalam database.
• Jumlah interface eksternal - dibaca komputer output atau input ditularkan melalui komunikasi data, CD, disket, dll.

Metode titik fungsi berlaku faktor bobot masing-masing komponen menurut kompleksitasnya. Tabel di bawah ini dapat membantu dalam Perhitungan CFP tersebut.

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

Relative Complexity Adjustment Factor (RCAF) merangkum kompleksitas karakteristik dari sistem perangkat lunak dengan nilai menugaskan (0 sampai 5) ke 14 mata pelajaran yang secara substansial mempengaruhi upaya pengembangan yang diperlukan. daftar ini mata pelajaran disajikan dalam bentuk perhitungan RCAF, seperti tabel di bawah ini. 

3. Tahap 3: Menghitung jumlah function points (FP)

Function Points untuk sistem perangkat lunak yang diberikan dihitung menurut dengan hasil tahap 1 dan 2, dengan menerapkan rumus berikut:

FP = CFP × (0,65 + 0,01 × RCAF)

Software Quality Infrastructure Components

Beberapa komponen kualitas perangkat lunak adalah jaminan yang bersifat umum, mereka yang umum untuk banyak proyek dan kegiatan pemeliharaan, untuk desain semua review, ke semua rutinitas pengujian. Komponen alam ini mewakili " infrastruktur jaminan kualitas perangkat lunak ". Seperti infrastruktur, mereka adalah alat utama yang digunakan untuk mencegah kesalahan perangkat lunak dan mempromosikan kualitas tingkat organisasi secara keseluruhan. Tanggung jawab bagi perkembangan mereka, update, pemeliharaan, dan distribusi biasanya diletakkan di tangan jaminan kualitas tim.

Apa saja komponen infrastruktur khas?

• Procedures and work instruction
• Quality support devices like templates and checklists
• Staff SQA training and certification activities
• Preventive and corrective actions
• Software configuration management
• Documentation and quality records control

Beberapa komponen infastruktur di atas, juga sudah saya upload di blog saya ini. Silahkan di cek :) semoga bermanfaat ! 

PROJECT PROGRESS CONTROL

Ada empat komponen utama dari project progress control. Manajemen diharapkan untuk campur tangan dan berkontribusi untuk menciptakan solusi dalam kasus yang ekstrim.

1. Control of risk management
mengacu pada tindakan yang diambil sehubungan dengan perangkat lunak item risiko yang diidentifikasi dalam tinjauan kontrak dan dokumen rencana proyek serta mengambil risiko item diidentifikasi kemudian, selama kemajuan proyek. Dalam prakteknya, tim pengembangan perangkat lunak mencoba untuk mengurangi risiko dengan menerapkan sistematis risiko kegiatan manajemen. Manajemen mengontrol upaya ini melalui review laporan periodik dan evaluasi informasi kemajuan. Komponen kontrol kemajuan langsung memberikan kontribusi untuk pencapaian fungsional proyek tujuan teknis dan.
2. Project schedule control sepakat dengan proyek yang disetujui dan jadwal kontrak. Follow-up yang berdasarkan tonggak selain periodik laporan, yang bersama-sama memungkinkan identifikasi keterlambatan penyelesaian direncanakan kegiatan. Penekanan khusus diberikan kepada pelanggan-tonggak dituntut, karena tercantum dalam kontrak. Manajemen cenderung berfokus pada kontrol mereka keterlambatan kritis yang mengancam untuk secara substansial mengganggu tanggal penyelesaian proyek.
3. Project resource control berfokus pada sumber daya manusia yang profesional, tetapi juga dengan fasilitas pengembangan perangkat lunak dan pengujian, biasanya diperlukan oleh real-time sistem perangkat lunak dan firmware. Latihan manajemen mengontrol berdasarkan laporan berkala dari sumber daya yang digunakan, yang harus dilihat dari segi yang sebenarnya proyek berlangsung.
4. Project budget control berdasarkan perbandingan biaya aktual dengan yang dijadwalkan. Item anggaran utama yang harus dikendalikan adalah:

• Sumber daya manusia
• Pengembangan dan pengujian fasilitas
• Pembelian Cots perangkat lunak
• Pembelian perangkat keras
• Pembayaran kepada subkontraktor

Kontrol anggaran memerlukan input ditularkan oleh tonggak serta laporan periodik. Laporan-laporan ini memuat identifikasi awal overruns anggaran yang mempengaruhi proyek profitabilitas. Ketidaktahuan dari komponen lain dari kontrol kemajuan diharapkan secara substansial mengurangi efektivitas pengendalian proyek kemajuan. Yang lain komponen kontrol proses diharapkan untuk mengidentifikasi situasi menyimpang lebih awal dari kontrol anggaran yang mampu melakukan.

Pelaksanaan project progress control membutuhkan:

1. Berikut untuk didefinisikan untuk setiap proyek:

• Unit Orang atau manajemen yang bertanggung jawab untuk kontrol kemajuan
• Frekuensi laporan kemajuan diperlukan dari manajemen berbagai proyek tingkat
• Situasi di mana pemimpin proyek wajib melaporkan segera untuk manajemen
• Situasi di mana tingkat rendah manajemen wajib melaporkan segera untuk manajemen tingkat atas.

2. Manajemen audit dari kemajuan proyek yang berhubungan dengan seberapa baik pelaporan oleh pemimpin dan manajer proyek lain, serta pengendalian manajemen proyek kegiatan, berfungsi.

Corrective and Preventive Actions

Corrective actions           :

Sebuah proses umpan balik secara teratur yang diterapkan, yang meliputi pengumpulan informasi pada ketidaksesuaian kualitas, identifikasi dan analisis sumber penyimpangan serta pengembangan dan asimilasi praktek perbaikan dan prosedur, bersama dengan pelaksanaan kontrol mereka dan pengukuran hasil mereka.

Preventive actions          :

Sebuah proses umpan balik secara teratur yang diterapkan yang meliputi pengumpulan informasi tentang masalah kualitas potensial, identifikasi dan analisis penyimpangan dari kualitas, pengembangan standar dan asimilasi praktek perbaikan dan prosedur, bersama dengan pelaksanaan kontrol mereka dan pengukuran hasil mereka.

 

Proses tindakan perbaikan dan pencegahan

Keberhasilan operasi dari proses CAPA meliputi kegiatan:

• Pengumpulan informasi
• Analisis informasi
• Pengembangan solusi dan perbaikan metode
• Penerapan metode yang sudah diperbaiki
• Follow-up

Berikut merupakan skema proses nya

Configuration Managament

Configuration management

View more presentations from inggrid_5209100069.

Documentation Control

Documentation Control

Dokumentasi dalam Kamus Besar Bahasa Indonesia didefinisikan sebagai sesuatu yang tertulis , tercetak atau terekam yang dapat dipakai sebagai bukti atau keterangan. Adapun definisi dokumentasi adalah pemberian atau pengumpulan bukti-bukti dan keterangan.

Sedangkan dokumen control adalah sebuah dokumen yang saat ini penting atau mungkin menjadi penting untuk pengembangan dan pemeliharaan sistem perangkat lunak serta untuk pengelolaan saat ini dan masa depan hubungan dengan pelanggan. Oleh karena itu, persiapan, penyimpanan, pengambilan dan pembuangan dikendalikan oleh prosedur dokumentasi.Tipe dokumen control :

1. Pre project document

·         Contract review report

·         Contract negotiation meeting minutes

·         Software development contract

·         Software maintenance contract

·         Software development subcontracting contract

·         Software development plan

2. Project life cycle documents

·         System requirements document

·         Software requirements document

·         Preliminary design document

·         Critical design document

·         Database description

·         Software test plan

·         Design review report

·         Follow-up records of design review action items

·         Software test procedure

·         Software test report

·         Software user manuals

·         Software maintenance manuals

·         Software installation plan

·         Version description document

·         Software change requests

·         Software change orders

·         Software maintenance requests

·         Maintenance services reports

·         Records of subcontractor evaluations

3. SQA infrastructure documents

·         SQA procedures

·         Template library

·         SQA forms library

·         CAB meeting minutes

4. Software quality management documents

·         Progress reports

·         Software metrics reports

5. SQA system audit documents

·         Management review report

·         Minutes of management review meeting

·         Internal quality audit report

·         External SQA certification audit report

6. Customer documents

·         Software project tender documents

·         Customer’s software change requests

Komponen prosedur dokumentasi control :

• The controlled documents list
• Controlled document preparation
• Controlled document approval issues
• Issues of controlled document storage and retrieval issues.

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.

Controlled document preparation

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

• Struktur
• Cara identifikasi
• Standar orientasi dan informasi referensi

Struktur dokumen bebas atau ditentukan oleh template. Sebuah metode identifikasi ini dirancang untuk memberikan setiap dokumen, versi dan revisi dengan identitas yang unik. Metode ini biasanya memerlukan notasi dari (a) sistem perangkat lunak atau nama produk atau nomor, (b) dokumen (type) kode dan (c) nomor versi dan revisi. Metode ini dapat bervariasi untuk berbeda jenis dokumen.

Orientasi dokumen dan informasi referensi mungkin diperlukan juga. Orientasi dan referensi informasi dukungan akses masa depan diperlukan dokumen dengan menyediakan informasi tentang isi dokumen dan kesesuaian dengan kebutuhan pengguna masa depan. Tergantung pada jenis dokumen, proporsi yang lebih besar atau lebih kecil dari informasi berikut item yang biasa dibutuhkan:

• Penulis dokumen
• Tanggal penyelesaian
• Orang yang menyetujui dokumen, termasuk posisi yang diselenggarakan
• Tanggal persetujuan
• Tanda tangan dari penulis dan orang-orang yang disetujui
• Deskripsi dari perubahan dalam rilis baru
• Daftar mantan versi dan revisi
• Sirkulasi daftar
• Kerahasiaan pembatasan

Requirement Traceability Matrix

Sebuah dokumen Requirement Traceability Matrix, biasanya dalam bentuk tabel, yang berkorelasi setiap dua dokumen dasar yang memerlukan banyak hubungan banyak untuk menentukan kelengkapan hubungan tersebut. Hal ini sering digunakan dengan tingkat persyaratan yang tinggi (ini sering terdiri dari persyaratan pemasaran) dan persyaratan rinci tentang produk perangkat lunak ke bagian pencocokan desain tingkat tinggi , perancangan detil, rencana uji , dan uji kasus .

Sebuah dokumen Requirement Traceability Matrix dapat digunakan untuk memeriksa serta melihat apakah persyaratan proyek saat ini telah terpenuhi, dan untuk membantu dalam penciptaan sebuah Request for Proposal , penyerahan berbagai  dokumen, dan rencana proyek.

Penggunaan umum adalah untuk mengambil identifier untuk setiap item dari satu dokumen dan menempatkan mereka di kolom kiri. Pengenal untuk dokumen lain ditempatkan di baris atas. Ketika sebuah item dalam kolom kiri yang berhubungan dengan item di bagian atas, tanda ditempatkan di sel berpotongan. Jumlah hubungan yang ditambahkan untuk setiap baris dan setiap kolom. Nilai ini menunjukkan pemetaan dari dua item. Nilai nol menunjukkan bahwa hubungan tidak ada. Harus ditentukan jika salah satu harus dilakukan. Nilai yang besar berarti bahwa hubungan yang terlalu kompleks dan harus disederhanakan.

Untuk memudahkan pembuatan dokumen Requirement Traceability Matrix, disarankan untuk menambahkan hubungan ke dokumen sumber untuk kedua penelusuran mundur dan mampu menelusuri ke depan. Dengan kata lain, ketika suatu item berubah dalam satu dokumen dasar, mudah untuk melihat apa yang perlu diubah di lain.

Diagram RTM dapat digunakan selama seluruh tahapan proyek untuk:

•        Melacak semua kebutuhan dan apakah sedang atau tidak mereka penuhi pada saat proses dan desain

•        Membantu dalam penciptaan RFP, Rencana Proyek, Dokumen Deliverable, dan Test Scripts

•        Membantu memastikan bahwa semua persyaratan sistem telah terpenuhi selama proses Verifikasi

Penggunaan RTM meningkatkan proses manajemen ruang lingkup. Hal ini juga membantu dengan kontrol proses dan kualitas manajemen. RTM juga dapat dianggap sebagai proses mendokumentasikan koneksi dan hubungan antara persyaratan awal dari proyek dan produk akhir atau jasa yang dihasilkan.

Dalam setiap langkah-langkah di atas, kebutuhan masing-masing harus unik dan jelas. Persyaratan kemudian bagian dari setiap komponen penting dari proyek tersebut. Referensi seluruh seluruh proses harus konsisten dan unik. Untuk memastikan bahwa hal ini terjadi, Matrix menelusuri kebutuhan masing-masing dan menciptakan hubungan antara masing-masing proses.

Contoh RTM :

Konten Software Quality Assurance

Software Quality Assurance (SQA) diaplikasikan secara menyeluruh pada proses pengembangan software. SQA meliputi : 

1. Analisis, perancangan, pengkodean, dan metode serta peralatan ujicoba.
2. Tinjauan ulang teknikal secara formal yang diaplikasikan pada setiap tahapan pengembangan software.
3. Strategi ujicoba dengan banyak tahapan (multitiered).
4. Pengawasan terhadap dokumentasi software dan perubahan yang dialaminya. 
5. Suatu prosedur untuk menjamin pemenuhan standar pengembangan software (jika ada).
6. Mekanisme pengukuran dan laporan . 

Setiap pengembang software pasti setuju jika dikatakan bahwa kualitas software merupakan salah satu tujuan yang penting. Banyak definisi mengenai kualitas software, tetapi disini kualitas software didefinisikan sebagai :

“penyesuaian kebutuhan fungsional dan performa yang ditetapkan secara eksplisit, standar pengembangan yang terdokumentasi secara eksplisit, dan karakteristik implisit yang diharapkan dari seluruh software yang dikembangkan secara professional.” 

Definisi diatas menjelaskan 3 hal penting, yaitu :

1. Kebutuhan software merupakan pondasi/dasar dari kualitas yang akan diukur. Sedikitnya penyesuaian terhadap kebutuhan, maka semakin tidak berkualitas.
2. Standar yang dispesifikasikan mendefinisikan sekumpulan kriteria pengembangan yang memandu pengembangan software. Jika kriteria tidak disertakan, maka dapat dipastikan hasil akhir akan berkualitas rendah. 
3. Terdapat kebutuhan implisit (implicit requirements) yang terkadang tidak disebutkan (misalkan, keinginan untuk kemampuan pemeliharaan yang mudah). Jika software menyesuaikan kepada kebutuhan eksplisit, tetapi tidak kepada kebutuhan implisit, maka kualitas software akan dipertanyakan. 

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, seperti terlihat pada gambar diatas. Berdasarkan gambar diatas, McCall menyediakan beberapa dekripsi yaitu :

1. Correctness (kebenaran), tingkat pemenuhan program terhadap kebutuhan yang dispesifikasikan dan memenuhi tujuan/misi pengguna. 
2. Reliability (Keandalan), tingkat kemampuan program yang diharapkan dapat menampilkan fungsi yang dimaksud dengan presisi yang ditetapkan. 
3. Efficiency (efisiensi), jumlah sumberdaya yang diproses dan kode yang diperlukan oleh program untuk melaksanakan fungsinya. 
4. Integrity (Integritas), tingkat kemampuan pengawasan akses terhadap data atau software oleh orang-orang tertentu. 
5. Usability, usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan masukan dan mengartikan keluaran program. 
6. Maintainability, usaha yang diperlukan untuk menetapkan dan memperbaiki kesalahan dalam program. 
7. Flexibility, usaha yang diperlukan untuk memodifikasi program operasional. 
8. Testability, usaha yang diperlukan untuk menguji program untuk memastikan bahwa program melaksanakan fungsi yang telah ditetapkan. 
9. Portability, usaha yang diperlukan untuk memindahkan program dari hardware/lingkungan sistem software tertentu ke yang lainnya.
10. Reusability, tingkat kemampuan program/bagian dari program yang dapat dipakai ulang dalam aplikasi lainnya, berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh program.
11. Interoperability, usaha yang diperlukan untuk menggabungkan satu sistem dengan sistem lainnya. 

Aktivitas-aktivitas SQA (SQA Activities) SQA terdiri dari berbagai jenis aktivitas yang terhubung dengan 7 aktivitas utama, yaitu :

1. Aplikasi metode-metode teknikal (Application of technical methods) Kualitas software didesain kedalam sebuah produk atau sistem. Pada kenyataannya SQA dimulai dengan sekumpulan metode teknikal dan tool yang membantu analis untuk mencapai spesifikasi dengan kualitas yang tinggi dan para perancang membangun desain yang berkualitas tinggi. 
2. Mengadakan review teknikal formal (conduct of formal technical reviews) Ketika spesifikasi (atau prototype) dan desain telah dibuat, maka masing-masing harus di perkirakan untuk kualitas. Aktivitas utama yang memenuhi penaksiran kualitas adalah formal technical review (FTR). FTR merupakan pertemuan khusus yang diadakan oleh staff teknikal dengan tujuan untuk menemukan masalah. Dalam berbagai situasi, review merupakan hal yang efektif seperti ujicoba dalam mengungkap kerusakan dalam software. 
3. Ujicoba perangkat lunak (software testing) Ujicoba software mengkombinasikan strategi beberapa tahapan/langkah dengan sejumlah desain metode uji kasus yang membantu memastikan pendeteksian kesalahan yang efektif. Banyak pengembang software menggunakan ujicoba software sebagai jaminan kualitas. 
4. Pelaksanaan standar (enforcement of standards) Tingkatan dimana prosedur dan standar formal diaplikasikan dalam proses pengembangan software, sangat bervariasi antara satu perusahaan dengan yang lainnya. Dalam banyak kasus, standar ditentukan oleh konsumen atau pembuat kebijakan. Jika standar disediakan(secara formal tertulis) maka aktivitas SQA harus dilaksanakan untuk memastikan standar-standar tersebut dilakukan. 
5. Pengawasan terhadap perubahan (control of change) Ancaman utama dalam kualitas software adalah perubahan yang dilakukan terhadap sumber. Setiap perubahan yang dilakukan pada software sangat potensial untuk menghasilkan kesalahan atau membuat efek sampingan yang mengakibatkan kesalahan. Proses pengawasan perubahan memberikan kontribusi secara langsung terhadap kualitas software dengan permintaan perubahan yang diformalkan. Pengawasan perubahan diaplikasikan selama pengembangan software dan setelahnya, atau selama tahapan pemeliharaan software.
6. Pengukuran (measurement) Pengukuran (measurement) merupakan aktivitas yang melengkapi setiap bidang pengembangan. Tujuan utama dari SQA adalah untuk menelusuri kualitas software dan memperkirakn pengaruh dari perubahansecara metodologi maupun prosedur pada peningkatan kualitas software. Untuk itu, ukuran-ukuran software (software metrics) harus dikumpulkan. 
7. Penyimpanan catatan dan laporan (record keeping and reporting) Penyimpanan catatan dan perekaman (record keeping and recording) pada SQA menyediakan prosedur untuk mengumpulkan dan penyebaran informasi SQA. Hasil dari review, audit, pengawasan perubahan, ujicoba, dan aktivitas SQA lainnyaharus menjadi bagian dari record history untuk proyek dan harus disebarkan untuk staff pengembangan untuk pengetahuan.

Staff Training and Sertification

Staff training and sertification

View more presentations from inggrid_5209100069.

Komponen Software Quality Assurance (SQA)

Berikut saya tampilkan slideshow PPT mengenai komponen SQA :

Komponen SQA

View more presentations from inggrid_5209100069.

Software Quality Metrics

Software quality metrics dikategorikan menjadi dua :

1. Product Metrics 
2. Product metrics 

Yang tiap kategori terdiri dari beberapa sub kategori. Berikut merupakan gambaran visualisasi untuk software quality metrics dalam bentuk mindmap nya. Semoga bermanfaat :)

TASK 2 NOMOR 2 MKTI

Mempelajari 11 Software Quality Factors dari Mc Call (dari buku Galin) dan Menganalisa 2 faktor pada Tugas Akhir. Berikut kami tampilkan dalam bentuk PPT.
By : Inggrid Anggraeni S. 5209100069 / Puji Agustin N. 5209100077

Software quality factors (revisi)

View more presentations from inggrid_5209100069.

TUGAS 2 MKTI

Kelompok :
1. Inggrid Anggraeni S. 5209100069
2. Puji Agustin Ningrum 5209100077

The 9 Causes of Software Errors
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

Kami memilih salah satu dari sembilan penyebab kesalahan software, yaitu Shortcomings of the testing process. Shortcomings of the testing process adalah kekurangan dalam proses pengujian. Penyebab Shortcomings of the testing process” terdiri dari beberapa hal, yaitu :

• Rencana pengujian yang kurang lengkap
• Kegagalan mendokumentasikan dan melaporkan error serta kesalahan dalam software
• Kegagalan untuk segera memperbaiki kesalahan pada software yang terdeteksi sebagai penyebab error.
• Kurangnya koreksi terhadap error yang terdeteksi.

Pengujian Perangkat Lunak (Software Testing) adalah suatu teknik yang digunakan untuk menentukan bahwa perangkat lunak yang dihasilkan telah memecahkan masalah. Pengujian Perangkat Lunak termasuk salah satu langkah dalam metodologi pengembangan system (SDLC: System Development Life Cycle). Namun, pada setiap aktivitas SDLC yang dilakukan pengujian tetap harus dilakukan.

Tiga konsep yang harus diperhatikan dalam Pengujian Perangkat Lunak, yaitu :

• Demonstrasi validitas perangkat lunak pada setiap tahapan pembangunan system.
• Penentuan validitas system akhir terhadap pemakai kebutuhan.
• Pemeriksaan implementasi system dengan menjalankan system pada suatu contoh data uji.

Studi Kasus

Permasalahan dalam pembuatan software Sistem Informasi Akademik (SIAKAD)

Pendahuluan

Sebuah PTS telah membangun Sistem Informasi Akademik mulai tahun 2002. Sejak itu proses developnya berjalan. Masalah demi masalah tentang proses pelayanan akademik terselesaikan. Seiring perkembangannya, sampai sekarangpun tahun 2007 masih saja permasalahannya ada. Dari mulai compatible terhadap hardware, koneksi jaringan, pemilihan sistem operasi dan ada saja gangguan non teknis sehingga project SIAKAD ini belum pernah selesai sampai sekarang.

Masalah

Setelah diklarifikasi, ternyata ada beberapa masalah yang hingga sekarang belum terselesaikan. Beberapa masalahnya antara lain :

1. Mengatasi mahasiswa lintas jalur, masih mengalami kesuliatan dalam konversi nilai yang dibutuhkan mahasiswa tersebut.
2. Mahasiswa baru mengisikan biodata tapi tidak bisa diambil oleh BAAK karena programnya tidak terintegrasi (per modul).
3. Report banyak yang tidak berjalan.

Dari pihak Developer software masih belum bisa memecahkan masalah-masalah diatas. Karena pihak develop belum mengelolah permasalahan-permasalahan yang ada minimal terdokumentasi dengan baik. Hal ini terbukti belum pernah ada laporan penyerahan dokumentasi ke pihak client. Selain itu di pihak developer tidak memiliki penguji software (SOFTWARE TESTER). Sehingga software yang bekembang selama ini baru diketahui oleh user kalau software tersebut bermasalah setelah di pakai di lapangan. Sehingga pihak client dan developer selalu saling menyalakan satu sama lain.

Solusi

Software SIAKAD ini akan lebih baik apabila pihak client dalam hal ini dari PTS dan pihak developer dalam hal ini Software House membentuk tim Software Tester yang bertugas untuk mengatasi masalah-masalah yang terjadi pada Software SIAKAD tersebut. Sehingga dengan melakukan Software Testing yang ditugaskan pada Software Tester, masalah yang selama ini terjadi dapat tereduksi dan kulalitas dari Software SIAKAD ini lebih baik.

MKTI Task 1

Pada semester 6 ini, saya mengambil mata kuliah pilihan Manajemen Kualitas Teknologi Informasi. Minggu pertama perkuliahan, terdapat tugas membuat presentasi mengenai The Software Quality Challenge dengan menggunakan prezi. Yang bisa dilihat disini

Semoga bermafaat :)

Revisi Tugas 1 MKTI on Prezi