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