Proses Testing
• System Testing
– Pengujian terhadap integrasi sub-system, yaitu
keterhubungan antar sub-system
• Acceptance Testing
– Pengujian terakhirs sebelum sistem dipakai oleh user.
– Melibatkan pengujian dengan data dari pengguna
sistem.
– Biasa dikenal sebagai “alpha test” (“beta test” untuk
software komersial, dimana pengujian dilakukan oleh
potensial customer)

The testing process
Component testing
􀂄 Pengujian komponen-komponen program
􀂄 Biasanya dilakukan oleh component developer
(kecuali untuk system kritis)
Integration testing
􀂄 Pengujian kelompok komponen-komponen yang
terintegrasi untuk membentuk sub-system
ataupun system
􀂄 Dialakukan oleh tim penguji yang independent
􀂄 Pengujian berdasarkan spesifikasi sistem

Rencana Pengujian
Proses testing
􀂄 Deskripsi fase-fase utama dalam pengujian
Pelacakan Kebutuhan
􀂄 Semua kebutuhan user diuji secara individu
Item yg diuji
􀂄 Menspesifikasi komponen sistem yang diuji
Jadual Testing
Prosedur Pencatatan Hasil dan Prosedur
Kebutuhan akan Hardware dan Software
Kendala-kendala
􀂄 Mis: kekuranga staff, alat, waktu dll.

Failures, Faults
Failure: output yang tidak benar/tidak sesuai
ketika sistem dijalankan
Fault: kesalahan dalam source code yang
mungkin menimbulkan failure ketika code yg
fault tsb dijalankan
Corrupting Failure yang merusak sistem data
Non-corrupting Failure tidak merusak data
Unrecoverable Sistem tidak dapat memperbaiki secara otomatis
Recoverable Sistem dapat memperbaiki secara otomatis
Permanent Muncul untuk semua input
Transient Muncul untuk input tertentu
Failure Class Deskripsi

Failures, Faults
Failure: output yang tidak benar/tidak sesuai
ketika sistem dijalankan
Fault: kesalahan dalam source code yang
mungkin menimbulkan failure ketika code yg
fault tsb dijalankan
Corrupting Failure yang merusak sistem data
Non-corrupting Failure tidak merusak data
Unrecoverable Sistem tidak dapat memperbaiki secara otomatis
Recoverable Sistem dapat memperbaiki secara otomatis
Permanent Muncul untuk semua input
Transient Muncul untuk input tertentu
Failure Class Deskripsi

Test data: Input yang yang
direncankan digunakan oleh sistem.
Test cases: Input yang digunakan
untuk menguji sistem dan memprediksi
output dari input jika sistem beroperasi
sesuai dengan spesifikasi.
Test data dan kasus test

Disebut juga white-box testing
Penentuan test case disesuaikan
dengan struktur sistem. Knowledge
program digunakan untuk
mengidentifikasi test case tambahan.
Tujuannya untuk menguji semua
statement program (debug).
Structural testing

Path testing
Tujuannya meyakinkan bahwa himpunan test
case akan menguji setiap path pada suatu
program paling sedikit satu kali.
Titik awal untuk path testing adalah suatu
program flow graph yang menunjukkan nodenode
yang menyatakan program decisions
(mis.: if-then-else condition) dan busur
menyatakan alur kontrol
Statements dengan conditions adalah nodenode
dalam flow graf.

Menggambarkan alur kontrol. Setiap cabang
ditunjukkan oleh path yg terpisah dan loop
ditunjukkan oleh arrows looping kembali ke
loop kondisi node.
Digunakan sebagai basis untuk menghitung
cyclomatic complexity
Cyclomatic complexity = Jumlah edges –
Jumlah Node +2
Cyclomatic complexity menyatakan jumlah
test untuk menguji control statements
Program flow graphs

1, 2, 3, 8, 9
1, 2, 3, 4, 6, 7, 2
1, 2, 3, 4, 5, 7, 2
1, 2, 3, 4, 6, 7, 2, 8, 9
Test cases harus ditentukan sehingga
semua path tsb tereksekusi.
Independent paths


Black-box testing
Pendekatan pengujian dimana program
dianggap sebagai suatu ‘black-box’
(‘kotak hitam’)
Program test case berbasiskan
spesifikasi
Test planning dapat dimulai sejak awal
proses pengembangan sistem

Black-box testing
• Pengujian black box berusaha
menemukan kesalahan dalam kategori :
– Fungsi-fungsi yang tidak benar atau hilang
– Kesalahan interface
– Kesalahan dalam struktur data atau akses
database eksternal
– Kesalahan kinerja
– Inisialisasi dan kesalahan terminasi

Partisi Ekivalensi (equivalensi
partition)
Input data dan output hasil terdapat di klas
yang berbeda yang sesuai dengan klas
inputnya
Masing-masing klas equivalensi partition
diprosres dimana program akan memproses
anggota klas-klas tersebut secara equivale.
Test cases dipilih dari masing-masing partisi


Contoh Analisa Kebutuhan, Pengujian Black Box, dan Pengujian White Box pada Web Aplikasi Penjualan Online “Fast & Cheap”
Posted: 28/08/2010 by celulux in Rekayasa Perangkat Lunak
11
Pengantar
Fastncheap merupakan sebuah toko yang khusus menjual Khusus barang elektronik, mulai komputer, LCD, GPS, Laptop, dan asesoris lainnya. Fastncheap juga menyediakan toko atau website secara online. Di dalam website ini terdapat beberapa kategori dimana di setiap topik diberikan penjelasan secara rinci baik spesifikasi, kelebihan dan kelemahan terhadap produk yang dikehendaki sehingga menjadi bahan pertimbangan sebelum membeli produk tersebut.
Toko Fast & Cheap telah menggunakan Sistem Web Aplikasi Penjualan Online dimana produk disana sudah bisa dibeli secara online. Sistem disini harus bisa menampilkan Informasi Penjualan Komputer pada Toko Toko Fast & Cheap (FNC) secara online yang mempunyai beberapa cabang di Indonesia
Analisa Kebutuhan Sistem
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi tentang penjualan komputer secara online
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi pelanggan yang melakukan pembelian
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi jumlah dan spesifikasi barang (Komputer) yang dijual.
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi tentang jumlah rupiah dari transaksi penjualan
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi penambahan kas dari transaksi penjualan.
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi atau laporan penjualan baik perminggu/perbulan dan pertahun.
• Dengan Menggunakan Aplikasi Penjualan Komputer secara komputerisasi Admin dapat menampilkan informasi peningkatan penjualan dari periode sebelumnya dengan periode sekarang.
Pengujian Black Box
Pada pengujian Black Box, yang pertama kami menguji form dari registrasi untuk menjadi anggota supaya bisa memberikan komentar terhadap produk yang ditampilkan pada sistem penjualan online fast & cheap.


