Tugas Kelompok Testing Dan Implementasi Sistem Rekayasa Software Berorientasi Objek
OLEH: I WAYAN ANTARA JAYA
(13101168)
HARIS ZAIN
(13101122)
I PUTU GEDE SUGIANTARA
(13101124)
MEGA ARDINATA
(13101300)
I GEDE ADI CAHYADI
(13101049)
STIKI INDONESIA Jl. Tukad Pakerisan 97 Denpasar, Bali, Indonesia Tel. 0361 - 256 995 2015/2016 i
KATA PENGANTAR Om Swastyastu, Puji syukur dipanjatkan kepada Ida Sang Hyang Widhi Wasa, Tuhan Yang Maha Esa atas karunia-Nya penulis bisa menyelesaikan Makalah ini. Makalah ini merupakan Tugas Kelompok untuk penilaian UAS, yang diberikan oleh dosen mata kuliah Testing dan Implementasi Sistem, sebagai salah satu bentuk penilaian dosen kepada mahasiswa. Makalah ini berjudul Rekayasa Software Berorientasi Objek. Tujuan dari
menyelesaikan
makalah
ini
adalah
untuk
mendapatkan nilai UAS yang maksimal dan melatih belajar secara berkelompok, sebagai syarat untuk menyelesaikan mata kuliah Testing dan Implementasi Sistem ini. Penulis menyadari bahwa penyajian dan penulisan makalah ini masih jauh dari kata sempurna, dan banyak kekurangan. Oleh karena itu kritik dan saran yang bersifat membangun dalam penyusunan makalah ini penulis harapkan.
ii
Akhir kata penulis berharap penulisan dan penyusunan makalah ini dapat memberikan manfaat bagi pembacanya. Om Santih, Santih, Santih, Om. Denpasar, 14 Mei 2016
Penulis
iii
DAFTAR ISI
Halaman HALAMAN JUDUL................................................. i KATA PENGANTAR............................................... ii DAFTAR ISI.............................................................
iv
BAB I PENDAHULUAN 1.1 Latar Belakang......................................... 1 1.2 Rumusan Masalah.................................... 3 1.3 Tujuan dan Manfaat.................................
3
1.4 Metode Penulisan..................................... 4
BAB II PEMBAHASAN 2.1 Pengertian Rekayasa ddddddddSoftware.................................................. 2.2 Pengertian Object Oriented.....................
.... 5 5
.... 2.3 Pengertian Rekayasa Software ................Berorientasi Objek................................... 6 iv
2.4 Prosedur-Prosedur Pengujian Software... 7 2.4.1 Pendekatan Strategi Kepengujian .........Perangkat Lunak.................................
.... 8
2.4.2 Masalah-Masalah .........Strategis...............................................
.... 11
2.4.3 Pengujian Unit.....................................
13
2.4.4 Pengujian Integrasi..............................
14
2.4.5 Pengujian Validasi..............................
16
2.4.3 Pengujian Sistem.................................
18
BAB III PENUTUP 3.1 Simpulan................................................ 20 3.2 Saran......................................................
21
DAFTAR PUSTAKA...............................................
22
v
BAB I PENDAHULUAN 1.1 Latar Belakang Istilah Rekayasa Perangkat Lunak (RPL) secara umum
disepakati
sebagai
terjemahan
dari
istilah
Software Engineering. Istilah Software Engineering mulai
dipopulerkan
tahun
1968
pada
Software
Engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer. Perangkat lunak adalah
seluruh
perintah
yang
digunakan
untuk
memproses informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien, 1999). Pengertian RPL sendiri adalah sebagai berikut: Suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, 1
mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas, mempunyai arti semua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL. Secara lebih khusus kita dapat menyatakan tujuan RPL adalah sebagai berikut: 1..Memperoleh biaya produksi perangkat lunak yang ....rendah. 2..Menghasilkan perangkat lunak yang kinerjanya tinggi, ....handal dan tepat waktu. 3..Menghasilkan perangkat lunak yang dapat bekerja ....pada berbagai jenis platform. 4..Menghasilkan
perangkat
....perawatannya rendah. 2
lunak
yang
biaya
1.2 Rumusan Masalah 1.
Apa itu rekayasa software berorientasi objeck ?
2.
Apa saja prosedur pengujian perangkat lunak ?
3.
Apa yang dimaksud dengan pengujian integrasi ?
1.3 Tujuan dan Manfaat Tujuan disusunnya makalah ini adalah : 1. Menjelaskan mengenai rekayasa software berorientasi ....objeck. 2..Menjelaskan mengenai prosedur-prosedur pengujian ....perangkat lunak dan pengujian integrasi. Manfaat disusunnya makalah ini adalah : 1..Setelah
mengetahui
informasi
tentang
rekayasa
software berorientasi objek, prosedur pengujian dan pengujian integrasi perangkat lunak, maka developer atau pengembang dapat menghasilkan perangkat lunak yang kinerjanya tinggi, handal dan tepat waktu, menghasilkan perangkat lunak yang biaya perawatannya rendah.
3
1.4 Metode Penulisan 1. Studi Pustaka. 2..Mencari informasi melalui buku tentang rekayasa ....software berorientasi objek. 3..Jurnal dan internet mengenai rekayasa software ....berorientasi objek.
4
BAB II PEMBAHASAN 2.1 Pengertian Rekayasa Software Rekayasa Perangkat Lunak atau Rekayasa Software adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan
menggunakan
prinsip
reakayasa
untuk
menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna. 2.2
Pengertian Object Oriented OOP (Object Oriented Programming) adalah suatu
metode pemrograman yang berorientasi kepada objek. Tujuan dari OOP diciptakan adalah untuk mempermudah pengembangan program dengan cara mengikuti model yang telah ada di kehidupan sehari-hari. Jadi setiap bagian dari suatu permasalahan adalah objek, nah objek itu sendiri merupakan gabungan dari beberapa objek yang lebih kecil lagi. Saya ambil contoh Pesawat, Pesawat adalah sebuah objek. Pesawat itu sendiri 5
terbentuk dari beberapa objek yang lebih kecil lagi seperti mesin, roda, baling-baling, kursi, dll. Pesawat sebagai objek yang terbentuk dari objek-objek yang lebih kecil saling berhubungan, berinteraksi, berkomunikasi dan saling mengirim pesan kepada objek-objek yang lainnya. Begitu juga dengan program, sebuah objek yang besar dibentuk dari beberapa objek yang lebih kecil, objek-objek itu saling berkomunikasi, dan saling berkirim pesan kepada objek yang lain. 2.3
Pengertian Rekayasan Software Berorientasi
Objek. Sebuah sistem yang dibangun dengan berdasarkan motode berorientasi objek adalah sebuah sistem yang komponennya
dibungkus
(dienkapsulasi)
menjadi
kelompok data dan fungsi. Setiap komponen dalam sistem tersebut dapat mewarisi atribut dan sifat dari komponen lainnya, dan dapat berinteraksi satu sama lainnya.
6
2.4 Prosedur-Prosedur Pengujian Software Dalam strategi pengujian perangkat lunak dapat digambarkan dengan ilustrasi berikut: Sebuah perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian prose dilanjutkan ke dalam bentuk rancangan, dan akhirnya kepengkodean. Strategi pengujian serupa dengan hal tersebut, dimulai dengan unit testing di pusat spiral di mana masing-masing modul/unit dari perangkat lunak yang diimplementasikan dalam source code menjadi
sasaran
pengujian.
Kemudian
dilakukan
integration testing dengan focus pengujian adalah desain dan kontruksi arsitektur perangkat lunak. Selanjutnya dilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system testing, dimana perangkat lunakdan keseluruhan sistem diuji.
7
2.4.1 Pendekatan
Strategis
ke
Pengujian
Perangkat lunak. Pengujian merupakan rangkaian aktivitas yang dapat direncanakan sebelumnya dan dilakukan secara sistematis. memudahkan
Strategi para
uji
coba
perancang
perangkat untuk
lunak
menentukan
keberhasilan system yang telah dikerjakan. Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yang diperlukan. Strategi uji coba mempunyai karakteristik adalah sebagai berikut : 1.
Pengujian mulai pada tingkat modul yang paling bawah, dilanjutkan dengan modul di atasnya kemudian hasilnya dipadukan.
2.
Teknik
pengujian
yang
berbeda
mungkin
menghasilakn sedikit perbedaan (dalam hal waktu). 3.
Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen.
8
4.
Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian.
Verifikasi dan validasi Verifikasi dan validasi merupakan dua istilah yang sering dikaitkan dengan tahapan pengujian perangkat lunak.Verifikasi mengacu pada serangkaian aktivitas untuk
memastikan
bahwa
perangkatl
unak
mengimplementasikan fungsi tertentu secara benar, sedangkan validasi mengacu pada serangkaian aktivitas untuk memastikan bahwa perangkat lunak yang telah dibuat sesuai denga kebutuhan konsumen. Definisi V&V mencakup serangkaian aktivitas dari penjaminan kualitas perangkat lunak (SQA) yang meliputi kajian teknis formal, audit kualitas dan control, monitoring kinerja,simulasi, studi feasibilitas, kajian dokumentasi,
kajian
basisdata,
analisis
algoritma,
pengujian pengembangan, pengujian kualifikasi, dan pengujianinstalasi.
9
Pengorganisasian Pengujian Perangkat Lunak Proses pengujian sebuah perangkat lunak sebaiknya melibatkan
pihak
yang
memang
secara
khusus
bertanggung jawab untuk melakukan proses pengujian secara independen. Untuk itulah diperlukan Independent Test Group (ITG). Peran dari ITG adalah untuk menghilangkan“conflict of interest” yang terjadi ketika pengembang perangkat lunak berusaha untuk menguji produknya sendiri. Walaupun seperti itu, sering terjadi beberapa kesalahan pemahaman berkaitan dengan peran ITG, antara lain: 1.
Pengembang tidak boleh melakukan pengujian sama sekali. Pendapat ini tidak 100% benar,Karena dalam banyak kasus, pengembang juga melakukan proses unit testing dan integration test.
2.
Perangkat lunak dilempar begitu saja untuk diuji secara sporadic. Hal tersebut adalah salah karena pengemmbang dan ITG bekerja sama pada kesalahan proyek untuk memastikan pengujian akan dilakukan. Sementara pengujian dilakukan, pengembang harrus memperbaiki kesalahan yang ditemukan. 10
3.
Pengujitidak terlibat pada proyek sampai tahap pengujian dimulai. Hal tersebut salahkarena ITG merupakan bagian dari tim proyek pengembangan perangkat
lunak
dimanaia
spesifikasi
proses
dan
terlihat
tetap
selama
terlinat
pada
keseluruhanproyek besar.
2.4.2 Masalah-Masalah Strategis Masalah-masalah berikut harus diselesaikan bila pengujian ingin berlangsung sukses: 1.
Menspesifikasikan
kebutuhan
produk
pada
kelakuan yang terukur sebelum pengujian dimulai. Strategi pengujian yang baik tidak hanya untuk menenmukan kesalahan, namun juga unutk menilai kualitas program. 2.
Menspesifikasikan eksperangkat
tujuan
lunakisit.
pengujian
Sasaran
spesifik
secara dari
pengujian harus dinyatakan dalam bentuk yang terukur. 3.
Mengidentifikasikan kategori user untuk perangkat lunak dan membuat profilnya masing-masing. Beberapa kasus yang menggambarkan scenario 11
interaksi
bagi
masing-masing
kategori
dapat
mengurangi kerja pengujian dengan memfokuskan pengujian pada penggunaan actual produk. 4.
Membangun rencana pengujian yang menegaskan rapid cycle testing. Umpan balik yang muncul dari rapid
cycle
testing
dapat
digunakan
untuk
mengontrol kualitas dan strategi pengujian yang sesuai. 5.
Membangun perangkat lunak yang tangguh yang dirancang untuk menguji dirinya sendiri. Perangkat lunak dapat mendiagnosis jenis-jenis kesalahan tertentu dan mengakomodasi pengujian otomatis dan pengujian regresi.
6.
Menggunakan tinjauan formal yang efektif sebagai filter sebekum pengujian. Kajian teknis formal dapat mengungkap kesalahan seefektif pengujian sehingga dapat mengurangi jumlah kerja pengujian.
7.
Mengadakan tinjauan formal dapat mengungkap inkonsistensi, penghapusan, dan kesalahan seketika dalam pendekatan pengujian.
8.
Membangun pendekatan yang meningkat secara berkelanjutan untuk proses pengujian. Strategi 12
pengujian harus terukur. Metric yang terkumpul selama pengujian harus digunakan sebagai bagian dari pendekatan control proses statistical bagi pengujian perangkat lunak.
2.4.3 Pengujian Unit Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Ujicoba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel atau beruntun dengan modul lainnya. Pertimbangan Pengujian Unit. Interface modul diuji untuk memastikan bahwa informasi secara tepat mengalir masuk dan keluar dari inti program yang diuji. Struktur data local diuji untuk memastikan bahwa data yang tersimpan
secara
temporal
dapat
tetap
menjaga
integritasnya selama semua langkah langkah di dalam suatu algoritma dieksekusi. Kondisi batas diuji untuk memastikan bahwa modul beroperasi dengan tepat pada batas yang ditentukan untuk membatasi pemrosesan. Semua jalur independen (jalur dasar) yang melalui 13
struktur control dipakai sedikirnya satu kali. Dan akhirnya penanganan kesalan diuji. Prosedur Pengujian Unit Sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri maka driver (pengendali) dan atau sub perangkat lunak harus dikembangkan untuk pengujian unit.
2.4.4 Pengujian Integrasi Pengujian terintegrasi adalah teknik yang sistematis untuk penyusunan struktur program, pada saat dikerjakan uji coba untuk memeriksa kesalahan yang nantinya digabungkan dengan interface. Metode pengujian integrasi adalah sebagai berikut : 1. Top down integration Merupakan
pendekatan
inkremental
untuk
penyusunan struktur program. Modul dipadukan dengan bergerak ke bawah melalui kontrol hirarki dimulai dari modul utama. Modul subordinat ke modul kontrol utama 14
digabungkan ke dalam struktur baik menurut depth first atau breadth first. Proses integrasi: 1.
Modul utama digunakan sebagai test driver dan sub yang menggantikan seluruh modul yang secara langsung berada di bawah modul kontrol utama.
2.
Tergantung pada pendekatan perpaduan yang dipilih (depth / breadth).
3.
Uji coba dilakukan selama masing-masing modul dipadukan.
4.
Pada penyelesaian masing-masing uji coba sub yang lain dipindahkan dengan modul sebenarnya.
5.
Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yang mungkin muncul.
2. Buttom up integration Pengujian
buttom
up
dinyatakan
dengan
penyusunan yang dimulai dan diuji cobakan dengan atomic modul (modul tingkat paling bawah pada struktur program). Karena modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul subordinat yang 15
selalu diberikan harus ada dan diperlukan untuk sub yang akan dihilangkan. Strategi pengujian : 1.
Modul tingkat bawah digabungkan ke dalam cluster yang memperlihatkan sub fungsi perangkat lunak.
2.
Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan output.
3.
Cluster diuji
4.
Driver diganti dan cluster yang dikombinasikan dipindahkan ke atas pada struktur program.
2.4.5 Pengujian Validasi Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi terting. Pengujian validasi dikatakan berhasil bila fungsi yang ada pada perangkat lunak sesuai dengan yang diharapkan pemakai. Validasi perangkat lunak merupakan kumpulan seri uji coba black box yang menunjukkan sesuai dengan yang diperlukan. Kemungkinan kondisi setelah pengujian: 1.
Karakteristik performansi fungsi sesuai dengan spesifikasi dan dapat diterima. 16
2.
Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.
Pengujian BETA dan ALPHA Apabila PERANGKAT LUNAK dibuat untuk pelanggan maka
dapat
dilakukan
aceeptance
test
sehingga memungkinkan pelanggan untuk memvalidasi seluruh
keperluan.
Test
ini
dilakukan
karena
memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan membiasakan pelanggan memahami PERANGKAT LUNAK yang telah dibuat. Pengujian Alpha dilakukan pada sisi pengembang oleh seorang pelanggan. Perangkat Lunak digunakan pada setting yang natural dengan pengembang “yang memandang” melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian Pengujian Beta dilakukan pada satu atau lebih pelanggan oleh pemakain akhir perangkat lunak dalam lingkungan yang sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekam semua masalah (real atau imajiner) yang ditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu. 17
2.4.6 Pengujian Sistem. Pada
akhirnya
PERANGKAT
LUNAK
digabungkan dengan elemen system lainnya dan rentetan perpaduan system dan validasi tes dilakukan. Jikauji coba gagal atau di luar skope dari proses daur siklus pengembangan system, langkah yang diambil selama perancangan
dan
pengujian
dapat
diperbaiki.
Keberhasilan perpaduan PERANGKAT LUNAK dan system yang besar merupakan kuncinya. Sistem testing merupakan rentetan pengujian yang berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen system yang dikembangkan. Recovery Testing Recovery Testing adalah system testing yang memaksa PERANGKAT LUNAK mengalami kegagalan dalam bermacam-macam cara dan apakah perbaikan dilakukan dengan tepat. Security Testing Security Testing adalah pengujian yang akan melalukan verifikasi dari mekanisme perlindungan yang akan dibuat oleh system, melindungi dari hal-hal yang mungkin terjadi. 18
Strees Testing Strees Testing dirancang untuk menghadapi situasi yang tidak normal pada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yang tidak normal (melebihi atau kurang dari batasan) atau fekuensi.
19
BAB III PENUTUP 3.1 Kesimpulan Rekayasa Perangkat Lunak atau Rekayasa Software adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan
menggunakan
prinsip
reakayasa
untuk
menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna. Rekayasa perangkat lunak beroriantasi objek semuanya berkenaan dengan obje Objek adalah “ benda “ nyata yang ada di sekeliling kita baik secara fisik ataupun
konseptual.
Bagian
dalam
suatu
objek
tersembunyi dari pihak luar, Satu satunya jalan memasuki suatu objek melalui antar muka yang dimiliki objek tersebut. Kelas adalah cetak biru untuk objek sejenis.Karakteristik suatu kelas dapat diberikan kepada kelas yang lain melalui pewarisan Suatu objek dapat dibangun oleh dua atau lebih objek yang lain, proses ini disebut agregasi Secara umum 20
rekayasa perangkat lunak berorientasi objek unggul dari paradigma rekayasa perangkat lunak yang lain. Secara lebih khusus kita dapat menyatakan tujuan RPL adalah sebagai berikut: 1..Memperoleh biaya produksi perangkat lunak yang ....rendah. 2..Menghasilkan perangkat lunak yang kinerjanya tinggi, ....handal dan tepat waktu. 3..Menghasilkan perangkat lunak yang dapat bekerja ....pada berbagai jenis platform. 4..Menghasilkan
perangkat
lunak
yang
biaya
....perawatannya rendah.
3.2 Saran Dalam implementasi dan pengembangan sistem developer
harus
menerapkan
prosedur-prosedur
pengujian sistem, agar perangkat lunak yang di implementasikan mudah untuk dikembangka, sangat bermanfat bagi pengguna dan bebas dari error.
21
Daftar Pustaka Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall,2006. Jumat, 13 Mei 2016 pukul : 21:16 http://journal.uii.ac.id/index.php/Snati/article/viewFile/1493 /1274
Jumat, 13 Mei 2016 pukul : 22:04 http://www.slideshare.net/asepsuhendar/object‐oriented
Sabtu, 14 Mei 2016 pukul : 09:02 http://parno.staff.gunadarma.ac.id/Downloads/files/1368 5/RPL1_9_Pengujian_perangkat_Lunak.pdf Sabtu, 14 Mei 2016 pukul : 10:14 http://www.unsri.ac.id/upload/arsip/OOP.pdf
22
