Penerapan Testing dan Implementasi Pada Sistem Informasi

a.       Definisi tentang Testing dan implementasi sistem informasi ada 4, sebagai berikut : 

·       Melakukan pengujian terhadap system informasi / program aplikasi/aplikasi sebelum digunakan.

·       Menguji dan membandingan dengan system sebelumnya, untuk memunculkan keunggulan pada system yang lama dan mengurangi kesalahan pada system yang baru. System yang baru lebih baik dari pada system yang lama.

·       Merevisi sisstem yang diuji, sampai sistem benar benar dapat menyelesaikan maslah pada sistem / organisasi (revisi sistem sebelum sistem digunakan)

·       Sistem yang sudah digunakan, berarti sudah melalui pengujian sistem dan sistem layak dioperasikan / digunakan.

b.      Definisi Pengujian Pada Sistem

·         Suatu proses yang dilakukan untuk menilai apakah yang dirancang telah sesuai dengan apa yang diharapkan.

·      Suatu kegian untuk mengevaluasi keunggulan dan kelermahan terhadap sesuatu yang diuji (kualitas produk).

 ·         Mengevaluasi terhadap urutan kegiatan yang sistematis dalam mencapai tujuan sistem.

·         Mengevaluasi keseimbangan jumlah pelaksanaan kegiatan dengan beban kerja dalam sesuatu prosedur kegiatan.

c.       Pengujian dan Mengevaluasi Pada Sistem

·      Hal- hal yang terlibat dalam suatu kegiatan untuk mencapai tujuan yang diharapkan untuk pengguna. Testing adalah Proses yang dibuat sedemikian rupa untuk mengidentifikasikan adanya ketidak sesuaian hasil sebuah sistem informasi dengan apa yang diharapkan.

d. Berdasarkan pengertian diatas testing mempunyai beberapa tujuan :

·      Testing dilakukan untuk memastikan mutu dari suatu produk yaitu menguji apakah produk (dalam hal ini system informasi) yang dihasilkan telah sesuai dengan mutu yang dipersyaratkan. Testing dilakukan untuk memastikan atau menjaga mutu suatu produk.

·      Testing merupakan proses analisa dan entitas software, pada testing ini bertujuan untuk mendeteksi adanya perbedaan antrar kondisi software yang ada dengan kondisi yang diinginkan, untuk melihat kerusakan suatu produk melakukan evaluasi fitur fitur dari software.

e.  Pengujian pada Sistem

·       Melakukan proses evaluasi terhadap sistem yang sudah ada, apakah sistem sudah sesuai yang diharapkan oleh user

·       Menilai dan mengevaluasi terhadap output atau hasil dari sistem

·       Menguji terhadap input, pengelolaan / proses dan output system

·       Melakukan penilaian dan evaluasi terhadap komponen sistem prosedur pelaksanaan kegiatan dan mutu atau kualitas hasil sistem

f. Pengujian terhadap sistem

 1. Personil

·         Personil ditempakan sudah sesuai dengan skill atau kemampuan yang dimilikinya

·         Beban kerja yang optimum untuk masing-masing personil

·         Loyalitas atau kemamuan bekerja sama untuk menyelesaikan suatu kegiatan

·         Kemampuan personil dalam menyelesaikan masalah

g. Pengujian kegiatan

·         Prosedur dan system kerja yang sistematis

·         Perencanaan yang terkontrol dan terjadwal

·         Arah tujuan atau target ang dapat dilaksanakan sesuai dengan perencanaan

·         Hasil kegiatan yang terukur

·         Kesemimbangan kegiatan dengan bersarnya biaya yang digunakan

·         Pengujian misi atau tujuan

1.    Adanya integrasi antara personil yang terlibat dengan kegiatan yang dilaksanakn dalam mencapai target system

2.    Kualiatas dari kegiatan yang mewujudkan tujuan system

3.    Tujuan Testing dan Implementasi pada Sistem

4.    Melakukan pengujian terhadap sistem informasi apakah sudah memenuhi kebutuhan user atau sistem informasi sudah layak digunakan dengan melalui :

·         Uji analisis

·         Uji perancangan

·         Uji implementasi

Pemeliharaan Sistem

Definisi Pemeliharaan Sistem
Pemeliharaan Sistem adalah suatu kombinasi dari berbagai tindakan yang dilakukan untuk menjaga suatu sistem dalam, atau memperbaikinya sampai, suatu kondisi yang bisa diterima. Pada bulan April 1970 didefinisikan sebuah istilah untuk Teknologi Pemeliharaan yang mencakup pengertian yang lebih luas dari pada pengertian Pemeliharaan diatas. Istilah ini adalah Teroteknologi.

Sistem perlu dipelihara karena beberapa hal, yaitu :
1. Sistem memiliki kesalahan yang dulunya belum terdeteksi, sehingga kesalahan-kesalahan sistem perlu diperbaiki.
2. Sistem mengalami perubahan-perubahan karena permintaan baru dari pemakai sistem.
3. Sistem mengalami perubahan karena perubahan lingkungan luar (perubahan bisnis).
4.Sistem terinfeksi malware aktif
5.Sistem berkas corrupt
6.Perangkat keras melemah

Untuk mencegah hal-hal tesebut, digunakanlah mOS(maintenance Operating system) yang berfungsi untuk:

-Manajemen Malware yang aktif

-Pemulihan data (recovery) dan perbaikan sistem berkas

-Diagnosa perangkat keras.
mOS tidak menulis ke disk atau menjalankan kode apapun dari disk, memiliki akses langsung ke perangkat keras, dan hanya membutuhkan sedikit bagian dari perangkat keras untuk bekerja dengan sempurna. Selain dengan mOS, kita juga dapat memelihara sistem (pada windows) dengan cara-cara yang sederhana seperti:
-Jangan pernah mematikan power sampai sistem benar-benar sudah shutdown.
-Buatlah backup data-data yang penting.
-Lakukan defragment setidaknya satu bulan sekali
-Sisakan sedikitspace kosong di partisi tempat sistem operasi berada
-Gunakan firewall jika anda terkoneksi dengan jaringan.
-Lakukan pengecekan virus secara rutin.



Selain dengan menggunakan mOS pemeliharaan sistem juga dapat dilakukan dengan cara :

■ Pemeliharaan Korektif
Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesalahan yang ditemukan pada saat sistem berjalan. Umumnya pemeliharaan korektif ini mencakup kondisi penting atau bahaya yang memerlukan tindakan segera. Kemampuan untuk mendiagnosa atau memperbaiki kesalahan atau malfungsi dengan cepat sangatlah berharga bagi perusahaan.



■ Pemeliharaan Adaptif

Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi adalah dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai. Misalnya, Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam kalkulasi pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari.



■ Pemeliharaan Perfektif (Penyempurnaan)

Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang sebelumnya tidak dikenal. Ketika membuat perubahan substansial modul apapun, petugas pemeliharaan juga menggunakan kesempatan untuk meng-upgrade kode, mengganti cabang-cabang yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi. Sebagai contoh, kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang atau restrukturisasi perangkat lunak, penulisan ulang dokumentasi, pengubahan format dan isi laporan, penentuan logika pemrosesan yang lebih efisien, dan pengembangan efisiensi pengoperasian perangkat.


■ Pemeliharaan Preventif

Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap dan mengantisipasi permasalahan. Karena personil pemeliharaan sistem bekerja dalam sistem ini, mereka seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak dikoreksi di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun kemampuan untuk memeliharanya dalam waktu dekat.