Pada form tersebut kami menemukan beberapa kesalahan validasi yaitu sebagai berikut :
• Tab index tidak berjalan semestinya
• Kolom nama bisa dimasukkan angka & karakter
• Kolom telepon bisa dimasukkan huruf & karakter
• Tidak terdapat captcha untuk memastikan bahwa user adalah manusia
Yang kedua yaitu pengujian terhadap form New Produk


Pada form tersebut kami menemukan beberapa ketidak nyamanan pengguna yaitu :
• Ada beberapa rincian produk tidak lengkap
• Pengurutan produk tidak jelas menurut sub mana.
Yang ketiga yaitu pengujian terhadap form pencarian

 
Pada form tersebut kami menemukan kesalahan validasi dan pesan kesalahan yang belum sempurna yaitu :
• Kolom harga bisa dimasukkan huruf dan karakter
• Pesan kesalahan pada pencarian tidak sesuai dengan kenyataan (pesan kesalahan selalu “without thousand and decimal separator”)
Yang keempat yaitu pengujian terhadap form komentar


Pada form tersebut kami menemukan tidak ada validasi batas karakter yaitu :
• Isi jumlah karakter komentar tidak dibatasi, sehingga bisa memasukkan ribuan jumlah karakter.
Pengujian White Box
Seperti yang diatas, pertama-tama kami menguji form registrasi anggota


Yang kedua kami menguji form tambah komentar

screenshot:
Fungsi tombol “Close Window” setelah memberikan komentar tidak berjalan sesuai fungsinya.
Diperkirakan link yang terdapat pada Tulisan “Close Window” sama dengan link pada posting komentar sehingga halaman tidak berpindah
Yang ketiga kami menguji form shoping cart

screenshot :
Tidak terdapat validasi jumlah stok produk terhadap database sehingga bisa memasukkan angka jumlah produk yang sangat besar
Maintenance yang bisa dilakukan
• Pembersihan, pengawasan, dan pengecekan komentar yang masuk selama proses update produk
• Pengecekan kebenaran dan kecocokan database sistem terhadap produk yang ditampilakan
• Perbaikan tampilan sistem web agar lebih mudah diakses
• Pengecekan terhadap domain yang digunakan
• Pengecekan keamanan program (pembelian secara curang atau order dari Negara tertentu yang ilegal) yang digunakan sistem seiring perkembangan jaman
• Pengecekan terhadap pihak penerima pembayaran online
• Peningkatan kualitas layanan searching (pencarian)
Terlalu sering maintenance juga tidak baik karena berdampak buruk terhadap kenyamanan pelanggan
Fitur-fitur yang bisa ditambahkan
• Forum per topik, sehingga terdapat pertimbangan-pertimbangan dalam hal menentukan pilihan dalam membeli produk yangs sedang di bahas dalam forum tersebut
• Terdapat fasilitas diskon untuk member dengan ketentuan sedemikian rupa sehingga bisa memperbanyak pelanggan.
• Fitur pengganti bahasa. Sehingga pelanggan dari dalam negeri dan luar negeri bisa juga menggunakan web tersebut.
• Fitur Cetak dokumen bagi pelanggan yang ingin mencetak informasi tentang produk ataupun di forum (jika sudah ada)
• Sistem agar bisa diakses lewat mobile
• Penambahan fitur facebook, twitter, blog dsb. Untuk dapat lebih memudahkan dalam hal promosi.
NOTE :
Semua tulisan diatas dibuat dengan alasan proses pembelajaran. Data tersebut ditemukan sesuai tanggal postingan. Saya mohon maaf jika ada kata-kata yg atau tulisan yg tidak berkenan bagi semua pihak. Jika ada saran ataupun kritik silahkan komentar. Semoga tulisan ini bermanfaat bagi kawan-kawan semua ^_^



1
PENGUJIAN BLACK-BOX
Pengujian black-box berfokus pada persyaratan fungsional perangkat lunak.
Pengujian ini memungkinkan analis sistem memperoleh kumpulan kondisi
input yang akan mengerjakan seluruh keperluan fungsional program.
Tujuan metode ini mencari kesalahan pada:
 Fungsi yang salah atau hilang
 Kesalahan pada interface
 Kesalahan pada struktur data atau akses database
 Kesalahan performansi
 Kesalahan inisialisasi dan tujuan akhir
Metode ini tidak terfokus pada struktur kontrol seperti pengujian white-box
tetapi pada domain informasi.
Pengujian dirancang untuk menjawab pertanyaan sebagai berikut:
 Bagaimana validitas fungsional diuji?
 Apa kelas input yang terbaik untuk uji coba yang baik?
 Apakah sistem sangat peka terhadap nilai input tertentu?
 Bagaimana jika kelas data yang terbatas dipisahkan?
 Bagaimana volume data yang dapat ditoleransi oleh sistem?
 Bagaimana pengaruh kombinasi data terhadap pengoperasian sistem?
