1

Daftar Isi

A. Quality Assurance in Software Development Life Cycle

I. Software Development Life Cycle Model
II. The Prototyping Model
III. The Spiral Model
IV. The Object Oriented Model
V. Scrum
B. Faktor-faktor yang mempengaruhi intensitas kegiatan Quality Assurance dalam
proses development

1
A. Quality Assurance in Software Development Life Cycle
I. Software Development Life Cycle Model
Software Development Life Cycle Model (model SDLC) adalah model klasik
(masih berlaku sampai sekarang); ini memberikan deskripsi paling
komprehensif tentang proses yang tersedia. Model menampilkan blok
penyusun utama untuk seluruh proses pengembangan, yang digambarkan
sebagai urutan linier. Pada tahap awal proses pengembangan perangkat lunak,
dokumen desain produk disiapkan, dengan versi pertama program komputer
diselesaikan dan dipresentasikan untuk evaluasi hanya pada tahap akhir
proses.

Gambar 1 Software Development Life Cycle Model

■Requirements Definition. Untuk fungsionalitas sistem perangkat lunak yang

akan dikembangkan, pelanggan harus menentukan kebutuhan mereka. Dalam
banyak kasus, sistem perangkat lunak adalah bagian dari sistem yang lebih

2
besar. Informasi tentang bagian lain dari sistem yang diperluas membantu
menjalin kerja sama antara tim dan mengembangkan antarmuka komponen.
■ Analysis. Upaya utama di sini adalah menganalisis implikasi persyaratan
untuk membentuk model sistem perangkat lunak awal.
■Design. Tahap ini melibatkan definisi rinci dari output, input dan prosedur
pemrosesan, termasuk struktur data dan database, struktur perangkat lunak,
dll.
■ Coding. Pada fase ini, desain diterjemahkan ke dalam kode. Pengkodean
melibatkan kegiatan jaminan kualitas seperti inspeksi, tes unit dan tes
integrasi.
■ System Test. Tes sistem dilakukan setelah fase pengkodean selesai. Tujuan
utama pengujian adalah untuk mengungkap kesalahan perangkat lunak
sebanyak mungkin sehingga mencapai tingkat kualitas perangkat lunak yang
dapat diterima setelah koreksi selesai.
■ Installation and conversion. Setelah sistem perangkat lunak disetujui, sistem
diinstal untuk berfungsi sebagai firmware, yaitu sebagai bagian dari sistem
informasi yang mewakili komponen utama dari sistem yang diperluas. Jika
sistem informasi baru menggantikan sistem yang ada, proses konversi
perangkat lunak harus dimulai untuk memastikan bahwa aktivitas organisasi
terus berlanjut tanpa gangguan selama fase konversi.
■ Operation and Maintenance. Operasi perangkat lunak reguler dimulai setelah
penginstalan dan konversi selesai. Sepanjang periode operasi reguler, yang
biasanya berlangsung selama beberapa tahun atau hingga generasi perangkat
lunak baru muncul, diperlukan pemeliharaan. Pemeliharaan menggabungkan
tiga jenis layanan: korektif – memperbaiki kesalahan perangkat lunak yang
diidentifikasi oleh pengguna selama pengoperasian; adaptif – menggunakan
fitur perangkat lunak yang ada untuk memenuhi persyaratan baru; dan
perfective – menambahkan fitur minor baru untuk meningkatkan kinerja
perangkat lunak.

Jumlah fase dapat bervariasi sesuai dengan karakteristik proyek. Dalam model
skala besar yang kompleks, beberapa fase dibagi, menyebabkan jumlahnya
bertambah menjadi delapan, sembilan atau lebih. Dalam proyek yang lebih

3
 kecil, beberapa fase dapat digabungkan, mengurangi jumlah fase menjadi
enam, lima, atau bahkan empat fase.