Memelihara Perangkat Lunak
Perangkat lunak aplikasi mungkin terstruktur mungkin pula tidak, atau mungkin didokumentasikan mungkin pula tidak. Beberapa perangkat lunak yang tidak terstruktur dan tidak didokumentasikan mungkin hampir tidak dapat dipelihara. Sebenarnya salah satu sebab utama mengapa pemeliharaan sistem memerlukan anggaran sistem yang amat banyak adalah karena kenaikan tenaga yang dibutuhkan untuk mencoba memelihara perangkat lunak yang didokumentasikan serta distruktur secara acak-acakan. Di lain pihak program perangkat lunak yang tidak terstruktur dan tidak terdokumentasi juga tidak dapat dipelihara. Seandainya suatu perubahan dalam operasi memaksa program itu untuk berubah, maka program itu harus disingkirkan dan dikembangkanlah program baru. Sehinga menyia-nyiakan semua sumber yang dikeluarkan untuk
membangun program asli yang tidak dapat dipelihara tersebut, belum lagi kerugian operasi bisnis bila hari yang ditentukan tiba.

Memelihara Perangkat Keras
Pemeliharaan perangkat keras terutama pemeliharaan preventif yang memerlukan reparasi, penggantian, atau penambahan suku cadang dan komponen untuk merestorasi atau menjaga agar perangkat keras tetap bekerja dengan baik. Komponen perangkat keras sistem informasi sebaiknya dicek dan diservis secara periodik

Siklus Hidup Pemeliharaan Sistem (SMLC)
-Permintaan Perubahan
-Mengubah permohonan pemeliharaan menjadi suatu perubahan
-Menspesifikasi perubahan Membangun pengganti
-Menguji pengganti
-Melatih pengguna dan melakukan tes penerimaan
-Pengkonversian dan pelepasan ke operasi
-Mengupdate dokumentasi
-Melakukan pemeriksaan pascaimplementasi

Mengatur Pemeliharaan Sistem
-Menetapkan kegiatan pemeliharaan
-Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal
-HELP DESK
-Mengevaluasi aktivitas pemeliharaan sistem

Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC)

Tahap pemeliharaan dilakukan setelah tahap implementasi. Sistem baru yang berjalan digunakan sesuai dengan keperluan organisasi. Selama masa hidupnya, sistem secara periodik akan ditinjau. Perubahan dilakukan jika muncul masalah atau jika ternyata ada kebutuhan baru. Selanjutnya, organisasi akan menggunakan sistem yang telah diperbaiki tersebut.

Pemeliharaan sistem dilaksanakan untuk 3 alasan:

1. Memperbaiki kesalahan

2. Menjaga kemutakhiran sistem

3. Meningkatkan sistem

4. Menyiapkan usulan rekayasa ulang

5. Menyetujui atau menolak rekayasa ulang sistem



Merupakan siklus terakhir dari SDLC Pemeriksaan periodik, audit dan permintaan pengguna akan menjadi source untuk melakukan perawatan sistem diseluruh masa hidup sistem.

Jenis Pemeliharaan :
1.Pemeliharaan Korektif
2.Pemeliharaan Adaptif
3.Pemeliharaan Perfektif
4.Pemeliharaan Preventif

Siklus Hidup Pemeliharaan Sistem (SDLC) :
1.Permintaan Perubahan
2.Mengubah permohonan pemeliharaan menjadi suatu perubahan
3.Menspesifikasi perubahan
4.Membangun pengganti
5.Menguji pengganti
6.Melatih pengguna dan melakukan tes penerimaan



Siklus Hidup Pemeliharaan Sistem (SDLC) :
1.Pengkonversian dan pelepasan ke operasi
2.Mengupdate dokumentasi
3.Melakukan pemeriksaan pascaimplementasi


Prosedur Pemeliharaan Sistem :
1.SDLC dan SWDLC
2.Definisi data standar
3.Bahasa pemrograman standar
4.Rancangan Moduler
5.Model yang dapat digunakan kembali
6.Dokumentasi standar
7.Kontrol sentral



Tahapan-Tahapan Siklus Hidup Pemeliharaan Sistem (SMLC)

a. Memahami Permintaan Pemeliharaan

b. Mentransformasi Permintaan Pemeliharaan Menjadi Pengubahan

c. Menspesifikasi Perubahan

d. Mengembangkan Perubahan

e. Menguji Perubahan

f. Melatih Pengguna dan Melakukan Test Penerimaan

g. Pengkonversian dan Meluncurkan Operasi

h. Mengupdate Dokumen

i. Melakukan Pemeriksaan Pasca Implementasi

Case Tools Untuk memelihara Sistem :
1.Forward engineering
2.Reverse Engineering
3.Reengineering
4.Restrukturing
5.Maintenance Expert Systems

Mengatur Pemeliharaan Sistem :
1.Menetapkan kegiatan pemeliharaan
2.Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal HELP DESK
3.Mengevaluasi aktivitas pemeliharaan sistem

Langkah-langkah pemeliharaan sistem terdiri atas:
1. Penggunaan Sistem
Yaitu menggunakan sistem sesuai dengan fungsi tugasnya masing-masing untuk operasi rutin atau sehari-hari.

2. Audit Sistem
Yaitu melakukan penggunaan dan penelitian formal untuk menentukan seberapa baik sistem baru dapat memenuhi kriteria kinerja. Hal semacam ini disebut penelaahan setelah penerapan dan dapat dilakukan oleh seorang auditor internal.

3. Penjagaan Sistem
Yaitu melakukan pemantauan untuk pemeriksaan rutin sehingga sistem tetap beroperasi dengan baik. Selain itu juga untuk menjaga kemutakhiran sistem jika sewaktu-waktu terjadi perubahan lingkungan sistem atau modifikasi rancangan software.

4. Perbaikan Sistem
Yaitu melakukan perbaikan jika dalam operasi terjadi kesalahan (bugs) dalam program atau kelemahan rancangan yang tidak terdeteksi saat tahap pengujian sistem.

5. Peningkatan Sistem
Yaitu melakukan modifikasi terhadap sistem ketika terdapat potensi peningkatan sistem setelah sistem berjalan beberapa waktu, biasanya adanya potensi peningkatan sistem tersebut terlihat oleh manajer kemudian diteruskan kepada spesialis informasi untuk dilakukan modifikasi sesuai keinginan manajer.

Jenis-Jenis Pemeliharaan :
– Pemeliharaan Korektif
– Pemeliharaan Adaptif
– Pemeliharaan Perfektif
– Pemeliharaan Preventif

Siklus Hidup Pemeliharaan Sistem (SMLC):
– Pengkonversian dan pelepasan ke operasi
– Mengupdate dokumentasi
– Melakukan pemeriksaan pascaimplementasi

Prosedur Pemeliharaan sistem :
– SDLC dan SWDLC
– Definisi data standar
– Bahasa pemrograman standar
– Rancangan Moduler
– Model yang dapat digunakan kembali
– Dokumentasi standar
– Kontrol sentral

Case Tools Untuk memelihara Sistem :
– Forward engineering
– Reverse Engineering
– Reengineering
– Restrukturing
– Maintenance Expert Systems

Mengatur Pemeliharaan sistem :
– Menetapkan kegiatan pemeliharaan
– Mengawali dan merekam kegiatan pemeliharaan sistem tidak terjadwal
– HELP DESK
– Mengevaluasi aktivitas pemeliharaan system



Alat-Alat Pemliharaan Sistem
Hardware Yang dibutuhkan sesuai dengan kebutuhan system
Software yang di butuhkan sesuai dengan kebutuhan system

Mengatur Pemeliharaan sitem
Tentukan jadwal maintenance pada system yang kita miliki
Update software yang compatible terhadap system kita
Gunakan tenaga ahli yang terpercaya untuk

Mengembangkan Perubahan Sistem manajemen