EQUIVALENCE PARTITIONING
Equivalence partitioning adalah metode pengujian black-box yang memecah
atau membagi domain input dari program ke dalam kelas-kelas data
sehingga test case dapat diperoleh.
Perancangan test case equivalence partitioning berdasarkan evaluasi kelas
equivalence untuk kondisi input yang menggambarkan kumpulan keadaan
yang valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai,
kumpulan nilai yang berhubungan atau kondisi Boolean.
Contoh :
Pemeliharaan data untuk aplikasi bank yang sudah diotomatisasikan.
Pemakai dapat memutar nomor telepon bank dengan menggunakan mikro
komputer yang terhubung dengan password yang telah ditentukan dan diikuti
dengan perintah-perintah. Data yang diterima adalah :
Kode area : kosong atau 3 digit
Prefix : 3 digit atau tidak diawali 0 atau 1
Suffix : 4 digit
Password : 6 digit alfanumerik
Perintah : check, deposit, dll
2
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen
dapat ditentukan sebagai berikut :
Kode area : kondisi input, Boolean – kode area mungkin ada atau tidak
kondisi input, range – nilai ditentukan antara 200 dan 999
Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1
Suffix : kondisi input nilai 4 digit
Password : kondisi input boolean – password mungkin diperlukan atau
tidak kondisi input nilai dengan 6 karakter string
Perintah : kondisi input set berisi perintah-perintah yang telah
didefinisikan
BOUNDARY VALUE ANALYSIS
Untuk permasalahan yang tidak diketahui dengan jelas cenderung
menimbulkan kesalahan pada domain outputnya. BVA merupakan pilihan test
case yang mengerjakan nilai yang telah ditentukan, dengan teknik
perancangan test case melengkapi test case equivalence partitioning yang
fokusnya pada domain input. BVA fokusnya pada domain output.
Petunjuk pengujian BVA :
1. Jika kondisi input berupa range yang dibatasi nilai a dan b, test case harus
dirancang dengan nilai a dan b.
2. Jika kondisi input ditentukan dengan sejumlah nilai, test case harus
dikembangkan dengan mengerjakan sampai batas maksimal nilai
tersebut.
3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai
jumlah maksimal.
4. Untuk struktur data pada program harus dirancang sampai batas
kemampuan.




PENGUJIAN BLACK BOX
Pengujian black box berfokus pada persyaratan fungsional perangkat lunak. Disebut juga pengujian behavioral atau pengujian partisi. Pengujian black box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian input yang sepenuhnya menggunakan semua persyaratan fungsional untuk
suatu program. Pengujian black box berusaha menemukan :
• Fungsi-fungsi yang tidak benar atau hilang
• Kesalahan interface
• Kesalahan dalam struktur data atau akses database eksternal.
• Kesalahan kinerja
• Inisialisasi dan kesalahan terminasi.
Dengan mengaplikasikan teknik black box, maka kita menarik serangkaian test case yang
memenuhi kriteria berikut :
• Test case yang mengurangi, dengan harga lebih dari satu, jumlah test case
tambahan yang harus di desain untuk mencapai pengujian yang dapat
dipertanggungjawabkan.
• Test case yang member tahu kita sesuatu mengenai kehadiran atau ketidakhadiran
kelas kesalahan, daripada member tahu kesalahan yang berhubungan hanya
dengan pengujian spesifik.
Diposkan oleh Blogqu di 05:26

20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 2
Pengujian Perangkat Lunak
􀂄 Pengujian perangkat lunak mencakup:
􀂅 Strategi
= mengintegrasikan metode perancangan kasus uji dlm sekumpulan langkah yg direncanakan
􀂅 Teknik/Metode
= perancangan kasus uji
􀂄 White-box
􀂄 Black-box
􀂄 Pengujian perangkat lunak seharusnya menghabiskan 30% - 40% dari total biaya
pembangunan perangkat lunak.
􀂄 Testing (pengujian) tidak sama dengan debugging
􀂄 Pengujian perangkat lunak merupakan salah satu tugas yang dilakukan dalam
software verification and validation
􀂄 Verifikasi dan validasi perangkat lunak adalah bagian dari software quality
assurance.


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 3
Tujuan Pengujian
􀂄 Pengujian adalah proses menjalankan program dengan maksud
untuk mencari kesalahan (error)
􀂄 Kasus uji yang baik adalah kasus yang memiliki peluang untuk
mendapatkan kesalahan yang belum ketahuan
􀂄 Pengujian dikatakan berhasil bila dapat memunculkan
kesalahan yang belum ketahuan
􀂄 Jadi, pengujian yang baik bukan untuk memastikan tidak ada
kesalahan tetapi untuk mencari sebanyak mungkin kesalahan
yang ada di program
􀂄 Pengujian tidak dapat menunjukkan ke-tidak-hadir-an defect,
pengujian hanya menunjukkan bahwa kesalahan perangkat
lunak ada.



20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 3
Tujuan Pengujian
􀂄 Pengujian adalah proses menjalankan program dengan maksud
untuk mencari kesalahan (error)
􀂄 Kasus uji yang baik adalah kasus yang memiliki peluang untuk
mendapatkan kesalahan yang belum ketahuan
􀂄 Pengujian dikatakan berhasil bila dapat memunculkan
kesalahan yang belum ketahuan
􀂄 Jadi, pengujian yang baik bukan untuk memastikan tidak ada
kesalahan tetapi untuk mencari sebanyak mungkin kesalahan
yang ada di program
􀂄 Pengujian tidak dapat menunjukkan ke-tidak-hadir-an defect,
pengujian hanya menunjukkan bahwa kesalahan perangkat
lunak ada.


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 5
Testability
􀂄 Perancangan perangkat lunak harus mempunyai kualitas:
􀂅 Operability
􀂅 Observability
􀂅 Controllability
􀂅 Decomposability
􀂅 Simplicity
􀂅 Stability
􀂅 Understandibility
􀂄 Kualitas pengujian yang baik:
􀂅 Memiliki peluang yang besar dalam menemukan kesalahan
􀂅 Tidak berganda (redundant)
􀂅 Cukup mewakili semua kemungkinan
􀂅 Tidak terlalu sederhana dan tidak terlalu rumit


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 6
Strategi Pengujian
􀂄 Pengujian Modul/Unit
􀂅 umumnya dilakukan oleh pengembang sendiri atau antar pengembang
􀂅 menguji modul/unit
􀂅 metode: white-box
􀂄 Pengujian Integrasi
􀂅 lebih baik menggunakan penguji independen (ITG = Independent Test Group)
􀂅 menguji perancangan perangkat lunak
􀂅 metode: white-box dan black-box
􀂄 Pengujian Validasi
􀂅 menguji kesesuaian dengan requirement
􀂅 metode: black-box
􀂄 Pengujian Sistem
􀂅 menguji perangkat lunak dan elemen sistem lain sebagai suatu kesatuan



