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)
1
2
BAB I PENDAHULUAN
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
4
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
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 standar
penjaminan kualitas dengan metodologi yang sesuai sehingga membantu pihak pengembang dalam memenuhi kualitas SSN yang dijanjikan kepada pelanggan?
3
• 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
BATASAN
• 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.
6
TUJUAN
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
Bagi Sekolah sebagai Klien
8
DASAR TEORI
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
Komponen
10
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.
Tujuan Penjaminan Kualitas
11
SOFTWARE QUALITY ASSURANCE
Sumber : Galin, D. (2004). Software Quality Assurance From Theory to Implementation. London: Pearson Addison Wesley.
Arsitektur Penjaminan Kualitas Perangkat Lunak
12
METODOLOGI PENGEMBANGAN PERANGKAT LUNAK
Strategi tertentu terkait proses – proses yang harus dilakukan untuk membangun suatu perangkat lunak yang berkualitas berdasarkan beberapa faktor :
Waktu Biaya
Sumber daya Kualitas
Jenis Metodologi Pengembangan Perangkat Lunak menurut M.A
Awad (2005)
Traditional
Agile
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 • Analisa penyebab utama tidak terpenuhinya kebutuhan
14
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 Fitur Orang Tua
16
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
BAB III METODE PENGERJAAN TUGAS AKHIR
18
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
STUDI LAPANGAN
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
20
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
Requirement Specification)
21
4.2. Metodologi Best Practice Pengembangan Perangkat Lunak
Tradisional (M. A. Awad (2005))
Waterfall
Prototyping Model
22
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.
24
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
AGILE
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.
ABRAHAMSSON, Pekka et al., 2002
26
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
mendukung.
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.
28
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
3 Scrum
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.
30
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 sistem Tester Deployer Technical writer
Terdapat 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.
32
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
34
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) dan Standar Penjaminan Kualitas SSN
36
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.
2. Penyesuaian dilakukan berdasarkan aktivitas kunci
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 serta
jadwal 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
38
4.5.2. Penyesuaian standar IEEE 730-2002 dengan fase metodologi XP untuk menentukan tugas dan aktivitas penjaminan kualitas SSN
Lihat lebih lengkap pada buku Tugas Akhir poin 4.5.2
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
40
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
>> Tabel 4.10 Perbandingan Struktur IEEE 730-2002 dengan PKPA-SSN
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
42
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
44
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
46
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
Aktivitas 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
kualitas pengembangan SSN.
48
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 metodologi XP
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
Praktik “perencanaan” terpenuhi
50
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.
-
52
BAB V PENUTUP
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
KESIMPULAN
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.
54
KESIMPULAN
55
KESIMPULAN (2)
• Tidak semua praktik penjaminan kualitas pada XP dapat diterapkan dalam pengembangan SSN, hal tersebut karena perlunya penyesuaian dengan proses eksisting pengembangan SSN. Praktik penjaminan kualitas dalam XP yang tidak dapat
diterapkan pada pengembangan SSN adalah 40 hours per week karena kondisi tim
pengembang dan permintaan dari klien yang tidak memungkinkan pembangunan SSN untuk dikerjakan dalam waktu maksimal 40 jam per minggu. Selain itu karena fokus pengerjaan fitur aplikasi bukan berdasarkan maksimal kerja per minggu melainkan batas akhir penyelesaian fitur.
• IEEE 730-2002 tidak menyediakan panduan yang lengkap untuk proses penyesuaian tugas dan aktivitas penjaminan kualitas dengan metodologi XP, sehingga dalam tugas akhir ini dilakukan observasi lebih lanjut.
Observasi dilakukan dengan memetakan fase pada metodologi XP dengan tugas dan aktivitas penjamian kualitas yang dijelaskan pda IEEE 730-2002 berdasarkan definisi tiap fase XP, tugas dan aktivitas penjaminan kualitas.
56
SARAN
Karena aplikasi SSN akan dikembangkan menjadi aplikasi jejaring sosial yang tidak hanya dapat digunakan oleh Yayasan Pendidikan Al Azhar, melainkan untuk dikomersialkan kepada semua sekolah tingkat TK, SD, SMP, dan SMA sederajat, maka saran untuk pengembangan SSN selanjutnya adalah sebagai berikut:
1. Dokumen penjaminan kualitas pengembangan SSN yang telah dibuat dalam
tugas akhir ini perlu disesuaikan juga dengan kebijakan dan peraturan masing – masing sekolah.
2. Mengkombinasikan teknik penggalian kebutuhan pada XP (yang sebelumnya
merekam stories dari pengguna dengan skenario) dengan prototyping.
Top Related