Salah satu konsep yang dibahas, , dan dianalisis paling sering dalam beberapa tahun terakhir
telah terjadi perubahan organisasi dan konsep terkait resistensi terhadap perubahan dan
manajemen perubahan. Perubahan telah banyak didefinisikan sebagai membuat perbedaan materi
dalam sesuatu dibandingkan dengan keadaan sebelumnya, atau mengubah sesuatu, atau hanya
menjadi berbeda. Semua definisi ini dapat diterapkan untuk mengubah seperti itu terjadi dalam
organisasi dan bisnis. Perubahan organisasi bisa berarti perubahan teknologi infrastruktur
(misalnya, bergerak dari lingkungan mainframe untuk komputasi terdistribusi), strategi
pemasaran (target basis pelanggan baru), atau manajemen dan praktek pengambilan keputusan.
Perubahan organisasi bukanlah hal baru dengan lanskap bisnis Amerika. Sejak abad kesembilan
belas dan Revolusi Industri, perusahaan harus berurusan dengan perubahan dalam skala yang
semakin cepat. Semakin besar perkembangan teknologi dan semakin besar jumlah produk dan
informasi yang dihasilkan, semakin diperlukan menjadi bagi perusahaan untuk memberikan
manajemen yang efektif dan mengembangkan praktek organisasi yang solid Para profesional
bisnis yang paling dihormati di Amerika Serikat telah orang-orang yang paling mampu
memanfaatkan perubahan dalam bisnis dan perekonomian. Sebagai contoh, pada akhir abad
kesembilan belas, Andrew Carnegie sangat memperluas kerajaannya dengan membeli usaha
yang sangat ia bergantung pada untuk bisnis baja-nya, membuat satu perusahaannya contoh
sukses pertama dari integrasi vertikal.
Dimulai pada 1990-an, perubahan datang pada tingkat yang secara eksponensial lebih cepat
karena faktor-faktor seperti persaingan yang meningkat dalam ekonomi global, memperluas
pasar, cara-cara baru melakukan bisnis (seperti e-commerce), dan tugas di mana-mana menjaga
dengan yang terbaru teknologi. Guru manajemen Peter F. Drucker mengabdikan bukunya
Manajemen Tantangan dari 21 abad ke topik yang sangat. Akibatnya, perusahaan harus merevisi
(atau menyusun) misi perusahaan dan tujuan, praktek manajemen, dan fungsi bisnis sehari-hari.
Perusahaan secara rutin mulai merancang ulang strategi bisnis, sering menggantikan bagan
organisasi tradisional hirarki dengan struktur datar berpusat di sekitar “diberdayakan” tim.
Tujuan utama bagi kebanyakan organisasi adalah untuk perubahan iklim dan budaya perusahaan.
iklim Suatu organisasi dapat didefinisikan oleh bagaimana karyawan melihat alasan mendasar
organisasi. karena, khususnya, misi perusahaan secara keseluruhan dan tujuan dan bagaimana
pentingnya pengertian karyawan kesejahteraan adalah tujuan-tujuan tersebut. Iklim perusahaan
kemudian melahirkan budaya organisasi yang terdiri dari apa karyawan lihat sebagai
kepercayaan manajemen dan sistem nilai. Kedua hal, iklim dan budaya, kemudian menentukan
bagaimana setiap manajer dan karyawan bentuk kinerja nya sendiri, biasanya dalam rangka
paling berhasil mencapai tujuan perusahaan dan mudah-mudahan memastikan keberhasilan
sendiri serta perusahaan. Faktor-faktor ini mempengaruhi setiap aspek dari pekerjaan setiap
orang, termasuk proses pengambilan keputusan, pola komunikasi dalam organisasi, dan
tanggung jawab individu dan tanggung jawab perusahaan.

INDIKATOR PERUBAHAN
Ada empat indikator utama dari perubahan pekerjaan-tempat utama.. Mereka adalah perubahan
struktur organisasi, produk atau jasa baru, manajemen baru, dan teknologi baru. Struktur
Organisasi bisa berubah melalui perampingan besar, outsourcing, akuisisi, atau merger. Tindakan
ini sering disertai dengan PHK, khususnya sebagai posisi tertentu menjadi berlebihan.. Sebuah
produk atau jasa baru memiliki implikasi untuk perubahan dalam produksi, penjualan, dan
layanan pelanggan.. Selain itu, dengan mengubah produk atau jasa organisasi mungkin
menghadapi pesaing baru atau pasar baru.. manajemen baru, seperti perubahan dalam CEO atau
presiden, sering membawa masa transisi di mana para manajer tingkat atas cenderung untuk
mengubah proses bisnis yang ada dan kebijakan personil. Akhirnya, teknologi baru dapat
membuat perubahan besar bagi organisasi. Teknologi dapat mengubah proses produksi atau
kondisi kerja (yaitu, telecommuting), dan perubahan ini mungkin mempengaruhi keterampilan
yang karyawan menggunakan pada pekerjaan.

Implementasi Sistem

Implementasi Sistem Informasi

- System Development Lyfe Cycle (SDLC) 

System Development Lyfe Cycle (SDLC)adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.

- Perancangan Sistem

Perancangan Sistem adalah merancang atau mendesain suatu sistem yang baik, yang isinya adalah langkah-langkah operasi dalam proses pengolahan data dan prosedur untuk mendukung operasi sistem.

- Pengujian

Pengujian adalah sebuah ujicoba kasus yang baik adalah yang memiliki probabilitas yang tinggi dalam menemukan kesalahan-kesalahan yang belum terungkap.

- Implementasi Sistem

Implementasi Sistem adalah tahap dimana sistem yang telah dirancang pada tahap sebelumnya diterapkan, berupa perangkat lunak maupun perangkat keras yang digunakan. Dengan penerapan sistem yang dirancang, hasilnya dapat dioperasikan dan digunakan secara optimal sesuai kebutuhan.

Software Configuration Management (SCM)

Pengertian

• Serangkaian aktifitas penelusuran dan pengendalian yang dimulai ketika proyek dimulai sampai software tidak dioperasikan lagi

Tujuan SCM

• Mengidentifikasi perubahan

• Mengontrol perubahan

• Memastikan perubahan yang telah diimplementasikan

Kategori output

• Program komputer untuk sumber dan dieksekusi

• Dokumen untuk praktisi teknis dan pemakai

• Data yang diisi kedalam program dan keluaran dari program

Sumber perubahan mendasar

• Kondisi pasar

• Tuntutan pelangan

• Reorganisasi/perubahan struktur tim pengembang

• Redefenisi sistem atau produk

Configuration Management (CM)

• Versi baru perangkat lunak dibuat karena ada perubahan:

– Sistem operasi yang berbeda pada mesin;

– Adanya perubahan pada kemampuan (menawarkan kemampuan yang berbeda)

– Untuk kebutuhan tertentu.

• Kaitan-kaitan CM untuk memenej pengembangan perangkat lunak meliputi:

– Penggantian sistem pada sebuah aktifitas tim;

– Bertujuan untuk mengontrol biaya dan melibatkan membuat perubahan pada sistem.

– Melibatkan standar dan prosedur pengembangan aplikasi untuk memenej pengembangan perangkat lunak.

– Merupakan bagian dari proses manajemen kualitas.

– Hubungan CM, sistem perangkat lunak disebut juga baselines sebagai titik awal untuk mengembangkan lebih anjut.

– Merupakan sebuah konsep manajemen konfigurasi perangkat lunak untuk mengontrol perubahan selama perubahan masih dapat dibenarkan

Standarisasi CM

• CM selalu berdasarkan kepada standar yang diaplikasikan didalam sebuah organisasi.

• Standar didefenisikan bagaimana item-item diidentifikasikan, bagaimana perubahan dikendalikan dan bagaimana memenej

versi yang baru.

• Standar external yang mungkin mempengaruhi seperti: standar IEEE.