20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 7
Strategi Pengujian
􀂄 Spesifikasikan kebutuhan (requirement) produk dalam bentuk yang dapat
diukur (quantifiable) jauh sebelum pengujian dimulai
􀂄 Nyatakan tujuan pengujian secara eksplisit
􀂄 Pahami pengguna perangkat lunak dan buatlah profil dari tiap kategori
pengguna
􀂄 Buat rencana pengujian yang menekankan pada rapid cycle testing
􀂄 Buat perangkat lunak robust yang dapat menguji dirinya sendiri
􀂄 Gunakan formal technical review sebagai penyaring sebelum pengujian
dilakukan
􀂄 Gunakan formal technical review untuk menilai strategi pengujian dan
kasus uji
􀂄 Kembangkan ancangan peningkatan berlanjut untuk proses pengujian


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 8
Strategi Pengujian - Pengujian
Modul/Unit
􀂄 Hal-hal yang diujikan:
􀂅 Antarmuka modul
􀂄 memastikan bahwa informasi yang berasal dari dan keluar dari modul yang diuji
mengalir dengan benar
􀂅 Struktur data lokal
􀂄 memastikan bahwa data yang disimpan sementara menjaga integritasnya selama
eksekusi perintah dalam modul
􀂄 mencari kesalahan-kesalahan dalam bentuk:
􀂅 Penggunaan tipe yang tidak tepat atau nirtaatasas
􀂅 Inisialisasi yang salah atau nilai pasti (default) yang salah
􀂅 Nama peubah yang salah
􀂅 Tipe data yang nirtaatasas
􀂅 Underflow, overflow, dan addressing exceptions
􀂅 Kondisi batas
􀂄 memastikan bahwa modul beroperasi dengan benar pada batas-batas pemrosesan
yang ditentukan


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 9
Strategi Pengujian - PengujianModul/Unit
􀂅 Jalur-jalur bebas
􀂄 memastikan bahwa semua kemungkinan jalur kontrol yang mungkin dieksekusi
dengan benar paling tidak sekali
􀂄 mencari kesalahan-kesalahan dalam bentuk:
􀂅 penghitungan/pemrosesan yang salah
􀂅 pembandingan yang salah
􀂅 alur kontrol yang tidak tepat
􀂅 Jalur-jalur penanganan kesalahan
􀂄 perancangan perangkat lunak yang baik menuntut agar kondisi salah dapat diantisipasi
dan memiliki penanganan kesalahan agar pemrosesan dapat berhenti dengan bersih
(antibugging) - Yourdon
􀂄 mencari kesalahan-kesalahan dalam bentuk:
􀂅 Perian kesalahan tidak dapat dipahami
􀂅 Pemberitahuan kesalahan tidak sesuai dengan kesalahan yang dialami
􀂅 Kondisi kesalahan menyebabkan intervensi sistem sebelum penanganan kesalahan
dilakukan
􀂅 Penanganan kesalahan tidak benar
􀂅 Perian kesalhan tidak memberikan informasi yang cukup untuk mencari sumber kesalahan

20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 11
Strategi Pengujian - Pengujian Integrasi
􀂄 Ada dua ancangan dalam pengujian integrasi secara incremental:
􀂅 Top-Down
􀂄 modul diintegrasikan dengan menurun dilihat dari hirarki kontrol, dimulai dari
modul pengendali utama (main program)
􀂄 pengintegrasian modul-modul di bawah digabungkan dengan cara:
􀂅 breadth-first
􀂅 depth-first
􀂄 proses integrasi:
Driver =
Main
Program
Modul
Subordinat Stub
Test Cases
Test Results
Stub
Regression
Test

20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 16
Strategi Pengujian - Pengujian
Sistem
􀂄 Persiapkan masalah: Saling Tuding
􀂅 Rancang penanganan kesalahan untuk semua kemungkinan masuknya
informasi dari elemen sistem di luar perangkat lunak
􀂅 Lakukan pengujian yang mensimulasikan masuknya data jelek dan salah
􀂅 Catat semua hasil pengujian untuk bukti
􀂅 Ikut andil dalam perencanaan dan perancangan pengujian sistem untuk
memastikan bahwa pengujian perangkat lunak sudah cukup
􀂄 Jenis sistem test:
􀂅 Pengujian pemulihan (recovery testing)
􀂅 Pengujian keamanan (security testing)
􀂅 Pengujian kekuatan (stress testing)
􀂅 Pengujian kinerja (performance testing)




20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 17
Teknik Pengujian -White Box
􀂄 Jenis teknik white-box:
􀂅 Basis Path Testing
􀂄 Buat Flow Graph Notation
􀂄 Hitung Cyclomatic Complexity = salah satu dari:
􀂅 Jumlah region
􀂅 V(G) = E - N + 2
􀂃 E = jumlah busur pada flow graph
􀂃 N = jumlah simpul pada flow graph
􀂅 V(G) = P + 1
􀂃 P = simpul predikat (simpul yang memiliki kondisi = 2 atau lebih busur yang
keluar)
􀂄 Tentukan jalur bebas (independent path) = jalur program yang merupakan satu
kumpulan perintah pengolahan atau satu kondisi pengolahan
􀂄 Siapkan kasus uji untuk setiap jalur bebas
􀂄 Graph Matrices = Connection Matrices = representasi lain dari FGN


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 18
Teknik Pengujian -White Box
􀂅 Control Structure Testing
􀂄 Condition Testing
􀂅 cara merancang kasus uji untuk kondisi logika yang ada pada suatu modul
program:
􀂃 kondisi sederhana = peubah boolean | ekspresi relasional
􀂃 kondisi bentukan (compound) = gabungan dari beberapa kondisi
sederhana
􀂄 Data Flow Testing
􀂅 cara menguji berdasarkan lokasi dari pendefinisian dan penggunaan suatu
peubah dalam modul program
􀂄 Loop Testing
􀂅 cara menguji berdasarkan validitas dari konstruksi pengulangan yang
digunakan dalam modul program:
􀂃 sederhana
􀂃 bercabang
􀂃 bersambung (concatenated)
􀂃 takterstruktur


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 19
Teknik Pengujian - Black Box
􀂄 Jenis pengujian black-box:
􀂅 Graph-based Testing
􀂄 geraf yang mewakili hubungan antar objek pada modul sehingga tiap objek
dan hubungannya tersebut dapat diuji
􀂅 Equivalence Partitioning
􀂄 pembagian domain masukan dari program menjadi kelas data yang dapat
dibuatkan kasus ujinya
􀂅 Boundary Value Analysis
􀂄 pemilihan kasus uji dengan mencari batas-batas ekstrim dari kelas data
􀂅 Comparison Testing
􀂄 digunakan untuk sistem yang menganut redundancy
􀂄 kasus uji yang dirancang untuk satu versi perangkat lunak dijadikan
masukan pada pengujian versi perangkat lunak lainnya
􀂄 hasil kedua versi perangkat lunak harus sama


