Model AQAM mengusulkan pendekatan baru untuk jaminan kualitas perangkat lunak yang fleksibel dan dapat disesuaikan, dengan memungkinkan tim untuk memilih KPA tertentu dan mengkustomisasinya sesuai kebutuhan. Hal ini membedakan AQAM dari model sebelumnya yang lebih fokus pada proses standar tanpa fleksibilitas.

1. A Customizable Agile
Software Quality
Assurance Model
{ Kelompok 17:
Irine Dwi Kenestie 5209100001
Rizqi Prifsanti 5209100084

2. Content
 Introduction
 AQAM definition
 KPA implementations
 Discussion and Future Works
 Conclusion
 References

3. Background
• Kondisi Saat Ini:
- Model yang digunakan biasanya hanya untuk tipe organisasi menengah-atas, karena
kompleksitas dan formalitas
- Model yang berfokus pada perbaikan proses pengujian dan diposisikan sebagai
pelengkap model sebelumnya
• Kondisi Yang Di Harapkan:
- Model jaminan kualitas yang fleksibel dan up-to-date yang dapat disesuaikan
berdasarkan ukuran yang berbeda dan gaya manajemen.
- User friendly, model ini harus menyediakan template atau rincian pelaksanaan
sehingga tim pengembangan tidak mengandalkan konsultasi profesional terlalu
banyak untuk menerapkan model
• Tujuan Dari Paper:
Tujuan dari paper ini ialah untuk mmengusulkan sebuah jaminan kualitas model proses
baru yang disebut AQAM (Agile Quality Assurance Model) model ini diperuntukkan
terutama untuk tim pengembangan software agile yang berukuran kecil dan menengah
untuk menganalisis dan meningkatkan kemampuan QA mereka.

4. Introduction
 Jaminan kualitas dan pengujian sangat penting untuk software berkualitas
tinggi dan ketepatan waktu pengiriman. Beberapa model terkenal yang di
bahas ialah:
 Capability Maturity Model (CMM) dan Capability Maturity Model Integration (CMMI).
Tujuan utama dari CMM dan CMMI adalah untuk membandingkan kemampuan &
kematangan antara organisasi dari luar. CMM dan CMMI biasanya lebih cocok untuk tipe
organisasi menengah hingga organisasi berukuran besar. CMMI adalah sebagian besar
tentang proses apa yang harus dilaksanakan, dan bukan tentang bagaimana mereka harus
dilaksanakan.
 TMM (Testing Maturity Model), berdasarkan CMM, TMM adalah model jatuh tempo
dengan fokus pada tes.
 TMMI (Testing Maturity Model Integration) adalah model yang berfokus pada perbaikan
proses pengujian dan diposisikan sebagai pelengkap CMMI. TMMI menggunakan sistem
tingkat kematangan dipentaskan.
 TPI (Test Process Improvement), TPI berfokus pada pengujian perangkat lunak, bukan
kegiatan lain dari jaminan kualitas perangkat lunak, seperti pencegahan cacat, koreksi
cacat, atau peer review yang dianggap sangat penting untuk jaminan kualitas perangkat
lunak.

5. Methodology
 Struktur di bawah menggambarkan arsitektur dari pekerjaan AQAM. Karena tidak
semua KPA memiliki tingkat yang sama-sama penting untuk kinerja proses jaminan
kualitas secara lengkap, tidak semua KPA diperlakukan sama di AQAM. Kami
mendorong tim yang berbeda untuk memilih KPA tertentu sesuai dengan kebutuhan
mereka dan tingkat mereka saat jatuh tempo. Tim kemudian dapat fokus pada KPA
dipilih. Praktik ini sangat berbeda dari CMM atau TMM.
 Guidelines, benefits, processes, best practices, templates, customization guides, and
maturity levels.

6. AQAM Process
Customization Section

7. KPA implementations

8. Analysis/Result
{ Dalam AQAM, pada masing-
masing KPA mencakup petunjuk,
manfaat, proses, best practices,
{ Benefit
Peer review dapat menyediakan
template, kustomisasi dan tingkat
kematangan. kepada anggota tim dan manager
mengenai bermacam-macam
Guidelines tingkatan dengan melihat kualitas
KPA peer review memiliki 7 guidelines, 7 dari produk yang teridentifikasi dari
best practices and 3 table templates kekurangan dan menyediakan
1. How to choose between group review and umpan balik terhadap anggota tim
single person review dan manager mengenai hasil review.
2. How to choose between informal review
and formal review
3. How to do review planning
4. Who are the participants of a review
meeting
5. How to calculate review efficiency
6. How to calculate defect detection efficiency
7. How to analyze defect detection efficiency

9. Processes (cont’d)
• Peranan dalam Peer Review adalah: moderator,
reviewer, author, reviser, dan observer
• Moderator  mengatur review, mengumpulkan
material untuk mereview, mendistribusikan material
kepada para reviewer, menyampaikan sesi review
dan follow up nya.
• Author bisa sekaligus menjadi moderator dan reviser.
• Review session merekam semua kekurangan/cacat
yang ditemukan dan resolusi untuk kekurangan
tersebut, dan dengan timeline yang ditentukan.
• Harus terencana  material, reviewer, schedule
• Metode agar peer review ridak ditinggalkan  project
management harus meminta tim untuk meluangkan
presentase waktunya untuk peer review pada fase
planning, dan memaksa agar rencana ini dijalankan

10. Best Practises
• Mengedukasi anggota organisasi akan manfaat peer review agar
mereka termotivasi
• Memilih member yang berpengalaman sebagai reviewer
• Mengidentifikasi dan memilih pekerjaan penting sebagai material
review
• Ketika teknologi baru diadopsi dalam tim, tambah frekuensi review
• Pekerjaan member yang tidak berpengalaman harus diprioritaskan
untuk direview
• Manajemen tidak seharusnya menggunakan peer review sebagai
performance evaluation
• Peer review harus dimasukkan pada project plan secara keseluruhan

11. Templates
• Review Memo
• merekam issue yang
ditemukan saat proses
persiapan dan ditunjukkan
pada saat sesi review
• Review Session Log
• digunakan untuk merekam
kekurangan yang dikonfirmasi
dalam meeting dan status dari
kekurangan yang belum
diselesaikan.
• Common categorized defect
table
• untuk pencegahan kekurangan
dan pelatihan reviewer dan
author

12. •
{ Customization
Konten yang diperlukan
{

Maturity Level
Level 1: Initial
• Keseluruhan perencanaan project,
spesifikasi kebutuhan, design secara
keseluruhan, testing plan  Level 2: Performed
• Peer review harus dimasukkan dalam
project plan atau testing plan  Level 3: Managed
• Konten yang disarankan  Level 4: Optimized
• Review session log 
mendokumentasikan semua defect
dan resolusi lebih efisien
• Common categorized defect table 
berguna untuk pencegahan defect
dan merupakan pelatihan untuk tim
• Konten yang bisa dicustomize
• Review memo  optional
• Field the hours pada Review Memo
dan Review Session Log  optional
• Field Amount of Work Reviewed
pada Review Memo dan Review
Session Log  optional
• Review Session Log  optional,
tetapi jika tidak dilakukan, tim
harus melacak status dari issue yang
belum terselesaikan

13. Conclusion (Discussion)
AQAM adalah model proses baru SQA yang
ditujukan untuk tim software development
dengan ukuran small atau medium. Dengan
AQAM, organisasi dapat mengkustomisasi dan
memanage model proses berdasarkan level
maturity, proses penjaminan kualitas dan style
manajemen pada organisasi tersebut. Model
didemokan cara kerjanya dengan contoh salah
satu KPA-nya yaitu Peer Review.

14. References
[1] Fowler, P., Rifkin S., Software Engineering Institute, Software Engineering Process Group Guide, Technical
Report, CMU/SEI-90-TR-24, 1990
[2] Caputo, K., CMM Implementation Guide: Choreographing Software Process Improvement, Addison-
Wesley, 1998
[3] Software Engineering Institute, Capability Maturity Model Integration (CMMI®), CMMI® for
Development, Version 1.3, Technical Report, Nov. 2010
[4] Burnstein, I., Suwannasart, T., and Carlson, C.R., A Model to Assess Testing Process Maturity, Crosstalk,
Nov. 1998
[5] TMMi Foundation, Test Maturity Model Integration (TMMi) Version 3.1, Retrieved March 1, 2011, TMMi
Foundation: http://www.tmmifoundation.org/downloads/tmmi/TMMi%20Framework.pdf, Ireland.2010
[6] Jari Andersin, TPI – a model for Test Process Improvement,
http://www.cs.helsinki.fi/u/paakki/Andersin.pdf, retrieved on July 01, 2011.
[7] Deissenboeck, F., Juergens, E., Lochmann, K., Wagner, S., Software quality models: Purposes, usage
scenarios and requirements, WOSQ '09. ICSE
Workshop on Software Quality, 2009
[8] De Souza, C. R. B., Redmiles D. F., An Empirical Study of Software Developers’ Management of
Dependencies and Changes. In ICSE’08, Proceedings of the 30th International Conference on Software
Engineering, May 10–18, 2008, Leipzig, Germany. 241-250
[9] Nagappan, N., Maximilien, E., Bhat, T., Williams, L., Realizing quality improvement through test driven
development: results and experiences of four industrial teams, Empirical Software Engineering, Volume 13,
Issue 3, 2008 289-302
[10] Paulk, M. C., Weber, C. V., Curtis, B., Chrissis, M. B., The Capability Maturity Model for Software:
Guidelines for Improving the Software Process, Addison-Wesley, 1995
[11] Fowler, M., Continuous Integration, 2006,
http://www.martinfowler.com/articles/continuousIntegration.html,
retrieved on March 01, 2011.
[12] http://en.wikipedia.org/wiki/V_model , retrieved June 1, 2011

15.  Apa kelebihan AQAM dibandingkan dengan
model SQA lainnya seperti CMM, TMM,
TMMI, TPI?
Question