• Beberapa standar menerapkan proses pengembangan seperti\ model air terjun (waterfall), standar CM yang baru membutuhkan pengembangan yang evolusioner

Frequent system building

• Memudahkan untuk menemukan masalah yang berasal dari interaksi komponen dimulai awal proses.

• Sebuah proses manajemen perubahan yang diperlukan untuk menelusuri masalah yang telah ditemukan dan diperbaiki.

Perencanaan CM

• Seluruh produk proses perangkat lunak mempunyai :

– Spesifikasi;

– Disain;

– Program-program;

– Test data;

– User manuals.

• Semakin komplek sistem perangkat lunak, semakin banyak dokumen-dokumen yang diperlukan dan perlu dibuat pemisahan ( layaknya modul-modul ).

Konfigurasi Data base

• Seluruh informasi CM harus di maintenence di dalam sebuah konfigurasi data base.

• Database ( db ) CM terutama dihubungkan untuk pengaturan perangkat lunak

Implementasi Db CM

• Menjadi bagian dari sebuah lingkungan terpadu untuk mendukung pengembangan perangkat lunak.

- Db CM dan dokumen yang tertata seluruhnya dimainten pada sistem yang sama.

• Case tool terintegrasi dengan Db CM, sehinga memiliki hubungan erat antara CASE Tool dan CM Tool.

• Secara umum, dB CM dirawat secara terpisah sebagai bagian yang lebih fleksibel dan murah.

Manajemen Perubahan

• Sistem perangkat lunak tunduk kepada perubahan yang berkelanjutan, kebutuhan perubahan berasal

dari:

– User.

– Pengembang.

– Kekuatan pangsa pasar.

• Manajemen perubahan mempunyai kaitan dengan pengawasan bahwa perubahan telah diterapkan

dengan cara yang lebih hemat dan efektif.

Manajemen versi dan release

• Membuat suatu rencana versi sistem perangkat lunak.

• Rencanakan ketika suatu sistem dibuat versi yang baru.

• Pastikan prosedur manajemen versi dan tool diterapkan dengan baik.

• Rencanakan dan distribusikan release sistem yang baru.

Version/Variant/Release

• Version merupakan instansiasi dari sebuah sistem dimana secara fungsional berbeda cara

dengan sistem yang lain.

• Variant merupakan instansiasi dari sebuah sistem dimana identik secara fungsional tetapi

non-fungsional berbeda dengan sistem yang lain.

• Release merupakan sebuah instansiasi dari sebuah sistem yang telah didistribusikan ke user (pengguna) berada diluar lingkungan tim pengembang.

Identifikasi Versi

• Prosedur untuk identifikasi versi perlu menggambarkan suatu cara yang jelas untuk

menjelaskan versi komponen yang ada.

• Ada tiga teknik dasar untuk mengidentifikasi komponen:

– Penomoran versi;

– Identifikasi berdasarkan atribut;

– Identifikasi berorientasikan perubahan.

Penomoran versi

• Rencanakan penamaan yang sederhanamenggunakan secara linear V1, V1.1, V1.2, V2.1,V2.2 dan lain-lain.

• Struktur asal secara aktual merupakan sebuahpohon atau sebuah jaringan yang dibandingkan secara urutan sequence).

• Nama-nama tidak mengandung arti.

• Rencana penamaan secara hirarki mengarahkankearah yang lebih sedikit kesalahan didalam versi yang telah diidentifikasi.

Identifikasi BerdasarkanAtribut

• Atribut dapat dihubungkan dengan sebuah versi yang dikombinasikan atribut-atribut yang telah diindentifikasikan,

• Seperti: atribut tanggal, creator (pencipta), bahasa pemograman, pelanggan, status dan lain-lain.

• Lebih fleksibel dari skema penamaan yang eksplisit untuk pengembalian versi; bagaimanapun dapat meyebabkan permasalahan-permasalahan yang unik, serangkaian atribut yang dipilih untuk seluruh versi dapat dikenali dengan keunikkannya.

• Didalam prakteknya, sebuah versi juga membutuhkan sebuah nama ysng dihubungkan untuk memudahkan referensi

Identifikasi berorientasi perubahan

• Integrasi versi dan perubahan membuat perubahan versi awal.

• Digunakan untuk sistem dibandingkan komponen.

• Masing-masing usulan perubahan telah emiliki penjelasan untuk dimplementasikan.

• Perubahan diaplikasikan secara prinsip dalam sebuah versi sistem.

TOOLS SCM

• Briefcase toolkit

• Emacs

• Aegis

• BCS

• CVS

• ICE

• ODE

• dll

Strategi Pengujian Perangkat Lunak

STRATEGI PENGUJIAN PERANGKAT LUNAK

Digunakan untuk mengintegrasikan metode-metode perancangan kasus pengujian perangkat lunak menjadi suatu langkah-langkah terencana dengan tujuan mendapatkan perangkat lunak yang sukses. Setiap strategi pengujian perangkat lunak harus meliputi perencanaan pengujian, perancangan kasus-kasus uji, eksekusi pengujian, pengumpulan data,serta evaluasi. 

Pengujian unit program 

Pengujian difokuskan pada unit terkecil dari suatu modul program. Dilaksanakan denganmenggunakan driver dan stub. Driver adalah suatu program utama yang berfungsimengirim atau menerima data kasus uji dan mencetak hasil dari modul yang diuji. Stubadalah modul yang menggantikan modul sub-ordinat dari modul yang diuji.

2. Pengujian integrasi

Pengujian terhadap unit-unit program yang saling berhubungan (terintegrasi) denganfokus pada masalah interfacing. Dapat dilaksanakan secara top-down integration atau bottom-up integration.

3. Pengujian validasi

Pengujian ini dimulai jika pada tahap integrasi tidak ditemukan kesalahan. Suatu validasidikatakan sukses jika perangkat lunak berfungsi pada suatu cara yang diharapkan oleh pemakai.

4. Pengujian sistem

Pengujian yang dilakukan sepenuhnya pada sistem berbasis komputer.

• Recovery testing

Pengujian dilakukan dimana sistem diusahakan untuk gagal, kemudian diujinormalisasinya.

• Security testing

Dilakukan untuk menguji mekanisme proteksi

• Stess testing

Pengujian yang dirancang untuk menghadapkan suatu perangkat lunak kepada situasiYang tidak normal.

Pengujian Perangkat Lunak Berorientasi Objek

Pemrograman berorientasi objek (object-oriented programming disingkat OOP) merupakan paradigma pemrograman yang berorientasikan kepada objek. Semua data dan fungsi di dalam paradigma ini dibungkus dalam kelas-kelas atau objek-objek. Bandingkan dengan logika pemrograman terstruktur. Setiap objek dapat menerima pesan, memproses data, dan mengirim pesan ke objek lainnya.

Model data berorientasi objek dikatakan dapat memberi fleksibilitas yang lebih, kemudahan mengubah program, dan digunakan luas dalam teknik piranti lunak skala besar. Lebih jauh lagi, pendukung OOP mengklaim bahwa OOP lebih mudah dipelajari bagi pemula dibanding dengan pendekatan sebelumnya, dan pendekatan OOP lebih mudah dikembangkan dan dirawat.

Pemrograman orientasi-objek menekankan konsep berikut:

* kelas — kumpulan atas definisi data dan fungsi-fungsi dalam suatu unit untuk suatu tujuan tertentu. Sebagai contoh ‘class of dog’ adalah suatu unit yang terdiri atas definisi-definisi data dan fungsi-fungsi yang menunjuk pada berbagai macam perilaku/turunan dari anjing. Sebuah class adalah dasar dari modularitas dan struktur dalam pemrograman berorientasi object. Sebuah class secara tipikal sebaiknya dapat dikenali oleh seorang non-programmer sekalipun terkait dengan domain permasalahan yang ada, dan kode yang terdapat dalam sebuah class sebaiknya (relatif) bersifat mandiri dan independen (sebagaimana kode tersebut digunakan jika tidak menggunakan OOP). Dengan modularitas, struktur dari sebuah program akan terkait dengan aspek-aspek dalam masalah yang akan diselesaikan melalui program tersebut. Cara seperti ini akan menyederhanakan pemetaan dari masalah ke sebuah program ataupun sebaliknya.