20092006 SE6161 Perancangan dan Analisis Perangkat Lunak 20
Debugging
􀂄 Ancangan:
􀂅 Brute-force
􀂄 memory dump, run-time trace, WRITE statements
􀂅 Backtracking
􀂄 perunutan balik mulai kesalahan ketahuan hingga sampai lokasi sumber
􀂅 Cause elimination
􀂄 dengan induksi atau deduksi: isolasi kemungkinan penyebab kesalahan
􀂄 Proses:
Eksekusi Debugging
Penyebab
Diketahui
Penyebab
Dicurigai
Pengujian
Tambahan
Pengujian
Regresi
Kasus Uji
Hasil


Pendekatan Strategis ke
pengujian perangkat lunak
Pengujian Unit
Pengujian Integrasi
Pengujian Validasi
Pengujian Sistem

Pengujian Unit
Berfokus pada inti terkecil dari desain
perangkat lunak yaitu modul
Biasanya berorientasi pada white box
MMOODDUULL Interface
Struktur data lokal
Kondisi Batas
Jalur independen
Jalur penanganan kesalahan
Test Case


Pengujian Unit
Checklist untuk pengujian interface
􀂄 Apakah jumlah parameter input sama dengan
jumlah argumen?
􀂄 Apakah antara atribut dan parameter argumen
sudah cocok?
􀂄 Apakah antara sistem satuan parameter dan
argumen sudah cocok?
􀂄 Apakah jumlah argumen yang ditransmisikan ke
modul yang dipanggil sama dengan atribut
parameter?

Pengujian Unit
􀂄 Apakah atribut dari argumen yang ditransmisikan
ke modul yang dipanggil sama dengan atribut
parameter?
􀂄 Apakah sistem unit dari argumen yang
ditransmisikan ke modul yang dipanggil sama
dengan sistem satuan parameter?
􀂄 Apakah jumlah atribut dan urutan argumen ke
fungsi-fungsi built-in sudah benar?
􀂄 Adakah referensi ke parameter yang tidak sesuai
dengan poin entri yang ada?
􀂄 Apakah argumen input only diubah?

Pengujian Unit
􀂄 Apakah definisi variabel global konsisten dengan
modul ?
􀂄 Apakah batasan yang dilalui merupakan argumen?
Test case harus didesain untuk mengungkap kesalahan
dalam kategori
pengetikan yang tidak teratur dan tidak konsisten
inisialisasi yang salah atau nilai-nilai default
Nama variabel yang tidak benar
Tipe data yang tidak konsisten
Underflow, overflow dan pengecualian pengalamatan

● Dua Aspek yang dipertimbangkan:
• Apakah implementasi sudah sesuai dengan spesifikasi ?
• Apakah spesifikasi sesuai dengan kebutuhan user ?
● Validasi
• “Apakah sistem yang dikembangkan sudah benar?”
• Pengujian dimana sistem ketika diimplementasikan sesuai dengan
yang iharapkan
● Verifikasi
• “Apakah sistem dikembangkan dengan cara yang benar ?”
• Pengujian apakah sistem sudah sesuai dengan spesifikasi
Seberapa baik sistem yang
sudah dibangun ?


Integration testing
Pengujian keseluruhan system atau subsystem
yang terdiri dr komponen yg
terintegrasi.
Test integrasi menggunakan black-box
dengan test case ditentukan dari spesifikasi.
Kesulitannya adalah menemukan/melokasikan
Penggunaan Incremental integration testing
dapat mengurangi masalah tersebut.


Pendekatan integration testing
Top-down testing
􀂄 Berawal dari level-atas system dan terintegrasi
dengan mengganti masing-masing komponen
secara top-down dengan suatu stub (program
pendek yg mengenerate input ke sub-system yg
diuji).
Bottom-up testing
􀂄 Integrasi components di level hingga sistem
lengkap sudah teruji.
Pada prakteknya, kebanyakan test integrasi
menggunakan kombinasi kedua strategi
pengujian tsb.


Pendekatan Testing
Architectural validation
􀂄 Top-down integration testing lebih baik digunakan
dalam menemukan error dalam sistem arsitektur.
System demonstration
􀂄 Top-down integration testing hanya membatasi
pengujian pada awal tahap pengembangan system.
Test implementation
􀂄 Seringkali lebih mudah dengan menggunakan
bottom-up integration testing


Dilakukan kalau module-module dan subsystem
terintegrasi dan membentuk sistem
yang lebih besar
Tujuannya untuk medeteksi fault terhadap
kesalahan interface atau asumsi yg tidak valid
terntang interface tsb.
Sangat penting untuk pengujian terhadap
pengembangan sistem dgn menggunakan
pendekatan object-oriented yg didefinisikan
oleh object-objectnya
Interface testing

Pengujian perangkat lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan spesifikasi, desain dan pengkodean.

Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang merusak daripada membangun.

Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu :
A. Teknik uji coba perangkat lunak
B. Strategi uji coba perangkat lunak