Di akhir setiap fase, keluaran diperiksa dan dievaluasi oleh pengembang dan,
dalam banyak kasus, juga oleh pelanggan. Hasil yang mungkin dari tinjauan
dan evaluasi meliputi:
■ Persetujuan output fase dan melanjutkan ke fase berikutnya, atau
■ Tuntutan untuk memperbaiki, mengulang atau mengubah bagian dari fase
terakhir; dalam kasus tertentu, kembali ke fase sebelumnya diperlukan.

II. The Prototyping Model

Metodologi prototyping memanfaatkan (a) perkembangan teknologi informasi,
yaitu generator aplikasi canggih yang memungkinkan pengembangan
prototipe perangkat lunak dengan cepat dan mudah, dikombinasikan dengan
(b) partisipasi aktif dalam proses pengembangan oleh pelanggan dan
pengguna yang mampu memeriksa dan mengevaluasi prototipe.

Saat menerapkan metodologi pembuatan prototipe, pengguna sistem di masa

mendatang diharuskan mengomentari berbagai versi prototipe perangkat
lunak yang disiapkan oleh pengembang. Menanggapi komentar pelanggan dan
pengguna, pengembang memperbaiki prototipe dan menambahkan bagian ke
sistem untuk menghadirkan perangkat lunak generasi berikutnya untuk
evaluasi pengguna. Proses ini diulang sampai tujuan pembuatan prototipe
tercapai atau sistem perangkat lunak selesai.

4
 Gambar 2The Prototype Model

III. The Spiral Model

Model spiral, menawarkan metodologi yang lebih baik untuk mengawasi
proyek-proyek pembangunan yang besar dan lebih kompleks yang
menampilkan prospek kegagalan yang lebih tinggi, tipikal dari banyak proyek
yang dimulai dalam dua dekade terakhir. Ini menggabungkan model iteratif
yang memperkenalkan dan menekankan analisis risiko dan partisipasi
pelanggan ke dalam elemen utama SDLC dan metodologi prototyping.

Menurut model spiral, pengembangan perangkat lunak dianggap sebagai

proses berulang; pada setiap iterasi, kegiatan berikut dilakukan:
■ Perencanaan
■ Analisis dan penyelesaian risiko

5
 ■ Kegiatan perekayasaan sesuai dengan tahapan proyek: desain, pengkodean,
pengujian, pemasangan, dan pelepasan
■ Evaluasi pelanggan, termasuk komentar, perubahan dan persyaratan
tambahan, dan lain lain.

Gambar 3The SpiralModel

IV. The Object Oriented Model

Model berorientasi objek berbeda dari model lain dengan penggunaan kembali
komponen perangkat lunak secara intensif. Metodologi ini ditandai dengan
integrasi yang mudah dari modul perangkat lunak yang ada (disebut objek atau
komponen) ke dalam sistem perangkat lunak yang baru dikembangkan.
Pustaka komponen perangkat lunak melayani tujuan ini dengan menyediakan
komponen perangkat lunak untuk digunakan kembali.

Jadi, menurut model berorientasi objek seperti yang ditunjukkan, proses

pengembangan dimulai dengan urutan analisis dan desain berorientasi objek.
Fase desain diikuti dengan perolehan komponen yang sesuai dari pustaka
perangkat lunak yang dapat digunakan kembali, bila tersedia. Pengembangan
"reguler" dilakukan sebaliknya. Salinan komponen perangkat lunak yang baru
dikembangkan kemudian "disimpan" di pustaka perangkat lunak untuk
digunakan kembali di masa mendatang. Diharapkan stok komponen perangkat

6
 lunak yang berkembang di perpustakaan perangkat lunak yang dapat
digunakan kembali akan memungkinkan penggunaan kembali perangkat
lunak secara substansial dan meningkat, sebuah tren yang akan
memungkinkan pemanfaatan sumber daya yang lebih besar sebagai berikut:
■ Ekonomi – Biaya pengintegrasian komponen perangkat lunak yang dapat
digunakan kembali jauh lebih rendah daripada biaya pengembangan
komponen baru.
■ Peningkatan kualitas – Komponen perangkat lunak yang digunakan
diharapkan memiliki lebih sedikit cacat daripada komponen perangkat lunak
yang baru dikembangkan karena deteksi kesalahan oleh pengguna
sebelumnya.