* Objek – membungkus data dan fungsi bersama menjadi suatu unit dalam sebuah program komputer; objek merupakan dasar dari modularitas dan struktur dalam sebuah program komputer berorientasi objek.

* Abstraksi – Kemampuan sebuah program untuk melewati aspek informasi yang diproses olehnya, yaitu kemampuan untuk memfokus pada inti. Setiap objek dalam sistem melayani sebagai model dari “pelaku” abstrak yang dapat melakukan kerja, laporan dan perubahan keadaannya, dan berkomunikasi dengan objek lainnya dalam sistem, tanpa mengungkapkan bagaimana kelebihan ini diterapkan. Proses, fungsi atau metode dapat juga dibuat abstrak, dan beberapa teknik digunakan untuk mengembangkan sebuah pengabstrakan.

* Enkapsulasi – Memastikan pengguna sebuah objek tidak dapat mengganti keadaan dalam dari sebuah objek dengan cara yang tidak layak; hanya metode dalam objek tersebut yang diberi ijin untuk mengakses keadaannya. Setiap objek mengakses interface yang menyebutkan bagaimana objek lainnya dapat berinteraksi dengannya. Objek lainnya tidak akan mengetahui dan tergantung kepada representasi dalam objek tersebut.

* Polimorfisme melalui pengiriman pesan. Tidak bergantung kepada pemanggilan subrutin, bahasa orientasi objek dapat mengirim pesan; metode tertentu yang berhubungan dengan sebuah pengiriman pesan tergantung kepada objek tertentu di mana pesa tersebut dikirim. Contohnya, bila sebuah burung menerima pesan “gerak cepat”, dia akan menggerakan sayapnya dan terbang. Bila seekor singa menerima pesan yang sama, dia akan menggerakkan kakinya dan berlari. Keduanya menjawab sebuah pesan yang sama, namun yang sesuai dengan kemampuan hewan tersebut. Ini disebut polimorfisme karena sebuah variabel tungal dalam program dapat memegang berbagai jenis objek yang berbeda selagi program berjalan, dan teks program yang sama dapat memanggil beberapa metode yang berbeda di saat yang berbeda dalam pemanggilan yang sama. Hal ini berlawanan dengan bahasa fungsional yang mencapai polimorfisme melalui penggunaan fungsi kelas-pertama.

* Inheritas- Mengatur polimorfisme dan enkapsulasi dengan mengijinkan objek didefinisikan dan diciptakan dengan jenis khusus dari objek yang sudah ada – objek-objek ini dapat membagi (dan memperluas) perilaku mereka tanpa haru mengimplementasi ulang perilaku tersebut (bahasa berbasis-objek tidak selalu memiliki inheritas.)



REPORT THIS AD

* Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sebagai contoh anggap kita memiliki sebuah departemen yang memiliki manager, sekretaris, petugas administrasi data dan lainnya. Misal manager tersebut ingin memperoleh data dari bag administrasi maka manager tersebut tidak harus mengambilnya langsung tetapi dapat menyuruh petugas bag administrasi untuk mengambilnya. Pada kasus tersebut seorang manager tidak harus mengetahui bagaimana cara mengambil data tersebut tetapi manager bisa mendapatkan data tersebut melalui objek petugas adminiistrasi. Jadi untuk menyelesaikan suatu masalah dengan kolaborasi antar objek-objek yang ada karena setiap objek memiliki deskripsi tugasnya sendiri.

1. Unit Testing

Pada konteks pengujian (testing) perangkat lunak berorientasi objek, unit terkecil yang dapat diuji adalah encapsulation dari class atau object, bukannya modul per modul. Sebuah class dapat mengandung sejumlah operasi yang berbeda-beda, dan operasi khusus yang mungkin melibatkan sejumlah class lainnya. Dengan demikian class testing untuk perangkat lunak berorientasi objek ini setara dengan unit testing untuk perangkat lunak konvensional, dimana class testing ini dikendalikan oleh encapsulation operasi-operasi dari class dan prilaku keadaan (state behavior) dari class.

2. Integration Testing

Seperti halnya unit testing, integration testing untuk perangkat lunak berorientasi objek berbeda dengan perangkat lunak konvensional. Ada dua macam strategi untuk pengujian dari sistem berorientasi objek (OO systems), yakni thread-based testing dan use-based testing.
Thread-based testing mengintegrasikan sekumpulan class yang dibutuhkan untuk merespon sebuah input atau event yang diberikan kepada sistem. Setiap thread diintegrasikan dan diuji secara individual. Regression testing digunakan untuk memastikan tidak ada efek samping yang muncul.
Use-based testing dimulai dengan membangun sistem dengan menguji class-class (yang disebut independent classes) yang menggunakan beberapa server class. Setelah independent classes diuji, lapisan (layer) berikutnya dari class-class tersebut (yang disebut dependent classes) yang menggunakan independent classes diuji.Rangkaian lapisan (layer) pengujian dari dependent classes ini diuji sampai keseluruhan sistem dibangun. Tidak seperti integrasi konvensional, selama memungkinkan, penggunaan driver dan stubs sebagai operasi pengganti diabaikan.

3. Validation Testing

Pada validasi atau level sistem, detail dari hubungan class tidak ditampakkan. Seperti halnya validasi pada perangkat lunak berorientasi objek, validasi difokuskan pada aksi user yang tampak dan output dari sistem yang dapat dibaca user. Metoda black-box testing dapat digunakan untuk mengendalikan pengujian validasi.

Object Oriented Testing

Untuk melakukan testing sistem OO (Object Oriented) yang mencukupi, harus dilakukan tiga hal berikut:

a. definisi testing harus diperluas untuk mencakup teknik penemuan error yang diaplikasikan ke dalam model OOA dan OOD.

b. strategi unit testing akan menjadi kurang berarti dan strategi integrasi harus berubah secara signifikan.

c. disain test case harus bertanggung jawab terhadap karakteristik unik software OO.

Kebenaran Model OOA (Object Oriented Analys) dan OOD (Object Oriented Design)

Notasi dan sintaksis digunakan untuk menggambarkan model analisa dan disain akan sangat terkait dengan metode analisa dan disain tertentu yang digunakan pada proyek.

Karenanya kebenaran sintaksis dinilai berdasarkan pada ketepatan penggunaan simbologi, dan tiap model direview untuk memastikan ketepatan konvensi pemodelan yang akan dirawat.

Selama analisa dan disain, kebenaran simantik harus dinilai berdasarkan pada pemenuhan model terhadap domain masalah yang sebenarnya.

Konsistensi Model OOA dan OOD Konsistensi model OOA dan OOD dinilai dengan memperhatikan hubungan antar entitas dalam model.
Untuk menilai konnsistensi, tiap class dan koneksinya dengan class lain harus diperiksa. Model Class-Responsibility-Colaboration dan diagram hubungan obyek dapat digunakan untuk membantu aktivitas ini. Model CRC berupa kartu berindex, yang tersusun dari nama class, tipe class, karakteristik class, tanggung jawab class (operasi yang ada), dan kolaborator-nya (class-class lain yang mengirim pesan dan yang bergantung pada pemenuhan tanggung jawabnya).

Disain Test Case untuk Software OO

Ada beberapa pendekatan menurut Berard :

– Setiap test case harus secara unik diidentifikasikan dan harus secara explisit diasosiasikan dengan class yang akan ditest.