TEKNIK UJI COBA PERANGKAT LUNAK

Pada dasarnya, pengujian merupakan suatu proses rekayasa perangkat lunak yg dapat dianggap (secara psikologis) sebagai hal yg destruktif daripada konstruktif.

SASARAN PENGUJIAN (Glen Myers) :

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.
2. Test case yg baik adalah test case yg memiliki probabilitas tinggi untuk menemukan kesalahan yg belum pernah ditemukan sebelumnya.
3. Pengujian yg sukses adalah pengujian yg mengungkap semua kesalahan yg belum pernah ditemukan sebelumnya.


PRINSIP PENGUJIAN (diusulkan Davis) :
1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
2. Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
3. Prinsip Pareto berlaku untuk pengujian perangkat lunak. Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yg ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua modul program.
4. Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian "yang besar".
5. Pengujian yg mendalam tidak mungkin.
6. Paling efektif, pengujian dilakukan oleh pihak ketiga yg independen.

TESTABILITAS
Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yg dapat dilakukan untuk membuatnya menjadi mudah.

Karakteristik perangkat lunak yg diuji :

* OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat diuji.
* OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji.
* KONTROLABILITAS, semakin baik kita dapat mengontrol perangkat lunak semakin banyak pengujian yg adapat diotomatisasi dan dioptimalkan.
* DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali.
* KESEDERHANAAN, semakin sedikit yg diuji semakin cepat pengujian.
* STABILITAS, semakin sedikit perubahan semakin sedikit gangguan pengujian.
* KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki semakin detail pengujiannya.

ATRIBUT PENGUJIAN YG BAIK :
* Memiliki probabilitas yg tinggi menemukan kesalahan.
* Tidak redundan.
* Harusnya ‘jenis terbaik’.
* Tidak boleh terlalu sederhana atau terlalu kompleks.



DESAIN TEST CASE

Terdapat bermacam-macam rancangan metode test case yg dapat digunakan, semua menyediakan pendekatan sistematis untuk uji coba, yg terpenting metode menyediakan kemungkinan yg cukup tinggi menemukan kesalahan.

Terdapat 2 macam test case:

1. Pengetahuan fungsi yg spesifik dari produk yg telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yg diharapkan.
2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.

Dua macam pendekatan test yaitu :

1. Black Box Testing

Test case ini bertujuan untuk menunjukkan fungsi perangkat lunak tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya.

Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.

Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.

Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.

2. White Box Testing

Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.

Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.

Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.

STRATEGI UJI COBA PERANGKAT LUNAK

Strategi uji coba perangkat lunak memudahkan para perancang untuk menentukan keberhasilan system yg telah dikerjakan. Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yg diperlukan.

Strategi uji coba mempunyai karakteristik sbb :

* Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan.
* Teknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu)
* Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen.
* Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian.

Pengujian perangkat lunak adalah satu elemen dari topik yang lebih luas yang sering diacu sebagai verifikasi dan validasi (V& V).

Verifikasi : Kumpulan aktifitas yg menjamin penerapan perangkat lunak benar-benar sesuai dgn fungsinya.

Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa perangkat lunak yang dibangun dapat memenuhi keperluan pelanggan.

1. PENGUJIAN UNIT
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel atau beruntun dengan modul lainnya.

2. PENGUJIAN INTEGRASI
Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan dengan interface.

Metode pengujian

a) Top- down integration

Top down integration adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.

Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.

b) Pengujian Integrasi Bottom-up

Bottom up integration memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:

1. modul tingkat rendah digabung ke dalam cluster (build) yang melakukan subfungsi perangkat lunak spesifik.
2. Driver (program control untuk pengujian) ditulis untuk mengkoordinasi input dan output test case
3. cluster diuji
4. driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.


PENGUJIAN DAN IMPLEMENTASI PERANGKAT LUNAK

Testing (Pengujian Perangkat Lunak)
Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean.
Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas.
Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang merusak daripada membangun.
Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah:
1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan
2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya
3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya
Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang ditemukan. Data yang dikumpulkan pada saat pengujian dilakukan memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak secara keseluruhan, tetapi ada satu hal yang tidak dapat dilakukan oleh pengujian, yaitu pengujian tidak dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak.
Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekayasa perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:
 semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan, maksudnya mengungkap kesalahan dari cacat yang menyebabkan program gagal.
 Pengujian harus direncanakan lama sebelum pengujian itu mulai, maksudnya semua pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan.
 Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program.
 Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”, Selagi pengujian berlangsung maju, pengujian mengubah focus dalam usaha menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem.
 Pengujian yang mendalam tidak mungkin karena tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program menengah pun sangat besar.
 Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent
Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program computer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program computer dapat diuji. Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi.
Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.

Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.
Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.
Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.
Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.
Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.

Integrasi Top-Down adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.
Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.

Pengujian Integrasi Bottom-up memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:
1. modul tingkat rendah digabung ke dalam cluster (build) yang melakukan subfungsi perangkat lunak spesifik.
2. Driver (program control untuk pengujian) ditulis untuk mengkoordinasi input dan output test case
3. cluster diuji
4. driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.

IMPLEMENTASI ENTEPRISE SISTEM