Gambar 4 The Object Oriented Model

V. Scrum Model
Scrum adalah kerangka kerja yang membantu tim bekerja sama. Scrum mendorong
tim untuk belajar melalui pengalaman, mengatur diri sendiri saat mengerjakan suatu
masalah, dan merenungkan kemenangan dan kekalahan mereka untuk terus

7
meningkat. Scrum paling sering digunakan oleh tim pengembangan perangkat lunak
dalam beberapa tahun belakangan ini.

a. Kerangka kerja
Orang sering menganggap scrum dan agile adalah hal yang sama karena scrum
berpusat pada peningkatan berkelanjutan, yang merupakan prinsip inti dari agile.
Namun, scrum adalah kerangka kerja untuk menyelesaikan pekerjaan, di mana
kelincahan adalah pola pikirnya. Anda tidak bisa benar-benar "agile", karena
dibutuhkan dedikasi dari seluruh tim untuk mengubah cara berpikir mereka tentang
memberikan nilai kepada pelanggan Anda. Tetapi Anda dapat menggunakan
kerangka kerja seperti scrum untuk membantu Anda mulai berpikir seperti itu dan
berlatih membangun prinsip-prinsip agile ke dalam komunikasi dan pekerjaan
sehari-hari Anda.

Kerangka scrum bersifat heuristik; itu didasarkan pada pembelajaran berkelanjutan

dan penyesuaian terhadap faktor yang berfluktuasi. Diakui bahwa tim tidak
mengetahui segalanya pada awal proyek dan akan berkembang melalui pengalaman.
Scrum disusun untuk membantu tim secara alami beradaptasi dengan perubahan
kondisi dan kebutuhan pengguna, dengan prioritas ulang yang dibangun ke dalam
proses dan siklus rilis singkat sehingga tim Anda dapat terus belajar dan berkembang.

b. Artefak scrum
- Product Backlog adalah daftar utama pekerjaan yang harus diselesaikan oleh
pemilik produk atau manajer produk. Ini adalah daftar fitur, persyaratan, peningkatan,
dan perbaikan dinamis yang berfungsi sebagai masukan untuk sprint backlog. Ini,
pada dasarnya, adalah daftar "To Do" tim. Product Backlog terus-menerus ditinjau
kembali, diprioritaskan kembali, dan dikelola oleh Product Owner.
- Sprint Backlog adalah daftar item, user stories, atau bug fixes, yang dipilih oleh tim
develop untuk diterapkan dalam siklus sprint saat ini. Sebelum setiap sprint, dalam
rapat sprint planning, tim memilih item mana yang akan dikerjakan untuk sprint dari
product backlog. Sprint backlog mungkin fleksibel dan dapat berkembang selama
sprint.

8
- Increment (atau Sprint Goal) adalah produk akhir yang dapat digunakan dari sprint.
Selama demo akhir sprint, di mana tim menunjukkan apa yang telah diselesaikan
dalam sprint. Itu tergantung pada bagaimana tim mendefinisikan "done" dan
bagaimana tim menentukan tujuan sprint.

c. Upacara scrum atau acara

- Sprint Planning: Pekerjaan yang akan dilakukan (ruang lingkup) selama sprint saat
ini direncanakan selama pertemuan ini oleh seluruh tim develop. Spesifik user story
kemudian ditambahkan ke sprint dari product backlog. user story ini selalu selaras
dengan tujuan dan juga disepakati oleh tim scrum untuk dapat diterapkan selama
sprint. Di akhir rapat perencanaan, setiap anggota scrum harus jelas tentang apa yang
dapat disampaikan dalam sprint dan bagaimana peningkatan dapat disampaikan.