– Tujuan dari test case harus telah ditentukan.

– Daftar langkah – langkah test harus dibangun dan berisi:

– Daftar dari status object yang akan ditest.

– Daftar dari message dan operasi yang akan diperiksa sebagai konsekuensi dari test case.

– Daftar perkecualian yang mungkin terjadi dari obyek yang dites.

– Daftar kondisi external (perubahan yang terjadi pada lingkungan external yang harus ada pada software agar dapat dites)

– Informasi pendukung yang akan digunakan untuk membantu pemahaman atau pengimplemenntasian dari tes.

Unit Testing dalam Kontek OO

Enkapsulasi menentukan definisi dari class dan obyek.
Unit testing tidak melakukan tes pada tiap modul secara individual, namun unit terkecil yang dites adalah class atau obyek yang di-enkapsulasi.
Dalam OO kita tak dapat melakukan tes operasi tunggal dalam suatu isolasi, tapi harus dalam bagian dari class.

Testing class untuk software OO sama dengan unit testing untuk software konvensional

Tak seperti testing software konvensional, yang cenderung berfokus pada detil algoritma dari modul dan aliran data sepanjang interface modul, testing class untuk software OO ditentukan oleh operasi dari class yang dienkapsulasi dan tingkah laku dari class.

Integration Testing dalam Kontek OO

Karena software OO tidak mempunyai struktur kendali dalam bentuk hirarkhi, strategi integrasi konvennsional (top-down / bottom-up integration) menjadi tak berarti.

Ada 2 strategi untuk testing integrasi dari sistem OO, yaitu:

– Thread-based Testing, mengintegrasikan sekumpulan class yang dibutuhkan dalam merespon satu input atau event terhadap sistem. Tiap thread diintegrasikan dan dites secara individual.

– Used-based Testing, memulai konstruksi dari sistem dengan melakukan testing class-class (disebut independent class) yang menggunakan sangat sedikit (jika ada) class server. Setelah itu dilanjutkan dengan melakukan testing terhadap dependent class yang menggunakan independent class yang telah dites. Proses testing berlanjut terus hingga keseluruhan sistem selesai dikonstruksikan.

Cluster Testing adalah suatu langkah dalam testing integrasi dalam software OO. Disini, suatu kluster mengkolaborasi class (ditentukan oleh CRC dan model hubungan obyek) diperiksa dengan mendisain test cases yang dapat untuk menemukan error dalam kolaborasi.

Validation Testing dalam Kontek OO
Seperti pada validasi software konvensional, validasi software OO berfokus pada aksi user dan output dari sistem. Test cases dapat diturunkan dari model tingkah laku obyek dan dari diagram alur kejadian (event) yang dibuat sebagai bagian dari OOA.

Re- testing on Inheritance (Regression testing of Classes)
Dalam teori testing ulang, suatu fungsi yang tidak diubah setelah diturunkan, adalah tidak perlu. Fitur class yang sudah ditest perlu ditest ulang pada class yang menurunkannya. Dalam hal ini karakteristik yang sudah ditest sebelumnya kemudian di modifikasi pada turunannya memerlukan test case yang berbeda.
Berapa banyak re- test diperlukan? Jawaban tergantung pada spesifik risk vs economic tradeoff dari subclass yang menurunkan object.

Beberapa superclass mungkin tidak dipengaruhi oleh perubahan dalam class yang diturunkannya.

Random testing
-Identifikasi operasi yang dapat digunakan pada class
-Definisikan constrain yang mungkin terjadi
-Identifikasi minimum test sequence, sequence yang mungkin terjadi definisikan secara minimum dalam sejarahnya
-Jalankan berbagai macam test sequence secara random, terutama class instance yang mempunyai sejarah yang kompleks

Partitioning testing
Menghemat banyak test case yang dibutuhkan oleh class yang banyaknya sama partitioning dalam konvensional software

State based testing
Kategori dan operasi test yang berjalan tergantung pada kemampuan dari class untuk berubah. Masalah yang mungkin terjadi:
-Testing harus dapat memberikan semua report yang ada dan dapat diakses oleh internal state dari object itu sendiri
-Informasi hiding : keadaan ini secara tidak langsung dapat diakses, tetapi dapat diakses jika class itu sudah di public.

Pengujian Aplikasi Berbasis Web

1. APLIKASI BERBASIS WEB (WEB APPLICATION)

Aplikasi berbasis WEB (WEB Application) adalah sebuah aplikasi yang diakses melalui internet maupun intranet (Anonim, 2010). Aplikasi ini dibangu menggunakan bahasa pemrograman WEB (HTML, PHP, Javascript dan lain-lain).

WEB Application menjadi populer dikarenakan banyak pengguna yang menggunakan jaringan internet dalam sehari-harinya. Pengguna menggunakan aplikasi yang biasa disebut WEB browser untuk mengakses internet. WEB browser memberi kemudahan kepada pengguna dalam mengakses aplikasi berbasis WEB. Pengguna tidak membutuhkan spesifikasi komputer yang tinggi untuk dapat mengakses aplikasi berbasis WEB.

Aplikasi berbasis WEB ini dianggap lebih praktis daripada aplikasi biasa, karena pengguna tidak perlu menginstal aplikasi di setiap komputer. Aplikasi berbasis WEB cukup terinstal pada sebuah komputer server. Berikut ini beberapa perbedaan antara aplikasi berbasis WEB dengan aplikasi biasa, diantaranya adalah : 

Aplikasi berbasis web hanya memerlukan satu host / server dimana aplikasi tersebut diinstall, user yang banyak, sebagai client dapat menggunakan aplikasi tersebut melalui browser. 

Aplikasi berbasis web bersifat cross-platform (platform independent), karena dapat diakses melalui berbagai sistem operasi (Windows, Linux, MacOS). 

2. LANGKAH-LANGKAH PENGUJIAN APLIKASI BERBASIS WEB

Pengujian terhadap aplikasi berbasis WEB perlu dilakukan sebelum aplikasi tersebut digunakan. Pengujian merupakan salah satu bagian yang paling penting dalam jaminan kualitas aplikasi. Pengujian ini dilakukan untuk menemukan beberapa kesalahan yang disebabkan oleh proses perancangan maupun proses implementasi yang belum benar.

Biasanya sebuah pengujian dilakukan oleh sekelompok tim yang sudah teroganisir. Dalam pengujian aplikasi berbasis WEB ini tim tersebut akan menyusun beberapa langkah. Menurut Krishen Kota terdapat 10 langkah dalam pengujian aplikasi berbasis WEB diantaranya adalah :

1. Menentukan Sasaran Pengujian (Objective)

Sebelum melakukan sebuah pengujian kita harus menentukan beberapa sasaran pengujian, agar pengujian yang akan dilakukan terarah. Sehingga seorang penguji dapat menentukan beberapa prioritas pengujian dalam sebuah pengujian aplikasi.

2. Menentukan Proses dan Pelaporan Pengujian

Dengan menentukan proses pengujian dan susunan pelaporan pengujian, maka setiap anggota dalam sebuah tim penguji akan mengerti aliran dari sebuah proses pengujian.

3. Memantau Hasil Pengujian (Tracking Results)

Ketika kita sudah memulai sebuah proses pengujian aplikasi, kita akan menemukan beberapa error, bug, defect, dan sebagainya. Sehingga tim penguji membutuhkan cara untuk menyimpan, mengorganisir dan mendistribusikan informasi tersebut kepada semua anggota tim penguji. Tim juga akan membutuhkan cara untuk menjaga tim agar tetap mendapat informasi status dari sebuah proses pengujian. Oleh karena itu, dalam sebuah pengujian dibutuhkan pemantauan hasil (tracking results).

4. Menentukan Area Pengujian (Environment Test)