Enterprise system adalah sistem berbasis software untuk membantu pengelolaan sistem informasi pada suatu organisasi dengan skala besar. Skala besar berarti volume transaksi yang besar, concern terhadap kualitas informasi yang tinggi, mengintegrasikan berbagai proses bisnis, lintas bidang (horisontal) maupun lintas strata (vertikal). Contoh dari ES adalah ERP (Enterprise Resource Planning) atau e-Business secara umum, e-Government, dan ingrated software lainnya.
Mengimplementasikan ES tidak mudah, atau setidaknya memilki strategi yang berbeda dengan sistem lain yang terbatas ruang lingkupnya, penggunanya dan tidak terpadu. Implementasi di sini bermakna bahwa software telah dapat digunakan dan bisa memberikan value bagi penggunanya sesuai tujuan pemanfaatan software tsb. Implementasi ini bisa dilakukan secara internal organisasi (oleh divisi IT/MIS) atau dengan pihak eksternal dalam kerangka proyek dan terikat legalitas berbentuk kontrak.
implementator sebagai pihak eksternal yang melakukan implementasi dan klien sebagai organisasi yang diimplementasikan softwarenya.
Implementasi ES berbeda dengan implementasi software berskala kecil atau yang penggunanya tunggal seperti MS Word, Database Rental VCD atau website, meskipun produknya sama-sama software yang berjalan di atas server dan membutuhkan konektivitas. Tentu nanti ada strategi yang berbeda, metode pemilihan bahan yang berbeda, tahapan yang berbeda, standar-standar tertentu, dst. Demikian pula dalam konteks software, bisa dipilah berdasar cakupan penggunaannya, bisa dilihat juga dari jenisnya (generik dan customized), yang masing-masing punya strategi implementasi yang berbeda. SE berkaitan dengan pengelolaan sistem informasi, yang tidak hanya bicara teknologi saja, tapi berkaitan dengan proses bisnis, struktur organisasi dan manusianya.
Pola pikir ”developer” adalah menganggap suatu problem bisa selesai dengan solusi berbasis software yang baik dan tepat. Tapi apakah cukup seperti itu? Dalam membangun solusi, ya itu cukup, tapi belum tentu menjamin kesuksesan implementasi. Pola pikir developer cenderung berfokus pada analisis dan development tidak pada implementasinya. Padahal sukses tidaknya proyek software, baik buruknya reputasi implementator, seringkali orang luar melihat pada keberhasilan implementasinya dan value yang didapatkan klien. ES untuk organisasi dengan puluhan divisi, ribuan orang, puluhan kepentingan, dan mungkin ratusan konflik. Apalagi jika software yang kita implementasikan bukan sekedar supporting tools tapi adalah core dari bisnis itu sendiri (konsep e-business). Cara implementasi dengan pola pikir seperti ini hanya akan menghasilkan solusi dan software yang bagus, tapi tidak optimal dan memberikan value untuk organisasi tsb, atau bahkan malah tidak pernah akan digunakan.
Implementator tidak bisa memposisikan diri sebagai project manager pada sebuah proyek yang berkaitan langsung dengan proses bisnis internal klien. Seorang project manager harus mampu mengelola semua resource berkaitan dengan proyek. Kadang kita tidak menyadari bahwa sebagaian besar resource dari proyek software justru berada di sisi organisasi klien. Sementara, project manager seharusnya memiliki akses ke seluruh resource tersebut, karena jika tidak, itu bukan project manager namanya.
Dalam kasus ini, maka project manager seharusnya justru berada di sisi klien, bukan implementator. Akan sia-sia jika aktivitas project planning, project controlling dsb sepenuhnya dilakukan oleh implementator, sementara klien hanya ”tahu beres” saja. Pada akhirnya aktivitas-aktivitas project management tsb hanya akan menghasilkan berkas-berkas dan dokumen administratif saja, yang pada kenyataannya tidak pernah dilaksanakan.
Peran yang paling pas untuk implementator adalah sebagai konsultan. Tugas utama dari konsultan adalah memberikan informasi, mendampingi, memfasilitasi dan menjadi motor ”behind the screen”. Tentu saja jika kontraknya melibatkan pengadaan software, konsultan juga akan melakukan development atau implementasi secara teknis, namun implementasi keseluruhannya harus dipimpin oleh klien sendiri melalui project manager. Jika klien tidak memiliki pengetahuan yang cukup untuk mengelola proyek software, itulah tugas konsultan untuk mendampinginya, sehingga proses project planning, control, evaluation, dst sepenuhnya akan berasal dari ide-ide, komitmen dan effort dari klien sendiri.
Tugas konsultan adalah memfasilitasi dan mengarahkannya. Model seperti ini yang kemudian memunculkan teknik JAD (Joint Application Design), yang intinya adalah melibatkan dan kolaborasi seluruh stakeholder proyek. salah satu fase dalam implementasi sistem adalah fase transisi, yang pasti akan menuntut perubahan baik kecil maupun besar. Adanya sistem baru, mau tidak mau akan merubah proses bisnis. Perubahan proses bisnis berarti perubahan cara kerja, alur kerja dan bahkan budaya kerja. Perubahan ini menyangkut aspek people dan proses bisnis, sehingga dikenal konsep change management.
Dalam eksekusinya, change ini harus dipimpin dan dimanage oleh leader di internal organisasi. Yang jelas seorang konsultan tidak hanya dituntut memiliki pengetahuan tentang software engineering dan hal-hal teknis, dan juga tidak cukup ditambah dengan pengalaman dan keterampilan project management, namun konsep dan bestpractice tentang change management, communication skill yang excellent sangat diperlukan.

JAD (Joint Application Development/Design) sebagai salah satu teknik manajemen dalam mengimplementasikan sebuah sistem informasi (SI) dalam konteks proyek. porsi terbesar dan terumit dari proses implementasi SI adalah justru pada proses transisinya, karena terkait banyak aspek tidak hanya di sisi teknologi tapi harus memahami sisi sosial, manajerial dan SDM.

Implementasi SI
Masalah terbesar dari implementasi SI adalah untuk mengetahui kebutuhan dari user, apalagi dengan karakter proyek :
• Sistem yang melibatkan multi-organisasi/divisi (penggunanya dari beberapa role dan divisi)
• Bisnis proses yang kompleks
• Kebutuhan yang sangat spesifik dan customized.
Dengan karakter proyek yang semacam ini, tidak cukup bagi seorang system analyst (SA) menentukan kebutuhan hanya dengan teknik wawancara, observasi ataupun kuesioner. Banyak kasus ditemui, bahwa pada akhirnya apa yang kita dapatkan dari proses analisa kebutuhan di awal proyek, tidak match dengan kebutuhan sesungguhnya dari pengguna sistem, sehingga sistem akhirnya tidak dapat digunakan dengan baik. Masalah lain adalah di sisi waktu. Teknik-teknik seperti itu seringkali sangat time consuming, sangat membutuhkan waktu yang lama. Sering juga tim developer dihadapkan situasi bahwa tidak semua stakeholder proyek memiliki kepedulian yang sama dengan yang lain. Seorang manajer tidak mengetahui kebutuhan detail dari staf-staf operasional, sementara itu staf operasional mungkin juga tidak memahami sepenuhnya spirit, goal dari SI. JAD merupakan sebuah teknik yang berfokus pada keterlibatan dan komitmen pengguna dalam menentukan kebutuhan dan merancang (desain) aplikasi. JAD biasanya dilakukan dalam bentuk tim yang merupakan gabungan dari seluruh stakeholder proyek, yang bekerja dalam bentuk workshop-workshop atau forum diskusi.
Kenapa workshop ? karena teknik JAD ini bukanlah sekedar rapat-rapat, yang biasa dilakukan dalam sebuah proyek dan melibatkan seluruh stakeholder proyek. JAD adalah tim yang nantinya akan membuat rancangan dan mengawasi, memonitor bersama jalannya proyek.

