Rabu, 13 Juni 2012

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
  2. 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.
  3. 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.
  4. 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.
  5. 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