Menentukan area pengujian disini diartikan sebagai pembagian wilayah kerja dari sebuah tim, misalkan sebuah tim penguji dibagi menjadi tiga area pengujian yaitu WEB server, database server, dan application server.

5. Pengujian Kegunaan Aplikasi (Usability Testing)

Dalam tahap usability test ini kita akan mencoba meneliti tiga aspek yang berkaitan dengan user’s experience diantaranya adalah : 

Apakah WEB application tersebut memiliki desain antarmuka yang konsisten? 

Seberapa mudahkah navigasi dari WEB application tersebut? 

Apakah feed back yang diberikan WEB application tersebut sesuai dengan keinginan pengguna? 

6. Pengujian Unit (Unit Testing)

Unit testing ini merupakan pengujian yang hanya fokus pada beberapa bagian kecil dari fungsionalitas WEB application. Misalnya menguji kebenaran dari penyimpanan data setelah pengguna menekan tombol “submit”.

7. Pengujian Kode HTML

Pengujian kode HTML ini bertujuan untuk menguji apakah aplikasi tersebut dapat dijalankan pada bermacam-macam browser, resolusi layar dan OS yang berbeda. Pengujian ini dapat dilakukan melalui http://validator.w3.org.

8. Load Testing

Pengujian ini dimaksudkan untuk mengukur seberapa lamakah sebuah halaman WEB application di-load kedalam browser milik pengguna. Pada umumnya, sebuah halaman dapat di-load kurang dari 15 detik.

9. User Acceptance Testing

Dengan melakukan pengujian ini, tim akan mengetahui apakah WEB application tersebut sudah memiliki fungsi yang sesuai dengan keinginan pengguna atau belum. Pengujian ini dapat dilakukan dengan menguji aplikasi versi Beta.

10. Pengujian Keamanan (Security Testing)

Tahap ini merupakan tahap akhir yang penting untuk mengetahui apakah WEB application tersebut sudah memiliki sistem keamanan yang baik atau belum. Kita juga harus menguji apakah WEB application tersebut aman terhadap serangan dari dalam maupun luar sistem.

3. KESIMPULAN

Pengujian adalah salah satu instrumen yang paling penting dalam pengembangan aplikasi Web untuk mencapai produk-produk berkualitas tinggi yang memenuhi harapan pengguna. Metode dan pengujian sistematis dari aplikasi Web adalah tindakan penting yang diberikan penekanan khusus dalam jaminan kualitas.Pengujian juga dapat diartikan sebagai suatu proses yang dapat menentukan apakah aplikasi WEB tersebut sudah layak untuk diluncurkan atau belum. Aplikasi WEB tersebut harus melalui beberapa tahapan pengujian, sebelum diluncurkan kepada semua pengguna.

Pengujian Aplikasi Konvesional

pengujian aplikasi konvensional

– Filosofi pengujian yang harus ditanamkan pada diri pengembang “buang

jauh‐jauh anggapan benar dari PL yang telah dikembangkannya dan

berusaha untuk merancang suatu test case untuk menghancurkan PL

tersebut”

ing

tersebut

– Tujuan pengujian aplikasi konvensional : merancang serangkaian test case

yang mampu menyingkapkan kesalahan‐kesalahan.

k Testi

– Teknik pengujian haruslah :

• Memperlihatkan logika internal dan antarmuka dari setiap komponen PL

• Memperlihatkan dan dari Tekni

ranah masukan keluaran program untuk

menyingkapkan kesalahan‐kesalahan dalam fungsi, perilaku dan kinerja

program.

– Yang melakukan pengujian :

• Tahap awal pengujian : rekayasawan PL

• Saat proses pengujian berlangsung : spesialis pengujian (tester)

– Secara umum langkah‐langkah pengujian dipandang dari dua sudut pandang

berbeda :

• Logika program internal diuji dengan teknik perancangan test case White Box

(kotak putih)

ing

• Kebutuhan PL uji menggunakan teknik perancangan test case Black Box (kotak

hitam)

k Testi

Use case membantu perancangan pengujian, yaitu membantu menyingkapkan

kesalahan‐kesalahan di tingkat validasi PL.

Pada setiap kasus tujuannya adalah menemukan sebanyak mungkin kesalahan

Tekni

dengan sesedikit mungkin waktu dan usaha.

– Test case dirancang untuk menguji logika internal, antarmuka, kolaborasi

komponen‐komponen dan menguji kebutuhan eksternal yang telah

dirancang dan didokumentasikan, hasil‐hasil yang diharapkan yang telah

ditetapkan dan hasil hasil dicatat

Dasar‐dasar Pengujian

Kemampuan sebuah program komputer, untuk diuji (testability)

meliputi :

– Operability (kemampuan untuk bisa dioperasikan), “semakin baik

kinerjanya, semakin efisien PL untuk bisa diuji”

– Observability (kemampuan untuk bisa diobservasi), “apa yang dilihat adalah

apa yang diuji”

– Controllability (kemampuan untuk dapat dikontrol) “ semakin Tekni

dikontrol), baik PL

dikontrol, semakin pengujian dapat diotomatisasi dan dioptimalkan”

– Decomposability (kemampuan untuk dapat diusun), “dengan mengontrol

ruang lingkup pengujian, maka pengisolasian masalah dapat cepat dilakukan

dan pengujian ulang dapat dilakukan dengan lebih cerdas”

– Simplicity (kesederhanaan), “semakin sedikit yang diuji, semakin cepat

dapat mengujinya”

– Stability (stabilitas), “ makin sedikit perubahan, semakin sedikit gangguan

untuk pengujian”

– Understability (kemampuan untuk dapat dipahami), “semakin banyak

informasi yang dimiliki semakin cerdas pengujiannya”

Karakteristik Pengujian :

– Pengujian yang baik memiliki probabilitas tinggi untuk

   menemukan kesalahan

– Pengujian yang baik tidak berulang‐ulang

– Pengujian yang baik harus menjadi “bibit terbaik”

– Pengujian yang baik harus tidak terlalu sederhana atau terlalu

   rumit

Teknik Pengujian Perangkat Lunak

TEKNIK PENGUJIAN PERANGKAT LUNAK

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

Dasar­-dasar Pengujian Perangkat Lunak

Pengembang perangkat lunak sesuai dengan sifatnya dasar mereka adalah manusia pembangun. Pengujian mengharuskan pengembang membuang pemikiran­pemikiran sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja dikembangkan dan mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan.

Sasaran Pengujian

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 dadalah pengujian yang mengungkapkan semua kesalahan yang belum pernah ditemukan sebelumnya.

Prinsip Pengujian

1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.

2. Pengujian harus direncanakan lama sebelum pengujian itu mulai.

3. Prinsp Pareto berlaku untuk pengujian perangkat lunak.

4. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian “yang besar”

5. Pengujian yang mendalam tidak mungkin.

6. Untuk menjadi paling efektif, pengujian hars dilakukan oleh pihak ketiga yang independen.


Karakteristik yang membawa perangkat lunak dapat diuji :

1.Operabilitas, Semakin baik dia bekerja, semakin efisien dia dapay diuji.

2. Obsaikervabilitas, “Apa yang anda lihat adalah apa yang anda uji”.

3.Kontralabilitas, “Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.

4.Dekomposabilitas, “Dengan mengontrol ruang lingkup pengujian, kita dapat dengen lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus”.

5.Kesederhaaan, “Semakin sedikit yang kita uji, semakin cepat kita dapat mengujinya’>

6.Stabilitas, “Semakin sedikit perubahan, semakin sedikit gangguan dalam pengujian’.

7.Kemampuan untuk dapat dipahami, “Semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan’.

Atribut-­atribut pengujian yang baik :

1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan.

2. Pengujian yang baik tidak redudan.