Siapa yang perlu terlibat ?
Secara garis besar yang perlu terlibat adalah :
1. Sponsor. Sponsor ini berarti project owner, memiliki kedudukan yang cukup tinggi dalam organisasi dan sebagai pengambil keputusan tertinggi dalam pengelolaan sistem informasi. Satu hal yang penting dilakukan oleh seorang project owner adalah komitmen yang kuat akan implementasi SI yang dilakukan. Without the executive sponsor's commitment, people do not show up for workshops on time or sometimes at all. Schedules change and projects are delayed. In short, without an executive sponsor, there is no project!
2. Business Users. Business User ini terdiri dari 2 jenis, yaitu real end user dan representative end user. Real end user adalah person yang melakukan pekerjaan real di lapangan. Dalam kasus, ini adalah operator-operator. Sedangkan representative end user adalah person yang mengetahui seharusnya bisnis proses itu dilakukan, memahami spirit dan goal dari sistem yang dikelolanya. Biasanya ini adalah kepala bagian, manajer, atau operator senior.
3. System Analyst (Tim Developer). Person/tim ini yang akan in-charge dari sisi teknologi dan proses engineeringnya.
4. System Experts. Tidak semua referensi mencantumkan peran ini. Perannya lebih seperti konsultan yang memahami seluk beluk bisnis proses dari sisi konseptual dan berbasis pengalaman.
5. Facilitator. Seorang fasilitator berfungsi sebagai moderator dan mengarahkan setiap aktivitas JAD yang melibatkan banyak pihak, untuk menjadi efektif. Seorang fasilitator harus memiliki kecakapan yang baik dalam berkomunikasi, memberikan stimulus-stimulus dan trik-trik agar diskusi bisa berjalan dengan baik.
Tentu saja, setelah penyusunan tim JAD, diperlukan strategi yang tepat dalam melakukan workshop-workshop, sehingga proses dilakukan lebih efektif. Yang jelas, teknik ini sudah terbuktif efektif dalam menyelesaikan masalah-masalah implementasi SI.


Kesimpulan studi kasus oleh Standish grouph report
Success Criteria Points DMV CONFIRM HYATT ITAMARATI
1. keterlibatan pemakai 19 NO ( 0) NO ( 0) YES (19) YES (19)
2. dukungan manajemen eksekutif 16 NO ( 0) YES (16) YES (16) YES (16)
3. kebutuhan yg jelas 15 NO ( 0) NO ( 0) YES (15) NO ( 0)
4. perencanaan yg sesuai 11 NO ( 0) NO ( 0) YES (11) YES (11)
5. harapan yg realistis 10 YES(10) YES (10) YES(10) YES (10)
6. proyek terkecil 9 NO ( 0) NO ( 0) YES ( 9) YES ( 9)
7. staff yg kompeten 8 NO ( 0) NO ( 0) YES ( 8) YES ( 8)
8. pemilik 6 NO ( 0) NO ( 0) YES ( 6) YES ( 6)
9. visi & sasaan ygjelas 3 NO ( 0) NO ( 0) YES ( 3) YES ( 3)
10. kerja keras, staff dipusatkan 3 NO ( 0) YES ( 3) YES ( 3) YES ( 3)
TOTAL 100 10 29 100 85


Sukses / gagalnya proyek
Project Success Factors % of Responses
1. keterlibatan pemakai 15.9%
2. dukungan manajemen eksekutif 13.9%
3. kebutuhan yg jelas 13.0%
4. perencanaaan yg sesuai 9.6%
5. harapan yg realistis 8.2%
6. proyek terkecil 7.7%
7. staff yg kompeten 7.2%
8. pemilik 5.3%
9. visi dan sasaran yg jelas 2.9%
10.kerja keras, staff dipusatkan 2.4%
Lainnya 13.9%






Project Challenged Factors % of Responses
1. tidak ada masukkan dari pemakai 12.8%
2. kebutuhan & spesifikasi tg tdk sempurna 12.3%
3. mengubah kebutuhan dan spesifikasi 11.8%
4. tidak ada dukungan dr manajemen eksekutif 7.5%
5. ketidakmampuan teknologi 7.0%
6. tidak ada sumber daya 6.4%
7. harapan yg tdk realistis 5.9%
8.sasaran tdk jelas 5.3%
9. batasan waktu tdk realistis 4.3%
10. teknologi baru 3.7%
Lainnya 23.0%

Project Impaired Factors % of Responses
1. kebutuhan tdk lengkap 13.1%
2. tidak ada masukan/keterlibatan dr pemakai 12.4%
3. tidak ada sumber daya 10.6%
4. harapan yg tdk realistis 9.9%
5. tidak ada dukungan dr manajemen eksekutif 9.3%
6. perubahan kebutuhan dan spesifikasi 8.7%
7. tidak ada perencanaan 8.1%
8. tidak diperlukan sama sekali 7.5%
9. tidak ada manajemen IT 6.2%
10. buta teknologi 4.3%
Lainnya 9.9%

Istilah
DMV : the California department of motor vehicles
Banco itamarti : bank brazil
Confirm : American airlines utk penyewaan mobil di hotel marriott
& hilton