- Sprint: Sprint adalah periode waktu sebenarnya saat tim scrum bekerja sama untuk
menyelesaikan sebuah increment. Dua minggu adalah durasi yang cukup umum
untuk sprint. Selama periode ini, ruang lingkup dapat dinegosiasikan ulang antara
pemilik produk dan tim pengembangan jika diperlukan. Ini membentuk inti dari sifat
empiris scrum.

- Scrum atau daily stand up: Banyak tim mencoba menyelesaikan rapat dalam 15
menit, tetapi itu hanya pedoman. Pertemuan ini juga disebut 'daily stand-up' yang
menekankan bahwa itu harus cepat. Sasaran scrum harian adalah agar setiap orang
dalam tim memiliki pemahaman yang sama, selaras dengan sasaran sprint, dan
menyusun rencana untuk 24 jam ke depan. Stand up adalah waktu untuk
menyuarakan keprihatinan apa pun yang Anda miliki dengan memenuhi tujuan sprint
atau penghalang apa pun. Cara umum untuk melakukan stand up adalah setiap
anggota tim menjawab tiga pertanyaan dalam rangka mencapai tujuan sprint:
• Apa yang saya lakukan kemarin?
• Apa yang saya rencanakan hari ini?
• Apakah ada kendala?

- Sprint Review: Di akhir sprint, tim berkumpul untuk sesi informal untuk melihat
demo, atau memeriksa, kenaikan. Tim pengembangan menampilkan item simpanan

9
yang sekarang 'done' kepada stakeholder dan rekan tim untuk mendapatkan
feedback. Pemilik produk dapat memutuskan apakah akan melepaskan kenaikan
atau tidak, meskipun dalam banyak kasus kenaikan tersebut dilepaskan.

- Sprint Retrospective: saat tim berkumpul untuk mendokumentasikan dan

mendiskusikan apa yang berhasil dan apa yang tidak berhasil dalam sprint, proyek,
orang atau hubungan, alat, atau bahkan untuk upacara tertentu. Idenya adalah untuk
menciptakan tempat di mana tim dapat fokus pada apa yang berjalan dengan baik
dan apa yang perlu diperbaiki untuk waktu berikutnya, dan lebih sedikit tentang apa
yang salah.

Gambar 5 Scrum Model

B. Faktor-faktor yang mempengaruhi intensitas kegiatan Quality Assurance

dalam proses development
Kegiatan jaminan kualitas siklus hidup proyek berorientasi pada proses, dengan kata
lain, terkait dengan penyelesaian fase proyek, pencapaian tonggak proyek, dan
sebagainya. Kegiatan penjaminan mutu akan diintegrasikan ke dalam rencana
pengembangan yang mengimplementasikan satu atau lebih model pengembangan
perangkat lunak –waterfall, prototyping, spiral, berorientasi objek atau model lainnya.

10
Perencana jaminan kualitas untuk suatu proyek diharuskan untuk menentukan:
■ Daftar kegiatan penjaminan mutu yang diperlukan untuk suatu proyek.
■ Untuk setiap kegiatan penjaminan mutu:
– Pengaturan waktu
– Jenis kegiatan penjaminan mutu yang akan diterapkan
– Siapa yang melakukan aktivitas dan sumber daya yang dibutuhkan. Perlu dicatat
bahwa berbagai badan dapat berpartisipasi dalam kinerja kegiatan penjaminan mutu:
tim pengembangan dan anggota staf departemen bersama-sama dengan badan
independen seperti anggota tim atau konsultan penjaminan mutu eksternal.
– Sumber daya yang diperlukan untuk menghilangkan cacat dan pengenalan
perubahan.

Intensitas kegiatan penjaminan mutu yang direncanakan, ditunjukkan dengan jumlah

kegiatan yang dibutuhkan, dipengaruhi oleh faktor proyek dan tim, seperti yang
ditunjukkan pada Frame 7.2.

11
Referensi

Perry, William E. 2006. Effective Methods for Software Testing, Third Edition.
Canada: Wiley Publishing, Inc.
https://www.atlassian.com/agile/scrum

12