3. Pengujian yang baik seharusnya “jenis terbaik”,

4. Pengujian yang tidak boleh terlalu sederhana atau terlalu kompleks.

DESAIN TEST CASE
Desain test case merupakan metode pengujian untuk perangkat lunak untuk memastikan kelengkapan pengujian
dan memberikan kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat lunak.

Semua produk yang direkayasa dapat diuji dengan satu atau dua cara :

1. Dengan mengetahui fungsi yang ditentukan dimana produk yang dirancang untuk melakukanya, pengujian dapat dilakukan untuk memperlihatkan bahwa masing­masing fungsi beroperasi sepenuhnya, pada waktu yang sama mencari kesalahan pada setiap fungsi.

2. Dengan mengetahui kinerja internal suatu produk, maka pengujian dapat dilakukan untuk memastikan bahwa semua roda gigi berhubungan, yaitu operasi internal bekerja sesuai dengan spesifikasi dan semua komponen internal telah diamati dengan baik.


PENGUJIAN WHITE BOX

·Pengujian White Box adalah metode desain test case yang menggunakan struktur control desain procedural untuk memperoleh test case.

·Disebut juga pengujian glass­box.

·Dengan pengujian white­box, perekayasa dapat melakukan :

1.Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kali.

2.Menggunakan semua keputusan logis pada sisi true and false.

3.Mengeksekusi semua loop pada batasan mereka dan pada batas operasional mereka.

4.Menggunakan struktur data internal untuk menjamin validitasnya.

PENGUJIAN BASIS PATH

Pengujian basis path memungkinkan desain test case mengukur kompleksitas logiss dari desain procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi. Test case yang dilakukan untuk menggunakan basis set tersebut dijamin untuk menggunakan setia statemen di dalam program paling tidak sekali selama pengujian.
Notasi Diagram Alir
Diagram Alir atau grafik program menggambarkan aliran control logika.

Kompleksitas Siklomatis
Kompleksitas Siklomatis adalah metric perangkat lunak yang memberikan pengukuran kuantitaif terhadap kompleksitas logis suatu program.
Kompleksitas Siklomatis menentukan jumlah jalur independen dalam basis set suatu program dan memberikan batas atas bagi jumlah pengujian yang harus dilakukan untuk memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali.
Jalur independen adalah jalur yang melalui program yang mengintroduksi sedikitnya satu rangkaian statemen proses baru atau suatu kondisi baru.


Melakukan Test Case

1.Dengan menggunakan desain atau kode sebagai dasar, gambarkan sebuah grafik alir yang sesuai.

2.Tentukan kompleksitas siklomatis dari grafik alir resultan.

3.Tentukan sebuah basis set dari jalur independen secara linier.

4. Siapkan test case yang akan memaksa adanya eksekusi setiap basis set.

Matrik Grafis
·Matrik grafis adalah matriks bujur sangkar yang ukurannya sama dengan jumlah simpul pada grafik alir.
·Masing­masing baris dan kolom sesuai dengan yang diidentifikasi kan, dan entri matriks sesuai dengan edge di antara simpul.

PENGUJIAN STRUKTURAL KONTROL

- Pengujian Kondisi
- Pengujian Aliran Data
- Pengujian Loop


PENGUJIAN BLACK­BOX
v Pengujian black­box berfokus pada persyaratan fungsional perangkat lunak.
v Disebut juga pengujian behavioral atau pengujian partisi.

v Pengujian black­box memungkinkan perekayasa perangkat lunak mendapatkan serangkaian input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu program.

v 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.

v Dengan mengaplikasikan teknik black­box maka kita menarik serangkaian test case yang memenuhi criteria beirkut :

·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.
vMetode Pengujian Graph­Based
v Partisi Ekivalensi
o Input data dan output hasil terdapat di klas yang berbeda yang sesuai
dengan klas inputnya.
o Masing‐masing klas eqivalensi partition diproses dimana program akan memproses anggota klas‐klas tersebut secara equivale.
o Test case dipilih dari masing‐masing partisi
v Analisis Nilai Batas

Dasar - Dasar Pengujian Perangkat Lunak

Dasar-dasar Pengujian Perangkat Lunak (Software)

Pengujian perangkat lunak merupakan suatu investasi yang dilakukan untuk mendapatkan informasi mengenai kualitas dari produk atau layanan yang sedang diuji. Tujuannya untuk memberikan pandangan secara objektif dan independen yang bermanfaat dalam operasional bisnis untuk memahami tingkat resiko pada implementasinya. Pengujian perangkat lunak merupakan tahapan penting dalam pembangunan perangkat lunak.

Pengujian dilakukan dengan cara evaluasi konfigurasi (pembentukan susunan) yang terdiri dari :
- Spesifikasi kebutuhan
- Deskripsi perancangan
- Program yang dihasilkan

Hasil dari evaluasi konfigurasi kemudian dibandingkan dengan hasil uji yang diharapkan. Dan berusaha membangun perangkat lunak dari konsep abstrak ke implementasi yang dapat dilihat atau baru melakukan pengujian.


Sasaran-sasaran Pengujian Perangkat Lunak

Pengujian perangkat lunak memiliki aturan yang berfungsi sebagai sasaran. Yaitu :
1. Pengujian : yaitu proses eksekusi suatu program dengan maksud menemukan kesalahan.
2. Test Case : yaitu sekumpulan dari input test atau kondisi yang akan diuji. Kondisi yang baik adalah yang memiliki probabilitas tinggi untuk menentukan kesalahan yang belum pernah ditentukan sebelumnya.
3. Pengujian yang sukses : yaitu pengujian yang mengungkap semua kesalahan yang belum pernah ditentukan sebelumnya.

Prinsip-prinsip Pengujian Perangkat Lunak

- Semua pengujian harus dapat ditelusuri sampai kepada persyaratan pelanggan.
- Pengujian harus direncanakan jauh hari sebelum rencana itu dimulai.
- Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yang ditemukan akan dapat ditelusuri      dari semua modul program.
- Dimulai dari hal yang kecil dan berkembang ke arah pengujian yang lebih besar.
- Harus dilakukan oleh pihak ketiga yang independent untuk perangkat lunak yang paling efektif.


Proses Testing

1. System Testing : Pengujian terhadap integrasi sub sistem, yaitu ketehubungan antar sub sistem.
2. Acceptance Testing : Pengujian terakhir sebelum sistem dipakai oleh user, melibatkan pengujian dengan data dari pengguna sistem. Dikenal sebagai Alpha test (beta test untuk perangkat lunak komersial yang dilakukan oleh potensial customer).
3. Unit testing : Pengujian yang masing-masing unit komponen program untuk memastikan bahwa program sudah dijalankan secara benar.
4. Module Testing : Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan.
5. Sub System Testing : Pengujian terhadap koleksi modul-modul yang membentuk sub sistem.
6. System Testing : Pengujian terhadap keterhubungan sub sistem.


The Testing Process

1. Component Testing : Pengujian komponen-komponen program, biasanya dilakukan oleh component developer (kecuali untuk sistem kritis).
2. Integration Testing : Pengujian kelompok komponen yang terintegrasi untuk membentuk sub sistem ataupun sistem yang dilakukan oeh tim penguji yang independent. Pengujian dilakukan berdasarkan spesifikasi sistem.

Rencana Pengujian

1. Proses Testing
- Deskripsi fase-fase utama dalam pengujian.
2. Pelacakan Kebutuhan
- Semua kebutuhan user diuji secara individu.
3. Item yang Diuji
- Menspesifikasi komponen sistem yang diuji.
4. Jadwal Testing
5. Prosedur Pencatatan Hasil dan Prosedur
6. Kebutuhan akan Hardware dan Software

Hubungan antara rencana pengujian dan proses pengembanganan sistem