TEKNIK PENGUJIAN PERANGKAT LUNAK
Menurut Deutsch (1979), Pengembangan sistem perangkat lunak
melibatkan sederetan aktivitas produksi dimana peluang terjadinya
kesalahan manusia sangat besar. Kesalahan pertama terjadi mulai
permulaan proses dimana sasaran tidak ditetapkan secara sempurna.
Beizer (1990) mengatakan, ada mitos yang menyatakan bahwa
jika kita benar-benar baik dalam pemrograman, maka tidak akan terjadi
bug, demikian sebaliknya.
Hal tersebut terkait dengan analisis data yang matang,
pemrograman terstruktur, rancangan sistem yang baik dan dokumentasi
sistem yang lengkap. Jadi : “Haruskah pengujian sistem mencari
kesalahan ?”, “Apakah pengujian sistem bersifat merusak ?”.
A. DASAR-DASAR PENGUJIAN PERANGKAT LUNAK
Glen Myers (1979) menyatakan, aturan dalam pengujian
perangkat lunak meliputi :
1. Pengujian adalah proses eksekusi suatu program dengan maksud
menemukan kesalahan.
2. Test case yang baik adalah memiliki probabilitas tinggi untuk
menentukan kesalahan yang belum pernah ditemukan
sebelumnya.
3. Pengujian yang sukses adalah pengujian yang mengungkap
Penjelasan di atas menunjukkan parameter bahwa pengujian
dikatakan sukses :
1. Jika ditemukan kesalahan dalam perangkat lunak.
2. Fungsi perangkat lunak bekerja sesuai spesifikasi sistem dan
persyaratan kinerja.
3. Data yang terkumpul saat tahap analisis memberikan indikasi
yang baik.
Prinsip pengujian perangkat lunak (Pressman, 1997) :
1. Semua pengujian harus dapat ditelusuri sesuai permintaan user.
2. Pengujian harus direncanakan lama sebelum pengujian dimulai.
3. Pengujian harus dimulai dari “hal kecil” dan berkembang ke “hal
besar”.
4. Pengujian yang mendalam tidak mungkin dilakukan.
5. Agar efektif, pengujian dilakukan pihak ketiga yang independen.
Programmer melakukan pengujian dengan cara “testabilitas”.
James Bach (1994, internet newsgroup : comp.software-eng., dari
kutipan Pressman, 1997) mengatakan testabilitas adalah seberapa
mudah sebuah perangkat lunak dapat diuji ?. sebab pengujian sangat
sulit, perlu diketahui apa yang harus dilakukan agar menjadi mudah.
Karakteristik perangkat lunak yang dapat diuji (Pressman, 1997) :
2. Observabilitas : apa yang anda lihat, adalah apa yang anda uji.
3. Kontrolabilitas : semakin baik mengendalikan perangkat lunak,
semakin banyak pengujian yang dapat diotomatisasi.
4. Dekomposabilitas : mengendalikan ruang lingkup pengujian,
maka lebih cepat mengisolasi masalah dan pengujian ulang
secara halus.
5. Keserderhanaan : semakin sedikit yang diuji, semakin cepat
mengujinya.
6. Stabilitas : semakin sedikit perubahan source, semakin sedikit
gangguan dalam pengujian.
7. Kemampuan pemahaman : semakin banyak informasi yang
dimiliki, semakin halus pengujian dilakukan.
B. DESAIN TEST CASE
Sampai saat ini telah berkembang berbagai metode desain test
case. Metode tersebut memberikan pendekatan yang sistematik ke
pengujian. Perangkat lunak dapat diuji dengan dua cara :
1. Pengujian dilakukan secara bersamaan untuk memperlihatkan
bahwa setiap fungsi beroperasi sepenuhnya dan mencari
kesalahan setiap fungsi (black-box).
2. Pengujian dilakukan untuk memastikan bahwa “semua modul
Sumber Pustaka :
B. Beizer, 1990, Software Testing Techniques, 2ndEdition, Van Nostrand Reinhold.
Glen Myers, 1979, The Art of Software Testing, Wiley.
James Bach (1994) Internet newsgroup : comp.software-eng.
M. Deutsch, 1979, Verivication and Validation, dalam Software Enggineering, R. Jensen dan C. Tonies (eds.) Prentice –Hall, Hal. 329 – 408.
Disebut juga Glass-Box adalah teknik pengujian menggunakan
struktur kontrol desain prosedural. Pengujian White-Box membuat
programmer dapat melakukan :
1. Kepastian bahwa semua modul program pernah di uji paling
tidak satu kali.
2. Menggunakan keputusan logis pada sisi true atau false.
3. Mengeksekusi semua looping dan pencabangan pada
setiap operasi modul.
4. Menggunakan struktur berkas untuk menjamin validasi.
D. PENGUJIAN BLACK-BOX
Berfokus pada persyaratan fungsional perangkat lunak. Sehingga
programmer mendapatkan serangkaian kondisi input yang seluruhnya
menggunakan syarat fungsional pada suatu program.
Pengujian Black-Box berusahan menemukan kesalahan dalam
kategori (Pressman, 1997) :
1. Fungsi-fungsi yang salah.
2. Kesalahan desain interface.
3. Kesalahan dalam struktur berkas atau akses database eksternal.
4. Kesalahan kinerja (bisa sistem atau manusia).
5. Masalah inisialisasi.
E. PENGUJIAN BASIS PATH
Diperkenalkan perrtama kali oleh Tom McCabe (1976). Beberapa
Notasi Grafik Alir
Grafik alir yang menggambarkan secara logika ditunjukkan gambar 1.
Gambar 1. Grafik alir secara logika
Grafik alir yang menggambarkan secara prosedural seperti gambar 2.
Dari gambar 2 direpresentasikan ke bentuk grafik alir logika sehingga
hasilnya ditunjukkan gambar 3.
Kompleksitas Siklomatis
Kompleksitas Siklomatis adalah matrik perangkat lunak yang
memberikan pengukuran kuantitatif terhadap logika suatu program. Bila
diterapkan pada Pengujian Basis Path menunjukkan bahwa semua
statement telah dieksekusi sedikitnya satu kali, dan nilai yang terhitung
menentukan jumlah jalur independen. Jalur independen adalah jalur
yang melalui program yang mengeksekusi sedikitnya satu kali
Gambar 2. Grafik alir secara prosedural
Gambar 3. Representasi dari gambar 2
Jalur R1 : 1 - 11
Jalur R2 : 1 – 2 – 3 – 4 – 5 – 10 – 1 – 11
Jalur R3 : 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11
Bagaimana kita tahu banyaknya jalur yang dicari ?. Komputasi
Kompleksitas Siklomatis memberikan jawabannya. Ada tiga cara yaitu :
1. Jumlah region (R) sesuai dengan kompleksitas siklomatis.
2. V(G) = E – N + 2. Dimana E : jumlah link ; N : jumlah simpul ;
V(G) : kompleksitas siklomatis.
3. V(G) = P + 1. Dimana P : jumlah simpul predikat.
Ciri-ciri simpul predikat :
Masing-masing simpul berisi sebuah kondisi.
Ditandai dua atau lebih link yang berasal darinya.
Matriks Grafik
Adalah matrik bujur sangkar yang ukurannya sama dengan jumlah
simpul pada grafik alir (Beizer B., 1990). Link weight adalah 1 (ada
hubungan) dan 0 (tidak berhubungan). Link weight memberikan
informasi tambahan mengenai aliran kontrol.
Dengan demikian matrik grafis disebut matrik koneksi. Contoh gambar 4
menjelaskan.
F. PENGUJIAN STRUKTUR KONTROL
Pengujian struktur kontrol terdiri dari beberapa teknik/metode, yaitu :
Pengujian Kondisi
Adalah sebuah metode desain test case yang menggunakan kondisi
logis pada suatu program (Tai, 1989). Tujuan pengujian kondisi adalah
mendeteksi kesalahan dalam program dan kondisi pada program lain.
Kondisi sederhana : variabel boolean atau suatu persamaan yang didahului dengan operator NOT ( != ; <> ; # ).
Kondisi Gabungan : terdiri dari dua atau lebih kondisi sederhana, operator boolean dan tanda kurung.
Persamaan Boolean : kondisi tanpa persamaan relasional.
Persamaan Relasional mengambil bentuk (Tai, 1989) :
E1 (operator_relasional) E2
DimanaE1 dan E2 : aritmatika
Dimana operator relasional : < ; <= ; > ; >= ; #
Persamaan Boolean meliputi : OR ( | ) ; AND ( & ) ; NOT ( # )
Tipe kesalahan pada suatu kondisi meliputi :
1. Kesalahan operator boolean.
2. Kesalahan variabel boolean.
3. Kesalahan tanda kurung boolean.
4. Kesalahan operator relasional.
5. Kesalahan persamaan aritmatika.
Pengujian Aliran Data
Metode ini memilih jalur pengujian suatu program sesuai dengan lokasi
definisi dan menggunakan variabel-variabel pada program, metode ini
telah diteliti oleh beberapa pakar. (Frankl, 1988), (Ntafos, 1988) dan
(Frankl, 1993).
Metode Pengujian Aliran Data berguna untuk jalur pengujian suatu
program yang berisi statement IF yang nested (tersarang). Namun
pengujian Aliran Data lebih sulit dari pada masalah yang berhubungan
dengan Pengujian Kondisi (Pressman, 1997).
Pengujian Loop
Loop adalah batu pertama dalam pemrograman dan mayoritas
algoritma utama pada perangkat lunak. Menurut Beizer (1990),
Pengujian Loop merupakan teknik pengujian White Box yang berfokus
pada validasi konstruksi loop.
Empat kelas loop didefinisikan oleh Beizer sebagai berikut : Loop
G. PENGUJIAN BLACK BOX
Perbedaan utama White Box dan Black Box adalah :
White Box melakukan pada saat awal proses pengujian.
Black Box melakukan selama tahap akhir pengujian.
Pengujian Black Box didesain untuk menjawab pertanyaan berikut :
1. Bagaimana validitas fungsional diuji ?
2. Kelas input apa yang membuat pengujian menjadi lebih baik ?
3. Apakah sistem cukup sensitif terhadap nilai input tertentu ?
4. Bagaimana batasan dari suatu data diisolasi ?
5. Apa saja yang dapat ditolerir oleh sistem ?
6. Apa pengaruh kombinasi tertentu dari data terhadap operasi
sistem ?
Teknik Graph-Based
Teknik yang menentukan sederetan pengujian memiliki hubungan yang
diharapkan satu dengan yang lain (Beizer, 1995). Dalam teknik ini ada
beberapa istilah yaitu :
1. Simpul yang merepresentasikan obyek.
2. Node weight yang menggambarkan properti dari suatu simpul.
3. Link weight yang menggambarkan beberapa karakteristik link.
Pada Black Box ada istilah Transivitas yaitu, hubungan sekuensial
dipelajari untuk menentukan bagaimana pengaruh hubungan tersebut
menyebar pada obyek yang ditentukan pada suatu grafik. Misal :
A diperlukan untuk menghitung B
B diperlukan untuk menghitung C
Sehingga dibangun hubungan transitif antara A dan C, dimana
A diperlukan untuk menghitung C
Teknik Partisi Ekivalensi
Adalah teknik pengujian black box yang membagi domain input dari
suatu program ke dalam kelas data dimana pengujian dapat dilakukan.
Kelas ekivalensi merepresentasikan serangkaian keadaan valid dan
invalid untuk kondisi input.
Analisis Nilai Batas (boundary value analisys) adalah teknik desain
proses yang melengkapi partisi ekivalensi. Myers, (1979) mengatakan
BVA merupakan teknik yang hampir sama dengan teknik partisi
ekivalensi. BVA lebih menekankan pada batasan suatu obyek.
STRATEGI PENGUJIAN PERANGKAT LUNAK
Pengujian : serangkaian aktivitas yang dapat direncanakan sebelumnya
dan dilakukan secara sistematis.
Langkah-langkah strategis terjadi pada waktu tekanan deadline
pembuatan program mulai naik (dekat), maka kemajuan perangkat
lunak harus dapat diukur dan masalah harus muncul sedini mungkin.
Strategi pengujian menentukan :
1. Kualitas perangkat lunak.
2. Manajemen sistem yang baru.
3. Implementasi yang sesuai dengan masalah.
Dari titik pandang psikologi, analisis dan desain perangkat lunak
merupakan tugas yang konstruktif. Programmer menciptakan sebuah
program, dokumentasi dan struktur berkasnya. Namun dari sudut
pandang psikologi programmer, pengujian dapat dianggap sebagai
destruktif.
Maka :
Programmer selalu bertanggungjawab terhadap pengujian modul
program.
Melakukan pengujian terintegrasi, yaitu setelah semua modul saling
Sebuah pernyataan klasik :
“ anda tidak akan pernah menyelesaikan pengujian. Beban yang ada
akan sedikit bergeser dari anda ke pengguna. “
atau
“ anda telah menyelesaikan pengujian bila anda telah kehabisan
deadline atau uang. “
Kesalahan umum dalam komputasi :
1. Kesalahpahaman yang tidak benar.
2. Operasi mode yang tercampur.
3. Inisialisasi yang tidak benar.
4. Inakurasi ketelitian.
5. Representasi sebuah persamaan relasi yang tidak benar.
6. Perbandingan tipe data yang berbeda.
7. Operator logika yang tidak benar.
8. Perbandingan atau variabel yang tidak benar.
9. Penggunaan loop yang tidak tepat.
Pengujian integrasi : teknik sistematis untuk mengkonstruksi sistem
program sambil melakukan pengujian untuk mengungkap kesalahan
sehubungan dengan interfacing.
Integrasi non-incremental :
Membangun program dengan cara menguji per modul kecil / per
segmen, kemudian digabung menjadi menu utama.
Sumber Pustaka :
Boehm B., 1981 Hal. 37, Software Engineering Economics, Prentice-Hall.
Gilb T., Januari 1995, What We Fail To Do In Our Current Testing Culture, Testing
Techniques Newsletter, Shoftware Research Inc., San Francisco.
Glen Myers, 1979, The Art of Software Testing, Wiley.
Miller , 1977 Hal. 1983, The Philoshopy of Testing, IEEE ComputerSociety Press.
Shooman ML., 1983, Shoftware Engineering, McGraw-Hill.
Wallace DR. dan RU. Fujii, 1989 Hal. 19-27, Shoftware Verivication dan Validation :,
dan Overfiew, IEEE Shoftware, Mei, 1989.
Integrasi Top-Down
Adalah pendekatan inkremental terhadap struktur program. Artinya
program diintegrasikan dengan menelusuri ke bawah melalui program
utama. Subordinat program pada program utama digabung dengan cara
depth-first atau breadth-first.
Proses integrasi dilakukan dengan lima langkah :
1. Program utama digunakan sebagai test driver, dan script yang
berhubungan dengan program utama ditambahkan pada semua
subprogram/modul.
2. Tergantung pada pendekatan integrasi yang dipilih (depth-first
atau breadth-first).
3. Pengujian dilakukan pada setiap modul yang diintegrasikan.
4. Pada setiap pengujian, script diganti dengan script aktual.
5. Pengujian regresi dapat dilakukan untuk memastikan bahwa
kesalahan beru belum muncul.
Strategi Top-Down kelihatannya tidak rumit, namun dalam prakteknya
banyak menimbulkan masalah. Artinya ada tiga pilihan yang diambil :
1. Menunda pengujian sampai script diganti dengan script aktual.
2. Mengembangkan script yang kemampuannya terbatas.
Gambar 7. Script
Integrasi Bottom-Up
Di mulai dengan pengujian modul atomik yaitu modul program pada
tingkat paling rendah pada struktur program. Karena diintegrasikan dari
bawah ke atas maka pemrosesan yang diperlukan selalu ada dan
kebutuhan script dapat dieleminasi.
Proses integrasi dilakukan dengan langkah :
1. Modul tingkat rendah digabung ke dalam cluster/kelompok.
2. Driver ditulis untuk mengkoordinasikan input dan output.
3. Cluster diuji.
4. Driver diganti dan cluster digabung dengan menggerakkan ke
atas di dalam struktur program.
Pengujian Regresi
Setiap kali modul program bertambah maka pengujian akan berubah.
Dalam konteks pengujian regresi integrasi, pengujian regresi
merupakan eksekusi ulang untuk memastikan bahwa perubahan tidak
Tanggapan Pengujian Integrasi
Kerugian utama dari pendekatan Top-Down adalah kebutuhan akan
script pada modul program. Kerugian dari Bottom-Up adalah program
sebagai sebuah entitas tidak sampai ke modul terakhir yang
ditambahkan. (Myers, 1979)
Pemilihan strategi integrasi tergantung pada karakteristik perangkat
lunak dan kadang-kadang juga pada jadual proyek. Pada saat
pengujian integrasi dilakukan, penguji harus mengidentifikasi modul
kritis. Modul kritis memiliki sifat berikut :
1. Menekankan beberapa persyaratan perangkat lunak.
2. Memiliki tingkat kontrol yang tinggi.
3. Kompleks atau error-prone.
4. Memiliki persyaratan kinerja yang terbatas.
Dokumentasi Pengujian Integrasi
Rencana dan deskripsi pengujian secara detail didokumentasikan
dalam spesifikasi pengujian. Spesifikasi ini dapat digunakan pada
proses rekayasa perangkat lunak. Outline spesifikasi pengujian adalah :
I. Lingkup Pengujian
II. Rencana Pengujian
A. Phase dan build pengujian B. Jadual
C. Perangkat lunak overhead D. Lingkungan dan sumber daya III. nProsedur Pengujian
3. Hasil yang diharapkan C. Lingkungan pengujian
1. Piranti atau teknis khusus
2. Deskripsi perangkat lunak overhead D. Data test case
E. Hasil yang diharapkan untuk n build IV. Hasil pengujian sesungguhnya
V. Referensi
VI. Lampiran
Sumber Pustaka :
Pengujian Validasi
Kriteria Pengujian Validasi :
1. Sifat kinerja program harus sesuai dengan spesifikasi.
2. Dokumentasi sistem dirancang secara benar.
Pengujian Alpha dan Beta
Kebanyakan pembuat produk software menggunakan sebuah proses
yang disebut pengujian alpha dan beta, untuk mengungkap kesalahan
yang hanya dapat ditemukan oleh end user (pemakai akhir).
Pengujian alpha dilakukan pada sisi pengembang oleh seorang
pelanggan. Pengujian alpha dilakukan pada sebuah lingkungan yang
terkontrol dan pengoperasiannya diawasi oleh pengembang atau
programmer. Pengujian alpha biasanya dilakukan saat pelatihan atau
training software.
Pengujian beta dilakukan pada satu atau lebih end user (biasa disebut
multi user). Pada pengujian beta biasanya programmer tidak melakukan
pengawasan, sehingga pengujian beta merupakan sebuah aplikasi ‘live’
dari perangkat lunak. End user merekam/mencatat semua ‘bug’ yang
ditemui dan dilaporkan ke programmer dalam interval yang sudah
Adalah sederetan pengujian yang berbeda dengan tujuan utamanya
adalah sepenuhnya menggunakan sistem berbasis komputer. (Beiser,
1984).
Beberapa unsur pengujian sistem meliputi :
1. Pengujian perbaikan. Adalah pengujian sistem yang memaksa
perangkat lunak untuk gagal dalam berbagai cara. Ada dua
macam perbaikan yaitu otomatis dan manual. Perbaikan otomatis
contohnya mampu melakukan perbaikan data, restart dll.
Perbaikan manual membutuhkan intervensi manusia.
2. Pengujian keamanan. Adalah menguji sistem keamaman
perangkat lunak yang dibuat. Misal berusaha menembus sistem
password, Membuat password bertingkat, proteksi dengan serial
number saat instalasi.
3. Pengujian stress. Adalah pengujian yang intinya merusak
program.
4. Pengujian kinerja. Sering berpasangan dengan pengujian sterss.
Pengujian ini membutuhkan instrumentasi perangkat keras.
Debugging
Debugging muncul akibat pengujian yang berhasil. Proses debugging
akan memiliki dua kmungkinan berikut :
1. Penyebab akan ditemukan, lalu dikoreksi dan dihilangkan. Atau
Menurut Bradley (1985), debugging adalah sebuah aplikasi langsung
dari suatu metode keilmuan yang telah dikembangkan selama 2500
tahun. Dasar debugging adalah meletakkan sumber masalah.
Menurut Myers (1979), tiga kategori pendekatan debugging diusulkan
sebagai berikut :
1. Gaya yang kasar (brute force), metode yang paling umum dan
paling efisien untuk mengisolasi penyebab kesalahan program.
Yaitu menggunakan filosofi “biarkan komputer yang menemukan
kesalahan”. Caranya memberikan statement WRITE pada saat
runtime.
2. Penelusuran balik (backtracking), pendekatan yang sangat umu
dilakukan pada program kapasitas kecil. Caranya melakukan
penelusuran balik kode sumber sampai penyebab ditemukan.
3. Eleminasi penyebab, (cause elemination), caranya data yang
berhubungan dengan penyebab kesalahan dikumpulkan untuk
JAMINAN KUALITAS PERANGKAT LUNAK
Pendekatan Terhadap Kualitas
Kualitas adalah hal yang harus diperhatikan dalam membangun sistem.
Tiga pendekatan yang menjamin kualitas teknik program :
1. Membuat sistem dengan pendekatan top-down.
2. Mendokumentasikan perangkat lunak dengan alat dokumentasi
sistem.
3. Melakukan pengujian, pemeliharaan dan pemeriksaan sistem.
Dua hal yang menjamin kualitas sistem :
1. End user adalah faktor utama yang menentukan kualitas sistem.
2. Lakukan pembenahan di awal pembuatan program untuk hasil
yang lebih baik, dari pada menunggu komplain dari end user saat
program dijalankan.
Metode Terstruktur Adalah Penjamin Kualitas :
Metode Terstruktur meliputi paling tidak empat orang : kepala proyek
sistem, koordinator pelaksana, analis/ programmer, end user (Kendall &
Kendall, 2002).
Pemrograman Moduler :
Pemrograman moduler merupakan pemecahan program secara logis/
modul. Pemrograman moduler menggunakan pendekatan top-down
Perancangan pemrograman moduler mempunyai tiga keuntungan :
1. Modul program dapat ditulis secara terpisah dan dipasang pada
sistem utama, karena dapat dijalankan secara mandiri. Jika terjadi
run-time error hanya ada di modul yang dieksekusi, bukan pada
sistem utama.
2. Perbaikan/pengembangan mudah dilakukan, karena sistem modul
dibuat secara terpisah. Jadi tidak mempengaruhi sistem utama.
3. Modul mudah di mengerti karena mereka adalah subsistem,
sehingga end user dapat membaca kode program dan memahami
fungsinya.
Memilih Teknik Perancangan dan Dokumentasi
Analis sistem selalu dihadapkan pada keputusan yang sulit terkait
teknik dan dokumentasi yang cocok. Berikut merupakan panduan untuk
membantu analis sistem memilih teknik dan alat dokumentasi :
1. Cocok dengan pengadaan dokumentasi.
2. Dimengerti oleh end user dalam organisasi terkait.
3. Mudah diingat dan dimengerti setelah jauh dari anda beberapa
waktu.
4. Sesuai dengan ukuran sistem yang dibuat.
5. Dapat dimodifikasi dengan mudah.
Menguji, Memeliharaan dan Memeriksa
Sistem yang baru dibuat harus diuji terus menerus. Menguji sistem
2. Sistem dalam tahap pengembangan.
Menguji adalah membosankan, namun ini merupakan hal yang harus
dilakukan untuk menjamin kualitas sistem pada akhirnya. LEBIH BAIK
MELAKUKAN TES UJI LEBIH AWAL DARIPADA MEMPUNYAI
SISTEM YANG GAGAL SETELAH INSTALASI KARENA TIDAK DIUJI
DENGAN BAIK (kendall & kendall, 2002).
Pemeliharaan dilakukan untuk memperbaharui perangkat lunak dalam
merespon perubahan organisasi. Pemeliharaan merupakan perhatian
utama setelah sistem terpakai, karena dapat memakan biaya 50% lebih
dari anggaran produksi program (kendall & kendall, 2002).
Dari pandangan tersebut wajar jika menemukan kesalahan lebih awal
dapat menghemat biaya operasional pemeliharaan, dari pada
membiarkan kesalahan yang tidak diketahui sehingga menjadi ‘bumm’.
Pemeriksaan ada dua hal yaitu internal dan eksternal. Internal dilakukan
terhadap hasil dari sistem berupa print out laporan yang berisi
informasi. Eksternal dilakukan oleh programmer/analis sistem untuk
memeriksa kelayakan sistem setelah digunakan sekian waktu.
Sumber Pustaka :
Kenneth E. Kendall and Julie E. Kendall, 2002, System Analysis and Design,
IMPLEMENTASI SISTEM INFORMASI
Pendekatan Implementasi
Analisis sistem mempunyai empat pendekatan implementasi sistem :
1. Implementasi dengan sistem komputer terdistribusi.
2. Implementasi dengan strategi teknik pelatihan sistem baru.
3. Implementasi dengan strategi teknik pelatihan sistem baru.
4. Implemetnasi dengan penilaian sistem baru yang telah digunakan.
Implementasi dengan sistem komputer terdistribusi.
Dibahas pada mata kuliah sistem terdistribusi.
Implementasi dengan strategi teknik pelatihan sistem baru.
Strategi pelatihan ditentukan oleh siapa yang dilatih dan siapa yang
melatih. Tentukan tujuan pelatihan. Metode pelatihan yang digunakan.
Materi pelatihan yang terkait dengan sistem baru.
Implementasi dengan strategi teknik pelatihan sistem baru.
Lima strategi konversi dari sistem lama ke sistem baru :
1. Perubahan langsung, artinya pada tanggal tertentu sistem lama
dihentikan dan sistem baru diberlakukan.
2. Konversi paralel, mengacu dengan menjalankan sistem baru dan
sistem lama bersamaan dengan waktu yang ditetapkan. Dan
kehandalan output kedua sistem dibandingkan. Cocok untuk
teknik diatas dengan menaikkan frekuensi kapasitas sistem yang
ditangani secara bertahap.
4. Konversi prototipe modular, menggunakan teknik modular untuk
merubah sistem lama ke sistem baru dengan cara bertahap.
Setiap modul diuji sebelum digunakan sampai end user terbiasa
menggunakan modul yang telah menyatu menjadi sebuah sistem.
5. Konversi terdistribusi, mengacu pada situasi dimana banyak
terdapat instalasi sistem baru. Seperti kasus perbankan, lembaga
