Presentasi Sidang Akhir
Penjaminan Kualitas Pengembangan Perangkat Lunak pada
Aplikasi School Social Network (SSN) berdasarkan Standar IEEE
730-2002
Pembimbing 1 : Ir. Achmad Holil Noor Ali, M.Kom
Pembimbing 2 : Hanim Maria Astuti, S.Kom, M.Sc
Oleh :
Ika Nurkasanah (5209100083)
LATAR BELAKANG
3
Penyimpangan terhadap kebutuhan kualitas yang disepakati di awal dapat terjadi karena tidak adanya prosedur atau instruksi yang seragam untuk setiap aktivitas pengembangan
Susahnya mendeteksi kesalahan pada aplikasi lebih awal karena tidak adanya checklist, sehingga dapat menyebabkan banyaknya kesalahan pada saat aplikasi akan disampaikan ke klien (saat validasi & verifikasi)
Usaha yang dilakukan untuk pengembangan / pemeliharaan aplikasi ke depannya akan sulit karena saat ini tidak ada dokumentasi pengembangan yang akan dijadikan acuan
Pengaruh negatif terhadap tradeoff
pengembangan SSN akibat tidak adanya metodologi pengembangan aplikasi “best practice” yang diadaptasi
Kontrol terhadap proses pengembangan aplikasi SSN belum dilakukan dengan baik
PERUMUSAN MASALAH
Penyimpangan terhadap kebutuhan kualitas yang disepakati di awal dapat terjadi karena tidak adanya prosedur atau instruksi yang seragam untuk setiap aktivitas pengembangan
Susahnya mendeteksi kesalahan pada aplikasi lebih awal karena tidak adanya checklist, sehingga dapat menyebabkan banyaknya kesalahan pada saat aplikasi akan disampaikan ke klien (saat validasi & verifikasi)
Usaha yang dilakukan untuk pengembangan / pemeliharaan aplikasi ke depannya akan sulit karena saat Pengaruh negatif terhadap tradeoff pengembangan SSN akibat tidak adanya metodologi pengembangan aplikasi “best practice” yang diadaptasi
Kontrol terhadap proses pengembangan aplikasi SSN belum dilakukan dengan baik
Metodologi pengembangan best
practice
apakah yang sesuai untuk pengembangan aplikasi SSN yang sedang berjalan saat ini?1
Standar
penjaminan kualitas perangkat lunak apa sajakah yang terkait dengan standar IEEE 730-2002?2
Bagaimana
menyesuaikan
standarpenjaminan kualitas dengan metodologi yang sesuai sehingga membantu pihak pengembang dalam memenuhi kualitas SSN yang dijanjikan kepada pelanggan?
• Penjaminan kualitas pengembangan aplikasi SSN yang dikerjakan dalam
tugas akhir ini terbatas pada perencanaan penjaminan kualitas dengan
menggunakan infrastruktur penjaminan kualitas berdasarkan standar
IEEE 730-2002
sebagai standar utama.
• Perencanaan penjaminan kualitas aplikasi SSN hanya dibuat untuk siklus
hidup proyek pengembangan aplikasi pada tahap eksekusi (
penggalian
kebutuhan, desain, koding, dan uji coba
).
5
• Tujuan pembuatan tugas akhir ini adalah untuk membuat suatu
dokumen penjaminan kualitas pengembangan aplikasi
SSN
yang sesuai dengan standar IEEE 730-2002 dan standar penjaminan
kualitas perangkat lunak lain yang terkait, serta metodologi best practice
yang sesuai untuk pengembangan aplikasi tersebut.
Bagi pengembang SSN
7
MANFAAT
Dapat mengetahui dan membuat penjaminan kualitas
pengembangan perangkat lunak sesuai standar
Dapat menerapkan pada dunia kerja nantinya
Perangkat lunak yang dihasilkan memenuhi kualitas ( kebutuhan
pelanggan) Proses pengembangan aplikasi
sesuai standar kualitas
Membantu efektivitas proses koordinasi dengan pihak
pengembang Membantu proses kontrol
Membantu memastikan bahwa aplikasi yang dibuat oleh tim pengembang / pengembang sudah memenuhi ekspektasi
Membantu mengevaluasi dan memastikan bahwa aktivitas –
aktivitas penjaminan kualitas dilakukan dengan baik
Bagi penulis
9
PERANGKAT LUNAK
Menurut IEEE (1991), definisi perangkat lunak (software) adalah program
komputer, prosedur, dokumentasi, dan data mengenai operasional sistem
komputer
Definisi Perangkat Lunak
1. Program komputer (kode)
2. Prosedur
3. Dokumentasi
4. Data
SOFTWARE QUALITY ASSURANCE
• Pola aktivitas yang terencana dan sistematis untuk menyediakan produk perangkat
lunak yang memenuhi kebutuhan teknis.
• Serangkaian aktivitas yang direncanakan untuk mengevaluasi proses dimana
perangkat lunak dibangun atau dikembangkan.
Software Quality Assurance (IEEE,2008)
• Menjamin tingkat pemenuhan kebutuhan teknis
fungsional.
• Menjamin tingkat pemenuhan kebutuhan manajerial
terkait dengan penjadwalan dan keuangan.
• Menginisiasi dan mengatur aktivitas yang dilakukan
untuk peningkatan efisiensi pembangunan perangkat
lunak.
11
SOFTWARE QUALITY ASSURANCE
Sumber : Galin, D. (2004). Software Quality Assurance From Theory to Implementation. London: Pearson Addison Wesley.
METODOLOGI PENGEMBANGAN PERANGKAT LUNAK
Strategi tertentu terkait proses – proses yang harus dilakukan untuk membangun
suatu perangkat lunak yang berkualitas berdasarkan beberapa faktor :
Waktu Sumber daya Biaya Kualitas
Jenis Metodologi Pengembangan Perangkat Lunak menurut M.A
Awad (2005)
Traditional
13
STANDAR PENJAMINAN KUALITAS PERANGKAT LUNAK
IEEE 730-2002
• Memiliki
fleksibilitas yang tinggi
untuk diintegrasikan dengan standar lain seperti ISO• Menjelaskan kebutuhan penjaminan kualitas untuk proses inisiasi, perencanaan, controlling,
eksekusi, serta maintenance pengembangan perangkat lunak
• Kunci utama :
• Manajemen Pertanggungjawaban
• Penjaminan kualitas pada produk dan proses perangkat lunak • Resiko Produk perangkat lunak
• Tingkat Integritas perangkat lunak • Kasus penjaminan
• Non-Conformance Requirement
• Tindakan corrective & preventive
SCHOOL SOCIAL NETWORK (SSN)
Bagan 3 Aplikasi - Aplikasi pada SLIMS+
Digunakan untuk memberikan pelayanan kepada pengguna melalui penyediaan dan penyampaian
informasi terkait hal – hal yang berhubungan dengan sekolah.
15
SCHOOL SOCIAL NETWORK (SSN)
FITUR SSN
Fitur Siswa
SCHOOL SOCIAL NETWORK (SSN)
FITUR SSN
Fitur Guru
Fasilitas – fasilitas yang disediakan untuk guru hampir sama dengan siswa, hanya saja pada manajemen fasilitas tertentu, hanya guru yang berhak
mengaksesnya. Misalnya pada manajemen acara dan manajemen akademik. Siswa hanya dapat membaca informasi dari guru / pihak sekolah. Sedangkan guru yang akan memasukkan informasi tersebut
17
METODE PENGERJAAN TUGAS AKHIR
STUDI LITERATUR
1. Metodologi pengembangan aplikasi
best practice
2. Standar penjaminan kualitas perangkat
lunak yang terkait dengan standar IEEE
730-2002
KELUARAN
1. Daftar standar penjaminan kualitas terkait IEEE 730-2002 yang akan digunakan.
2. Macam – macam metodologi tradisional dan Agile beserta kondisi penggunaannya.
1. Studi lebih lanjut mengenai proses
eksekusi pengembangan aplikasi SSN
yang sedang berjalan
2. Analisa metodologi best practice yang
sesuai untuk pengembangan aplikasi
SSN yang sedang berjalan
KELUARAN
1. Penjelasan mengenai proses eksekusi pengembangan aplikasi SSN yang sedang berjalan
2. Metodologi best practice yang sesuai dengan pengembangan SSN beserta penjelasan
analisanya
19
METODE PENGERJAAN TUGAS AKHIR
PEMBUATAN DOKUMEN PENJAMINAN
KUALITAS
Penyesuaian standar IEEE 730-2002
,standar penjaminan kualitas perangkat
lunak yang terkait, dan metodologi best
practice yang sesuai untuk SSN
KELUARAN
Dokumen penjaminan kualitas sesuai yang
berisi prosedur, checklist, template, metrics,
dan infrastruktur lain yang dibutuhkan (yang
disesuaikan dengan standar penjaminan
kualitas dan metodologi best practice
Evaluasi pemenuhan standar penjaminan
kualitas dan metodologi best practice
dalam dokumen penjaminan kualitas
pengembangan aplikasi SSN
KELUARAN
Hasil evaluasi pemenuhan standar penjaminan kualitas dan metodologi best practice dalam dokumen penjaminan kualitas pengembangan SSN
EVALUASI DOKUMEN PENJAMINAN KUALITAS
4.1. Standar Penjaminan Kualitas yang Terkait dengan IEEE
730-2002
1. IEEE Std. 1016-2009 Software Design Description
2. IEEE Std. 829-1998 System & Software Test Documentation
3. IEEE Std. 828-2005 Software Configuration Management
Plans
4. ISO IEC 12207 / IEEE 12207-2008 (Software & System
21
4.2. Metodologi Best Practice Pengembangan Perangkat
Lunak
Tradisional (M. A. Awad (2005))
Waterfall
4.2. Metodologi Best Practice Pengembangan Perangkat
Lunak
Agile ((ABRAHAMSSON, Pekka et al.,
2002))
eXtreme Programming
Feature Driven Development Model
Dan beberapa jenis metodologi Agile
lainnya yang dibandingkan berdasarkan
proses, peran & tanggung jawab, serta
praktik
23
4.3. Proses Eksekusi Pengembangan School Social Network
(SSN)
Fase Penjelasan
Penggalian Kebutuhan Proses penggalian kebutuhan dilakukan dengan presentasi langsung ke
pelanggan. Tim pengembang yang menawarkan fitur yang akan disediakan dengan scenario
Desain Belum ada dokumen desain atau spesifikasi kebutuhan perangkat lunak. Desain
yang dibuat adalah desain – desain tingkat tinggi seperti diagram database,
sistem, dan antarmuka yang masih terpisah – pisah.
Koding Proses koding dilakukan per fitur dan juga berdasarkan versi aplikasi,yaitu
mobile dan web.
Terdapat standarisasi penamaan folder upload file terbaru via dropbox
Testing Validasi
Validasi dilakukan langsung tanpa scenario atau test case
Testing dilakukan setiap selesai 1 fitur.
Dilakukan integration testing dan peer programming juga unuk mengecek kekurangan masing – masing fitur bagiannya.
Verifikasi
Dilakukan verifikasi melalui on-site customer (di lingkungan pelanggan)
Jika saat verifikasi masih ada yang kurang baik atau harus diperbaiki, maka akan kembali ke fase koding. Kami memfasilitasi adanya incremental.
4.4. Metodologi Best Practice untuk Pengembangan SSN
Faktor Pemilihan Metodologi (menurut M.A. Awad)
Karakteristik eksisting pengembangan SSN Tradisional Agile
Jumlah tim pengembang Kurang dari 10 orang
Perubahan pada proyek Dapat berubah – ubah sewaktu – waktu (tingkat
perubahan tinggi)
Tujuan utama proyek Sebagai aplikasi pendukung yang membutuhkan
keamanan yang handal
Membutuhkan waktu pengembangan yang cepat
Manajemen kebutuhan Membutuhkan baseline
Namun tetap bisa melayani perubahan sewaktu – waktu (fleksibilitas)
Komunikasi Intensif & cenderung face-to-face
Hubungan dengan pelanggan Membutuhkan kontrak yang secara jelas
mendefinisikan hubungan
Budaya Organisasi Pembagiannya tidak spesifik, hanya manajer
proyek dan programmer saja yang jelas
Lebih Dominan
25
4.4. Metodologi Best Practice untuk Pengembangan SSN
Nama Metodologi Poin Kunci Fitur Spesial Kekurangan
Adaptive Software Development (ASD)
Budaya adaptif, kolaborasi, komponen mission-driven berbasis pengembangan iteratif
Organisasi dilihat sebagai sistem yang adaptif.
ASD lebih berfokus pada konsep dan budaya daripada praktek terhadap perangkat lunak
Agile Modelling (AM) Menerapkan prinsip Agile
untuk memodelkan : budaya, dukungan komunikasi pada organisasi, kesederhanaan
Modelling Baik untuk filosofi add-on
dalam modeling
professionals, namun hal tersebut baru berjalan ketika diterapkan pada
metode lainnya
Crystal Family of Methods. Setiap
proyek memiliki standar yang berbeda, namun dengan prinsip, teknik, dan peranan yang sama
Prinsip metode desain. Kemampuan untuk memilih metode yang paling sesuai dengan ukuran proyek dan kekritisannya
Terlalu dini untuk estimasi. Hanya 2 dari 4 metode yang direkomendasikan yang berjalan.
4.4. Metodologi Best Practice untuk Pengembangan SSN
Nama Metodologi Poin Kunci Fitur Spesial Kekurangan
Dynamic System Development Model (DSDM)
Implementasi kontrol dari metode RAD, penggunaan timeboxing, optimalisasi tim, konsorsium aktif untuk mengendalikan metode pengembangan
Penggunaan prototyping,
penggunaan beberapa peran pengguna, yaitu ambassador, visionary, dan advisor.
Ketika metode ini dijalankan, hanya anggota konsorsium yang berhak mengakses laporan yang berkaitan dengan metode actual yang digunakan
eXtreme
Programming (XP)
Pengembangan berorientasi pelanggan, tim kecil, daily builds
Refaktor. Proses desain ulag sistem dilakukan untuk meningkatkan kinerja dan respon terhadap perubahan
Ketika praktik individual sesuai untuk berbagai situasi, pandangan keseluruhan dan praktek manajemen mendapatkan perhatian yang kurang.
Features Driven Development (FDD)
Proses 5 langkah, komponen berbasis objek. Iterasi yang pendek
Kesederhanaan metode, desain, dan implementasi sistem berdasarkan fitur, object
modeling.
FDD fokus hanya pada desain dan implementasi dan membutuhkan
pendekatan lainnya yang
27
4.4. Metodologi Best Practice untuk Pengembangan SSN
Nama Metodologi Poin Kunci Fitur Spesial Kekurangan
Open Source Software (OSS)
Volunteer based development, masalah yang sering timbul cenderung merupakan tantangan daripada usaha komersial
Licensing practice, source code freely, tersedia untuk semua pihak.
OSS bukan metodologi yang berdiri sendiri, dapat ditransformasikan pada prinsip komunitas dan commercial software development.
Pragmatic Programming
Menekankan pada
pragmatism, teori pemroraman tidak begitu penting, otomatisasi pada semua aspek pemrograman sangat penting
Konkrit, pragmatic approach Fokus hanya pada praktik individu. Bagaimanapun hal tersebut bukan metode dimana suatu sistem dapat dibangun
Rational Unified Process (RUP)
Model pengembangan yang lengkap termasuk terkait dengan item – item pendukungnya.
Business modeling, tool family support
RUP tidak memiliki batasan penggunaan ruang lingkup, namun banyak perubahan kebutuhan yang hilang.
Scrum Independen, kecil,
self-organizing team, 30-day release cycle.
Menekankan paradigma
“definisi dan pengulangan” pada pengembangan produk baru.
Ketika Scrum detail pada
manajemen 30 hari rilis yang detail, integration dan acceptance test tidak detail.
4.4. Metodologi Best Practice untuk Pengembangan SSN
Terdapat 3 metode yang memiliki kecenderungan karakteristik yang sama dengan
proses pengembangan SSN yang nyata
No
Jenis Metodologi Agile
1
eXtreme Programming
2
Feature Driven Development
29
4.4. Metodologi Best Practice untuk Pengembangan SSN
Ketidaksesuaian Metodologi XP dengan Proses Pengembangan Nyata
Aspek
Perbandingan
Konsep XP
Kondisi Eksisting
Praktik
Small / short releases
Rilis dilakukan dalam internal tim,
untuk ke masyarakat umum belum
bisa dilakukan karena aplikasi belum
jadi sepenuhnya.
40-hour week
Dalam
kenyataannya,
waktu
pengerjaan tidak selalu dengan
waktu maksimal 40 jam.
4.4. Metodologi Best Practice untuk Pengembangan SSN
Ketidaksesuaian Metodologi FDD dengan Proses Pengembangan Nyata
Aspek
Perbandingan
Konsep FDD
Kondisi Eksisting
Proses
Pembuatan desain fitur
Desain yang dilakukan hanya sebatas
desain database untuk tiap fitur dan
juga class diagramnya, namun itu
bukan
fokus
utamanya,
fokus
utamanya adalah pada koding. Desain
kadang
dilakukan
setelah
fitur
dibangun
Pembangunan fitur
Pembangunan fitur tidak selalu
dilakukan setelah desain
Peran
dan
tanggung jawab
Manajer proyek Chief architect Manajer pembangunan Chief Programmer Class Owner Domain Expert Domain manager Release manager Language lawyer Build engineer Toolsmith Administrator sistemTerdapat beberapa peran yang tidak
dimiliki
pada
pengembangan
eksisting, yaitu domain manager,
language
lawyer,
toolsmith,
administrator sistem, deployer, dan
technical writer
31
4.4. Metodologi Best Practice untuk Pengembangan SSN
Ketidaksesuaian Metodologi FDD dengan Proses Pengembangan Nyata (2)
Aspek
Perbandingan
Konsep FDD
Kondisi Eksisting
Praktik
Individual Class Ownership
Suatu class atau kode bisa dimiliki
oleh kedua programmer SSN.
4.4. Metodologi Best Practice untuk Pengembangan SSN
Ketidaksesuaian Metodologi Scrum dengan Proses Pengembangan Nyata
Aspek
Perbandingan
Konsep Scrum
Kondisi Eksisting
Proses
Development. Dilakukan sprint yang
sama dengan model tradisional, yaitu
mulai penggalian kebutuhan sampai
penyampaian.
Dilakukan iterasi hanya mulai koding
sampai uji coba
Jika ada backlog, maka itu akan
dilakukan pada saat pemeliharaan dan
rilis dalam versi selanjutnya.
Praktik
Product Backlog
Backlog pada SSN dikerjakan pada
versi yang baru, tidak semuanya
dilakukan pada versi yang sama
dengan yang saat ini dikerjakan.
Sementara backlog pada scrum
dilakukan dalam versi yang sama
33
4.4. Metodologi Best Practice untuk Pengembangan SSN
Ketidaksesuaian Metodologi Scrum dengan Proses Pengembangan Nyata (2)
Aspek
Perbandingan
Konsep Scrum
Kondisi Eksisting
Praktik
Sprint
Proses sprint yang menggabungkan
konsep tradisional dimana di setiap
sprint
selalu
ada
penggalian
kebutuhan,
tidak
sesuai
dalam
pengembangan SSN
4.4. Metodologi Best Practice untuk Pengembangan SSN
Jenis Metodologi
Jumlah Kesesuaian Jumlah poin
pembanding
Presentase
Ketidaksesuaian
eXtreme
Programming
15
17
88.23 %
Feature Driven
Development
10
14
71.42 %
Scrum
5
9
55.55 %
eXtreme Programming (XP) memiliki
presentase kesesuaian paling besar, berarti
SSN cenderung menerapkan metodologi XP
35
4.5.
Penyesuaian Metodologi eXtreme Programming (XP)
4.5.1.
Penyesuaian fase eksekusi fase pengembangan proyek dengan fase
metodologi XP
1. Penyesuaian ini dilakukan untuk mengetahui fase – fase pada XP
yang masuk dalam ruang lingkup pengerjaan tugas akhir, yaitu
penggalian kebutuhan, desain, koding, dan uji coba.
37
4.5.1.
Pemetaan fase eksekusi proyek pengembangan perangkat lunak dengan
fase pada metodologi XP
Fase Eksekusi Fase XP
Penggalian Kebutuhan
Pada fase ini dilakukan penggalian kebutuhan pengguna, yang mencakup kebutuhan fungsional dan non-fungsional
Eksplorasi
Fase dimana klien menuliskan stori yang diharapkan dari perangkat lunak. Setiap stori menggambarkan fitur yang akan ditambahkan dalam perangkat lunak
-
Perencanaan
Tahap memprioritaskan fitur dan mengestimasi usaha sertajadwal pengerjaan tiap fitur Desain
Fase perencanaan bagaimana perangkat lunak akan diprogram (kode), diimplementasikan, diverifikasi, dan dirilis. Biasanya terdapat 2 tingkat, yaitu high level design (seperti pembuatan use case dan activity diagram) dan low level design yang mengarah ke pemrograman (class dan sequence diagram)
3. Fase Iterasi
• Analisis dan Desain
Proses dimana desain perangkat lunak dan sistem dibuat dalam bentuk yang sederhana sehingga mempermudah pengkodean.
• Koding
Proses penerjemahan desain ke dalam kode pemrograman. • Perencanaan Uji Coba
Proses merencanakan uji coba perangkat lunak agar bisa dilaksanakan dengan baik.
• Uji Coba
Fase untuk memastikan apakah aplikasi yang telah dibangun memenuhi kebutuhan fungsional dan non fungsional
Koding
Fase penerjemahan desain ke dalam kode – kode pemrograman
Uji Coba
Fase untuk memastikan apakah aplikasi yang telah dibangun memenuhi kebutuhan fungsional dan non fungsional
4.5.2. Penyesuaian standar IEEE 730-2002 dengan fase metodologi XP untuk
menentukan tugas dan aktivitas penjaminan kualitas SSN
Tugas penjaminan kualitas (IEEE 730-2002)
Fase pada XP Tugas penjaminan kualitas SSN (sebagai hasil penyesuaian)
Keterangan
Evaluasi penggalian kebutuhan sistem
Evaluasi ini dilakukan untuk memeriksa sejak dini apakah proses penggalian kebutuhan sistem telah dilakukan dengan baik.
Fase eksplorasi
Fase dimana klien menuliskan kebutuhan / stori yang diharapkan dari perangkat lunak. Setiap stori menggambarkan fitur yang akan ditambahkan dalam perangkat lunak
Evaluasi penggalian kebutuhan sistem
Evaluasi ini dilakukan untuk memeriksa sejak dini apakah proses penggalian kebutuhan sistem telah dilakukan dengan baik sehingga mampu merekam kebutuhan sistem untuk menunjang implementasi SSN pada klien / penguna nantinya
Tugas Evaluasi penggalian kebutuhan sistem pada IEEE 730-2002 dan SSN sama.
Evaluasi penggalian kebutuhan perangkat lunak
Evaluasi ini dilakukan untuk memeriksa sejak dini apakah proses penggalian kebutuhan perangkat lunak telah dilakukan dengan baik sehingga mampu merekam kebutuhan klien / pengguna nantinya
Evaluasi penggalian kebutuhan perangkat lunak
Evaluasi ini dilakukan untuk memeriksa sejak dini apakah proses penggalian kebutuhan perangkat lunak telah dilakukan dengan baik sehingga mampu merekam kebutuhan klien / pengguna SSN nantinya.
Tugas Evaluasi penggalian kebutuhan perangkat lunak pada IEEE 730-2002 dan SSN sama.
- Fase perencanaan
Tahap memprioritaskan fitur dan mengestimasi usaha serta jadwal pengerjaan tiap fitur
Evaluasi Fase Perencanaan
Evaluasi fase perencanaan dilakukan untuk memeriksa apakah prioritasisasi fitur serta estimasi sumberdaya yang meliputi waktu dan penanggungjawab telah dilakukan dengan baik
Di dalam IEEE 730-2002, fase perencanaan tidak disebutkan, sehingga khusus untuk fase tersebut, tugas penjaminan kualitas didasarkan pada definisi fase perencanaan pada XP.
39
4.5.2. Penyesuaian standar penjaminan kualitas yang berkaitan dengan IEEE
730-2002
Lihat lebih lengkap pada Lampiran D
Proses Pengembangan SSN (sesuai konsep XP) Tugas Penjaminan Kualitas SSN (berdasarkan hasil penyesuaian IEEE 730-2002 dengan metodologi XP) Aktivitas Penjaminan Kualitas SSN (berdasarkan hasil penyesuaian IEEE 730-2002 dengan metodologi XP)
Masukan dan Keluaran Standar Terkait
Fase Eksplorasi Evaluasi Penggalian Kebutuhan Sistem
Verifikasi bahwa partisipan yang berhak telah terlibat dalam penentuan kebutuhan sistem
Masukan :
Matrix
Pertanggungjawaban
System & Software Spesification (ISO IEC 12207 & IEEE 12207-2008): Lampiran A Matrix Pertanggungjawaban Keluaran : System Requirements Analysis Process Audit Checklist
Figure B-3. IEEE Std 730-2002
4.6. Dokumen Penjaminan Kualitas Pengembangan Perangkat Lunak SSN
Dokumen Utama
[PANDUAN-001] Penjaminan Kualitas
Pengembangan Aplikasi School Social Network
(PKPA-SSN)
Mengadaptasi standar IEEE 730-2002, namun
dimodifikasi sesuai kebutuhan dan ruang lingkup
tugas akhir
41
4.6. Dokumen Penjaminan Kualitas Pengembangan Perangkat Lunak SSN
Dokumen Pendukung
Dokumen Pendukung
Deskripsi Kode Dokumen
Prosedur Prosedur adalah dokumen yang berisi langkah – langkah
yang seragam untuk menjalankan tiap aktivitas penjaminan kualitas pengembangan perangkat lunak
[PR-ab Rcd] Nama Dokumen Prosedur PR : Prosedur ab : Nomor Prosedur R : Revisi cd : Nomor Revisi
Kebijakan Dokumen kebijakan merupakan dokumen yang berisi
kebijakan untuk melakukan aktivitas yang dijelaskan di dalam prosedur (berdasarkan konsep metodologi XP)
[KE-ab Rcd] Nama Dokumen Kebijakan KE : Kebijakan ab : Nomor Kebijakan R : Revisi cd : Nomor Revisi
4.6. Dokumen Penjaminan Kualitas Pengembangan Perangkat Lunak SSN
Dokumen
Pendukung
Deskripsi Kode Dokumen
Checklist Cecklist merupakan dokumen yang digunakan untuk
memastikan apakah aktivitas yang dijelaskan pada prosedur telah terpenuhi
[CH-ab Rcd] Nama Dokumen Checklist CH : Checklist ab : Nomor Checklist R : Revisi cd : Nomor Revisi
Formulir Formulir merupakan alat bantu yang mendukung
tercapainya langkah – langkah aktivitas. Misalnya untuk melakukan diskusi diperlukan bahan – bahan diskusi itu sendiri. Formulir mendeskripsikan bahan – bahan tersebut sehingga memudahkan proses diskusi
[FM-ab Rcd] Nama Dokumen Formulir FM : Formulir ab : Nomor Formulir R : Revisi cd : Nomor Revisi
43
4.6. Dokumen Penjaminan Kualitas Pengembangan Perangkat Lunak SSN
Dokumen Pendukung
Deskripsi Kode Dokumen
Instruksi Instruksi merupakan dokumen yang berisi perintah
untuk menjalankan langkah pada prosedur dan secara khusus ditujukan pada salah satu elemen pengembangan SSN dan mengandung perintah yang spesifik.
[IN-ab Rcd] Nama Dokumen Instruksi CH : Instruksi ab : Nomor Instruksi R : Revisi cd : Nomor Revisi
Template Contoh – contoh dokumen yang menjadi masukan dari
aktivitas penjaminan kualitas perangkat lunak. Dokumen tersebut adalah dokumen yang mengikuti standar penjaminan kualitas seperti yang dijelaskan dalam tabel 4.8 dan juga bagian 4.2.1. Standar IEEE lainnya pada buku tugas akhir ini
[TE-ab Rcd] Nama Dokumen Template TE : Template ab : Nomor Template R : Revisi cd : Nomor Revisi
4.7. Evaluasi Dokumen Penjaminan Kualitas
Pengembangan Perangkat Lunak SSN
45
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
standar penjaminan kualitas
Evaluasi ini dilakukan untuk
memeriksa
apakah
dokumen
penjaminan
kualitas pengembangan aplikasi SSN yang telah dibuat dalam tugas akhir ini
telah
memenuhi tugas dan aktivitas penjaminan kualitas
SSN (yang sudah disesuaikan dengan
standar IEEE 730-2002
dan
metodologi XP) serta standar lainnya yang terkait
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
standar penjaminan kualitas (1)
Proses Pengembangan SSN (dengan XP) Tugas Penjaminan Kualitas SSN (berdasarkan hasil penyesuaian IEEE 730-2002 dengan metodologi XP) Aktivitas Penjaminan Kualitas SSN (berdasarkan hasil penyesuaian IEEE 730-2002 dengan metodologi XP)
Masukan &Keluaran Standar Penjaminan Kualitas Terkait
Dokumen Penjaminan Kualitas Pengembangan SSN
Fase Eksplorasi Evaluasi Fase Eksplorasi Evaluasi Penggalian Kebutuhan Perangkat Lunak Kebijakan : [KE-02 R00] Penggalian Kebutuhan Sistem Prosedur : [PR-02 R00] Prosedur Evaluasi Penggalian Kebutuhan Perangkat Lunak SSN Verifikasi bahwa kebutuhan perangkat lunak didefinisikan dan didokumentasika n sesuai dengan prosedur Masukan :
Stori Kebutuhan Fungsional System & Software Spesification (ISO IEC 12207
& IEEE 12207-2008)
Formulir :
[FM-01 R00] Stori Kebutuhan Fungsional SSN
Keluaran :
System Requirements Analysis Process Audit Checklist
Figure B-3. IEEE Std 730-2002 Checklist : [CH-01 R00] Checklist Evaluasi Penggalian Kebutuhan Sistem SSN
Lihat Lampiran E Evaluasi Pemenuhan Standar IEEE 730-2002 dalam Dokumen Penjaminan Kualitas Pengembangan Aplikasi SSN
Tugas terpenuhi
47
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
standar penjaminan kualitas (2)
Kondisi Ideal :
Untuk menjamin kualitas pengembangan aplikasi SSN berdasarkan standar IEEE
730-2002, diperlukan
pemenuhan pada seluruh tugas dan aktivitas
penjaminan kualitas
(berdasarkan standar IEEE 730-2002) dalam dokumen
penjaminan kualitas pengembangan aplikasi SSN
Hasil :
Dari tabel yang terdapat pada
Lampiran E
dapat diketahui bahwa
seluruh tugas
dan aktivitas telah dipenuhi (100%)
dalam dokumen penjaminan
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
praktik penjaminan kualitas XP
Evaluasi ini dilakukan untuk
memeriksa
apakah
dokumen
penjaminan
kualitas pengembangan aplikasi SSN yang telah dibuat dalam tugas akhir ini
telah
memenuhi praktik penjaminan kualitas pada
49
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
standar penjaminan kualitas (1)
Lihat Lampiran G Evaluasi Pemenuhan Standar IEEE 730-2002 dalam Dokumen Penjaminan Kualitas Pengembangan Aplikasi SSN
Praktik Penjaminan Kualitas XP menurut Beck (2009)
Status Keterangan Dokumen Penjaminan Kualitas terkait
1 Perencanaan (Planning) Diterapkan Praktik perencanaan diterapkan pada fase perencanaan SSN melalui :
Ketentuan tugas dan aktivitas penjaminan kualitas fase perencanaan SSN pada dokumen PKPA-SSN bagian 3.2.3.2
[PA-01 R00] Penjaminan Kualitas Pengembangan Aplikasi School Social Network (PKPA-SSN)
Kebijakan fase perencanaan SSN [KE-02 R00] Fase Perencanaan SSN
Prosedur masukan dan evaluasi fase perencanaan SSN
[PR-03 R00] Prosedur Evaluasi Fase Perencanaan SSN
Checklist untuk memeriksa pemenuhan prosedur perencanaan yang harus dilakukan
[CH-03 R00] Evaluasi Fase Perencanaan SSN
Formulir untuk melakukan perencanaan fitur, waktu dan penanggung jawab.pengerjaanya.
[FM-05 R00] Fase Perencanaan SSN
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
standar penjaminan kualitas (2)
Kondisi Ideal :
Untuk menjamin kualitas pengembangan aplikasi SSN yang mengadaptasi
metodologi XP, diperlukan penerapan 11 praktik penjaminan kualitas XP (dijelaskan
dalam buku tugas akhir poin 4.2.2.1.3)
Hasil :
1. 91%
(10 dari 11) praktik penjaminan kualitas XP diterapkan.
2. Praktik penjaminan kualitas XP yang tidak diterapkan pada pengembangan SSN adalah
40-hours-week (
Lampiran F
)
3. 100%
praktik penjaminan kualitas XP (yang diterapkan) telah terpenuhi dalam dokumen
penjaminan kualitas pengembangan aplikasi SSN (
Lampiran F
)
51
4.7.1. Evaluasi
dokumen
penjaminan kualitas pengembangan aplikasi SSN
terhadap
standar penjaminan kualitas (2)
Praktik Penjaminan Kualitas XP menurut Beck (2009)
Status Keterangan Dokumen Penjaminan Kualitas terkait
9 40 jam kerja (40-hour
week)
Tidak diterapkan
Praktik 40 jam kerja tidak diterapkan karena sangat bergantung pada kondisi programmer, baik dalam hal mengalokasikan waktu untuk pengerjaan fitur, menangani perubahan kebutuhan atau respon kesalahan kode fitur dari klien, maupun untuk waktu di luar pengerjaan aplikasi SSN (misalkan kuliah, bekerja, dan lain sebagainya), sehingga jumlah maksimal kerja dalam satu minggu menjadi tidak dapat ditentukan di awal, dampak penerapannya pun tidak terlalu signifikan untuk pengembangan SSN.
Untuk membuat dokumen penjaminan kualitas pengembangan aplikasi SSN
berdasarkan standar IEEE 730-2002 diperlukan proses sebagai berikut :
1. Menentukan metodologi best practice
untuk pengembangan SSN yang
sedang berjalan. Dalam studi kasus pengembangan SSN ini metodologi best
practice yang sesuai adalah XP.
2. Menyesuaikan tugas dan aktivitas penjaminan kualitas
pada standar
penjaminan kualitas utama (IEEE 730-2002) dengan metodologi best practice
(dalam tugas akhir ini adalah metodologi XP).
3. Menentukan kebutuhan masukan dan keluaran tiap aktivitas
penjaminan kualitas serta mencari standar penjaminan kualitas yang
mendukungnya (dalam tugas akhir ini standar yang mendukung adalah IEEE Std.
829-1998 System & Software Test Documentation dan ISO IEC 12207-2008/IEEE
12207-2008).
4. Membuat infrastruktur
penjaminan kualitas perangkat lunak yang berupa
dokumen.
5. Mengevaluasi pemenuhan
standar penjaminan kualitas dan metodologi best
practice pengembangan perangkat lunak (dalam tugas akhir ini adalah
metodologi XP) dalam dokumen penjaminan kualitas pengembangan aplikasi
SSN.
53
Untuk membuat dokumen penjaminan kualitas pengembangan aplikasi SSN
berdasarkan standar IEEE 730-2002 diperlukan proses sebagai berikut :
1. Menentukan metodologi best practice
untuk pengembangan SSN yang
sedang berjalan. Dalam studi kasus pengembangan SSN ini metodologi best
practice yang sesuai adalah XP.
2. Menyesuaikan tugas dan aktivitas penjaminan kualitas
pada standar
penjaminan kualitas utama (IEEE 730-2002) dengan metodologi best practice
(dalam tugas akhir ini adalah metodologi XP).
3. Menentukan kebutuhan masukan dan keluaran tiap aktivitas
penjaminan kualitas serta mencari standar penjaminan kualitas yang
mendukungnya (dalam tugas akhir ini standar yang mendukung adalah IEEE Std.
829-1998 System & Software Test Documentation dan ISO IEC 12207-2008/IEEE
12207-2008).
4. Membuat infrastruktur
penjaminan kualitas perangkat lunak yang berupa
dokumen.
5. Mengevaluasi pemenuhan
standar penjaminan kualitas dan metodologi best
practice pengembangan perangkat lunak (dalam tugas akhir ini adalah
metodologi XP) dalam dokumen penjaminan kualitas pengembangan aplikasi
SSN.
55
