Manajemen Kualitas Sistem Informasi · PDF fileReferensi Buku Utama: 1. Daniel Galin, Software...
-
Upload
trinhkhanh -
Category
Documents
-
view
227 -
download
2
Transcript of Manajemen Kualitas Sistem Informasi · PDF fileReferensi Buku Utama: 1. Daniel Galin, Software...
Manajemen Kualitas Sistem
Informasi
Referensi Buku Utama
1 Daniel Galin Software Quality ASsurance From theory to implementationPearson Adisson Wesley 2004
2 GGordon S James IMc Manus ldquoHandbook of software quality assurancerdquo 3rd ed Prentice Hall NEW JERSEY
3 Software Engineering A Practtionerrsquos Approach 2001 Oleh Roger S Pressman PhD
Buku Tambahan WEPerry ldquoQuality Assurance for Information SystemsrdquoQED Information
SciencesInc1991
Main Problems Addressed Deliver software system that
does what it is supposed to do
does the things correctly
showdemonstrateprove it (ldquodoes)
Major difficulties for the above
Size MLOC products common
Complexity
Environmental stressconstraints
Flexibilityadaptability expected
ldquono silver bullet but SQE (software quality engineering) helps
Major SQE activities
Scope and content hierarchy
System Implementation
Six major activities
1048708 Coding menterjemahkan hasil perancangan
1048708 Testing
1048708 Installation
1048708 Documentation
1048708 Training
1048708 Support
Purpose
1048708 To convert final physical system specifications into
working and reliable software
1048708 To document work that has been done
1048708 To provide help for current and future users
6
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Referensi Buku Utama
1 Daniel Galin Software Quality ASsurance From theory to implementationPearson Adisson Wesley 2004
2 GGordon S James IMc Manus ldquoHandbook of software quality assurancerdquo 3rd ed Prentice Hall NEW JERSEY
3 Software Engineering A Practtionerrsquos Approach 2001 Oleh Roger S Pressman PhD
Buku Tambahan WEPerry ldquoQuality Assurance for Information SystemsrdquoQED Information
SciencesInc1991
Main Problems Addressed Deliver software system that
does what it is supposed to do
does the things correctly
showdemonstrateprove it (ldquodoes)
Major difficulties for the above
Size MLOC products common
Complexity
Environmental stressconstraints
Flexibilityadaptability expected
ldquono silver bullet but SQE (software quality engineering) helps
Major SQE activities
Scope and content hierarchy
System Implementation
Six major activities
1048708 Coding menterjemahkan hasil perancangan
1048708 Testing
1048708 Installation
1048708 Documentation
1048708 Training
1048708 Support
Purpose
1048708 To convert final physical system specifications into
working and reliable software
1048708 To document work that has been done
1048708 To provide help for current and future users
6
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Main Problems Addressed Deliver software system that
does what it is supposed to do
does the things correctly
showdemonstrateprove it (ldquodoes)
Major difficulties for the above
Size MLOC products common
Complexity
Environmental stressconstraints
Flexibilityadaptability expected
ldquono silver bullet but SQE (software quality engineering) helps
Major SQE activities
Scope and content hierarchy
System Implementation
Six major activities
1048708 Coding menterjemahkan hasil perancangan
1048708 Testing
1048708 Installation
1048708 Documentation
1048708 Training
1048708 Support
Purpose
1048708 To convert final physical system specifications into
working and reliable software
1048708 To document work that has been done
1048708 To provide help for current and future users
6
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Major SQE activities
Scope and content hierarchy
System Implementation
Six major activities
1048708 Coding menterjemahkan hasil perancangan
1048708 Testing
1048708 Installation
1048708 Documentation
1048708 Training
1048708 Support
Purpose
1048708 To convert final physical system specifications into
working and reliable software
1048708 To document work that has been done
1048708 To provide help for current and future users
6
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Scope and content hierarchy
System Implementation
Six major activities
1048708 Coding menterjemahkan hasil perancangan
1048708 Testing
1048708 Installation
1048708 Documentation
1048708 Training
1048708 Support
Purpose
1048708 To convert final physical system specifications into
working and reliable software
1048708 To document work that has been done
1048708 To provide help for current and future users
6
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
System Implementation
Six major activities
1048708 Coding menterjemahkan hasil perancangan
1048708 Testing
1048708 Installation
1048708 Documentation
1048708 Training
1048708 Support
Purpose
1048708 To convert final physical system specifications into
working and reliable software
1048708 To document work that has been done
1048708 To provide help for current and future users
6
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
PEOPLErsquoS QUALITY EXPECTATIONS
In general people‟s quality expectations for software systems
they use and rely upon are two-fold
1 The software systems must do what they are supposed to do
In other words they must do the right things
2 They must perform these specific tasks correctly or
satisfactorily In other words they must do the things right
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Main tasks for software quality
engineering
1 quality planning
2 execution of selected QA or software validation and
verification activities
3 measurement and analysis to provide convincing evidence
to demonstrate software quality to all parties involved
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Quality
The American Heritage Dictionary defines quality as ldquoa
characteristic or attribute of somethingrdquo
Dalam PL
Kualitas desain karakteristik yang ditetapkan
Kualitas konformasi tingkat dimana spesifikasi desain terus diikuti
selama pembuatan
Dalam SW development
Kualitas desain mencakup syarat spesifikasi dan desain sistem
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
Quality views and attributes
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
FAKTOR KUALITAS PERANGKAT LUNAK
11
Yg dapat dihitung secara langsung
Error (Kesalahan)
Kilobytes Lines of Code (KLOC)
Dihitung secara tidak langsung
Usability (Kegunaan)
Maintainability (Pemeliharaan)
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
McCallrsquos Triangle of Quality
12
M a i n t a i n a b i l i t y M a i n t a i n a b i l i t y
F l e x i b i l i t y F l e x i b i l i t y
T e s t a b i l i t y T e s t a b i l i t y
P o r t a b i l i t y P o r t a b i l i t y
R e u s a b i l i t y R e u s a b i l i t y
I n t e r o p e r a b i l i t y I n t e r o p e r a b i l i t y
C o r r e c t n e s s C o r r e c t n e s s
R e l i a b i l i t y R e l i a b i l i t y
E f f i c i e n c y E f f i c i e n c y
I n t e g r i t y I n t e g r i t y
U s a b i l i t y U s a b i l i t y
P R O D U C T T R A N S I T I O N P R O D U C T T R A N S I T I O N P R O D U C T R E V I S I O N P R O D U C T R E V I S I O N
P R O D U C T O P E R A T I O N P R O D U C T O P E R A T I O N
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
FAKTOR KUALITAS hellip (McCall)
13
Correctness besarnya program dapat memuaskan spesifikasi amp
objektivitas dari misi pelanggan
Reliability besarnya program dapat diharapkan memenuhi fungsi2 yg
dikehendaki
Efficiency jumlah sumber2 amp 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 amp mengintepretasi kan output
program
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
SQAJaminan Kualitas Sistem
14
Merupakan kegiatan yg terpola secara sistematis dan terencana yg
dibutuhkan utk menjamin kualitas suatu perangkat lunakSI
Terdiri atas 7 aktifitas utama
Aplikasi metode secara teknis
Review teknis formal
Pengujian perangkat lunak
Penekanan pada standar
Pengontrolan pada perubahan
Pengukuran
Penyimpanan dan pelaporan
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
SQA (lanj)
15
SQA dimulai dgn sekumpulan alat amp metode teknis yg membantu analis utk
mendapatkan spesifikasi yg berkualitas tinggi amp bagi perancang utk
merancang dg kualitas tinggi
Setelah spesifikasi amp desain dibuat ditetapkan kualitasnya dg melakukan
review teknis formal
Pengujian per Lunak mengkombinasikan langkah2 strategi dg metode
rancangan test-case yg dpt menjamin pendeteksian kesalahan secara efektif
Jika terdapat standar yg formal berarti harus dapat dijamin bahwa standar
tsb diikuti
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
SQA (lanj)
16
Pengontrolan perubahan dilakukan selama pembuatan per Lunak amp pada
tahap pemeliharaan Setiap perubahan dpt menyebabkan kesalahan amp efek lain
yg akan menyebabkan kesalahan jg
Pengukuran terhadap per Lunak mencakup pengukuran secara manajemen amp
teknis
Penyimpanan hasil dari review audit pengontrolan perubahan pengujian dyl
sebagai bagian dari record historis utk suatu proyek dan didesiminasikan kpd
para staf pengembangan sbg bdquodasar utk mereka ketahui‟
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
REVIEW PERANGKAT LUNAK
17
Merupakan filter pada proses pembuatan perangkat lunak
Bentuknya presentasi formal di depan pelanggan manajemen amp staf
teknisi
Review ndash suatu cara penggunaan perbedaan2 dari sekompok orang
untuk
Menentukan peningkatan kebutuhan produk dari seseorang atau tim
Konfirmasi setiap bagian dari produk dimana peningkatan tsb diinginkan
atau tidak diinginkan
Mencapai kerja teknis yg seragam ataupun dapat lebih diprediksi daripada
tanpa review
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
PERTEMUAN PADA REVIEW TEKNIS FORMAL
18
Batasannya
Antara 3 amp 5 orang yg terlibat pemimpin review pereview amp produsen
Persiapan sebelumnya tidak lebih 2 jam kerja per orang
Lama pertemuan review minimal 2 jam
Fokus produk komponen program (spesifikasi kebutuhan
perancangan modul detail listing koding utk setiap modul
Akhir review harus diputuskan
Menerima produk tanpa modifikasi
Menolak produk krn kesalahan yg fatal
Menerima produk dg kesalahan yg kecil dan harus diperbaiki
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
PENDOKUMENTASIAN PADA REVIEW TEKNIS FORMAL
19
Laporan review harus dapat menjawab
Apa yg direview
Siapa yg mereview
Apa yg ditemukan amp disimpulkan
Daftar review mempunyai 2 tujuan
Mengidentifikasi area permasalahan produk
Menyediakan checklist setiap item kegiatan yg dapat memandu produsen utk
melakukan perbaikan
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
PEDOMAN REVIEW TEKNIS FORMAL
20
Mereview produk bukan produsen
Membuat agenda dan mengikutinya
Membatasi debat
Memberitahukan area masalah tetapi bukan utk menyelesaikan semua
masalah yg ada
Membuat catatan tertulis (di papanbisa dilihat)
Membatasi jumlah partisipan amp menekankan persiapan awal
Membuat checklist utk setiap produk yg direview
Mengalokasikan sumber daya amp waktu yg terjadual utk review berikutnya
Mengadakan pelatihan utk semua pereview
Mereview produk awal terlebih dulu (mis Panduan review)
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian
resource Software Engineering By RogerPressman
PROGRAM S2 UNIVERSITAS GUNADARMA
Software Quality Engineering Testing Quality Assurance and
Quantiable Improvement by Je Tian