Prinsip Pareto dalam RPL

PENGUJIAN DAN IMPLEMENTASI PERANGKAT LUNAK

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.

   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

Sistem Pareto dalam kaitannya dengan RPL

   Dalam ilmu komputer dan teori kontrol rekayasa seperti untuk konverter energi elektromekanis, prinsip Pareto dapat diterapkan untuk upaya optimasi.  Sebagai contoh, Microsoft mencatat bahwa dengan menetapkan atas 20% paling melaporkan bug, 80% dari kesalahan dan crash akan dihilangkan.

 Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program. 

 

   Dalam pengembangan perangkat lunak proses yang khas adalah bahwa pengumpulan persyaratan, persyaratan review, desain, desain review, coding, kode review, pengujian komponen, pengujian integrasi, rilis, dan pemeliharaan. Singkatnya, proyek mulai dengan satu set persyaratan, dan kemudian pergi melalui serangkaian perbaikan dimana spesifikasi asli dibandingkan dengan produk akhir untuk kelengkapan dan kebenaran dan terhadap penggunaan dunia nyata untuk perbaikan tambahan. Selama  revisi, jika persyaratan dari proses pembangunan mengikuti distribusi Pareto, maka beberapa isu kunci akan menampakkan diri dan perlu ditangani pada setiap revisi baru. Persyaratan lama akan memudar , dan yang baru akan muncul dengan konteks mereka sendiri .

   Praktis pengalaman memberitahu kita bahwa pada awal proyek perangkat lunak masalah tersebut mencakup isu-isu tersebut pada platform pilihan, bahasa implementasi, database model data, modus akses dan fungsi utama dari aplikasi. Seiring waktu, penyempurnaan lanjutan dapat memperkenalkan persyaratan yang membahas bagaimana aplikasi bekerja untuk kelompok tertentu pengguna, atau dalam konsep dengan aplikasi eksternal lainnya.

Pertambahan manfaat open source :

    Perancang sering menggunakan prinsip pareto dalam pengelolaan  teknik desain dan pengembangan . bahwa 80 % dari proyek mudah dibandingkan dengan yang 20 % terakhir. lebih khusus lagi dalam proses formal prioritas persayaratan menggunakan analisis pareto, setiap persyaratan yang unik diberi

   Peringkat sebagai persentase dari seluruh proyek. Kebutuhan individu tersebut kemudian disajikan dalam grafik batang dari yang paling signifikan. Perusahaan perangkat lunak seperti Microsoft memahami hal ini, dan desain untuk produk yang membahas 80 persen dari persyaratan, meninggalkan 20% terakhir sebagai kustomisasi oleh pengguna akhir. Sebagian besar aplikasi saat ini telah dirancang untuk mencakup beberapa bentuk penyesuaian atau diperpanjang termasuk pengaturan preferensi pengguna, bahasa scripting atau API untuk ekstensi kustom menggunakan bahasa yang lebih tradisional. 

Ada lima  cara utama prinsip dapat diterapkan untuk pengembangan perangkat lunak dan kualitas perangkat lunak :

1.     Mengidentifikasi cacat yang paling sering terjadi sehingga mereka bisa diperbaiki. Seperti kata J.M. Juran, target banyak, bukan sedikit.  waktu dan energi untuk memperbaiki cacat ini akan memiliki keuntungan terbesar atas investasi. 

2. Mengidentifikasi cacat paling mahal berdasarkan biaya untuk memperbaiki mereka atau biaya yang dikeluarkan ketika mereka terjadi. Cacat serius yang sistem crash pengguna atau menyebabkan pengguna untuk kehilangan semua data yang paling parah, dan ini adalah cacat Anda harus menargetkan.

3.   Identifikasi kelas yang paling umum dari kesalahan. Apakah sebagian besar kesalahan hasil dari kesalahan pengetikan? Apakah sebagian besar kesalahan logis? Apakah sebagian besar cacat pada antarmuka perangkat lunak? Identifikasi jenis yang paling umum dari kesalahan dan memfokuskan upaya kualitas perangkat lunak, debugging dan pengujian di daerah itu. 

4. Menggunakan prinsip Pareto untuk mengidentifikasi ketika tingkat kecacatan telah turun di bawah titik ketika itu bernilai waktu dan usaha untuk terus mencari cacat. Banyak model pengembangan perangkat lunak, seperti model kualitas perangkat lunak yang menggunakan pembibitan untuk menghasilkan perkiraan mengenai jumlah cacat aplikasi perangkat lunak . Anda mungkin mengatakan masih ada beberapa cacat tersisa di kode. Bila Anda menghentikan pengujian? Bila Anda telah menemukan setidaknya 85% dari perangkat lunak cacat diprediksi, pengujian perangkat lunak dapat menurunkan sementara bug besar atau bug yang paling sering terjadi adalah tetap. Ketika 90% atau lebih dari perkiraan jumlah bug yang ditemukan, mungkin tidak lagi efektif.

5. Prioritaskan permintaan perubahan perangkat lunak dan perangkat tambahan berdasarkan permintaan dan kebutuhan. Pilih untuk membuat perubahan yang mewakili 80% dari keluhan pengguna, bukan yang paling mudah untuk menerapkan atau diminta oleh klien yang paling menuntut.

     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.

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

           

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.