presentasi sidang akhir -...

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


FITUR SSN

Fitur Siswa Fitur Orang Tua

16


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


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



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



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


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


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


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


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


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


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


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.


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


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.

../Buku_TA_Lengkap.docx

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

../Lampiran/Lampiran D - Keterkaitan IEEE 730-2002 dengan Standar Penjaminan Kualitas Lainnya.docx

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

Buku_TA_Lengkap2.docx

41


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


Dokumen

Pendukung


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


Dokumen

Pendukung


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

../Lampiran/Lampiran E - Evaluasi Pemenuhan Tugas & Aktivitas Penjaminan Kualitas oleh Infrastruktur Penjaminan Kualitas .docx

47


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.

Lampiran/Lampiran E - Evaluasi Pemenuhan Tugas & Aktivitas Penjaminan Kualitas oleh Infrastruktur Penjaminan Kualitas .docx



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


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

../Lampiran/Lampiran G - Evaluasi Dokumen Penjaminan Kualitas Pengembangan Aplikasi SSN terhadap Metodologi XP.docx

50


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)

Lampiran/Lampiran F - Evaluasi Dokumen Penjaminan Kualitas Pengembangan Aplikasi SSN terhadap Metodologi XP.docx






51


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.

presentasi sidang akhir -...

Documents