Tahapan dalam developmen software

Pada artikel sebelumnya kita telah sedikit mengulas tentang Pengujian Perangkat Lunak (software testing) selanjutnya pada kesempatan posting kali ini kita akan melanjutkan jalan cerita yang tentunya sudah tidak asing di telinga kita tentang apa itu Software Release Life Cycle, alpha, beta dan Release Candidate mari kita langsung menuju TKP...


Software Release Life Cycle adalah tahapan-tahapan dalam developmen software hingga software tersebut rilis, dapat berupa software yang baru dibuat, perbaikan bug/error atau pengembangan software.  Tahapan-tahapan ini menggambarkan seberapa stabil dan seberapa selesai software tersebut. Berikut ini adalah tahapan-tahapan Software Release Life Cycle yang disusun secara beurutan

1.Alpha

Alpha adalah status Developmen pada software yang mungkin belum terdapat seluruh fitur yang direncanakan dan belum stabil, tetapi dapat menunjukan atau memberikan gambaran dari hasil akhir sebuah software.

Versi Alpha dapat di katakan sebuah versi review yang akan di-test secara intensif oleh internal penguji/tester tetapi dapat diberikan juga pada penguji eksternal, misalkan user yang ingin mencoba versi Alpha tersebut.

Tahapan Alpha bisa berkembang dari Alpha 1, Alpha 2 dan seterusnya tergantung dari hasil pengujian dan tindakan dari hasil pengujian tersebut seperti perbaikan bug atau error, penambahan, penyesuaian dsb-nya dari software tersebut

2.Beta

Beta adalah sebuah status Developmen pada software setelah Status Alpha telah dinyatakan selesai. Beta dapat dikatakan sebuah versi software yang telah lulus test/pengujian oleh tim tester/penguji internal.

Pada versi Beta software ditujukan kepada pengguna atau calon pengguna untuk mencoba software tersebut dengan tujuan untuk mendapatkan feedback yang dialamin penggunan saat menggunakan software tersebut (seperti apakah terjadi bug, error, ribet dsb nya).

Jadi pada tahap ini proses perbaikan bug dan error masih terus dilakukan oleh pihak pembuat software dan masih dapat terjadi penambahan, penggantian, penyesuaian feature dalam skala kecil.

Tahap Beta dapat berkembang dari beta1, beta2 dan seterusnya tergantung dari hasil feedback pengguna yang berperan sebagai penguji dan Software Versi Beta tidak direkomendasikan untuk digunakan keperlukan production. Sebagai contoh Software versi beta dapat berupa Download Gratis Software Beta.

Pada umumnya Versi Beta terbagi menjadi Open Beta yang berarti secara umum siapa saja dapat mencoba versi software tersebut dan Close Beta yang artinya adalah sofware tersebut hanya dirilis untuk sekolompok individu saja yang bertujuan untuk mencoba software tersebut.

3.RC (Release Candidate)

Pada tahap ini software sudah dinyatakan stabil dan kualitasnya sudah mendekati versi final yang siap untuk di-rilis dan jual secara massal (apabila prodak massal) jadi RC semacam preview dari final release.

RC (Release Candidate) biasanya`dikeluarkan untuk untuk pengujian tambahan untuk memastikan bahwa prodak telah siap. Biasanya software pada tahapan ini sudah bisa dipakai, karena relatif lebih stabil daripada versi beta dan pada tahap RC hanya dilakukan stabilisasi saja.

Pada tahap ini dapat berfungsi sebagai persiapan sebuah software untuk menyambut versi final atau versi stabil software, Tahapan RC biasanya jarang dilakukan oleh pembuat software melainkan langsung merilis versi final setelah tahap Beta.

4. Final / Gold / Stable Release

Ini adalah tahap terakhir dari Life Cycle Software Di tahap ini software sudah dinyatakan stabil dan layak untuk digunakan secara luas. Apabila software ini adalah prodak masal maka pihak pembuat software akan mempromosikan software.

Versi final atau stable ditandai dengan penulisan versi dengan nomor tanpa ada tambahan kata Alpha, Beta maupun RC, Sebagai Contoh adalah Browser Firefox yang stable ditulis.

• Version 3.0.13
• Version 3.6.16

Apabila Software Release Life Cycle digambarkan dalam bentuk diagram maka akan tampak seperti gambar dibawah ini.

Semantic Versioning

Pada umumnya sebuah software yang rilis memiliki versi. Versi Software adalah sebuah pemberian nomor atau angka yang bersifat unik kepada sebuah software untuk menerangkan status software tersebut. 

Nomor versi software diberikan secara berurut dan meningkat mengikuti Rilis (melepaskan/mengeluarkan) software tersebut.

Dengan memberikan versi pada sebuah software akan memudahkan dalam meng-organisir source code sebuah software yang bermanfaat bagi developer maupun pengguna sofware. Dan dapat berfungsi sebagai history perkembangan sebuah software.

Misalkan sebuah sofware akutansi bernama AKSES memiliki beberapa versi 1 hingga 4 yang setiap versinya memilki kelengkapan fitur berbeda, performance berbeda, keperluan spesifik dan tentunya harga yang berbeda, dengan pemberian versi sofware tersebut akan menjadi lebih mudah di-kelolah oleh developer dan di inggat oleh pengguna software tersebut.

Versi pada sebuah Software diwakili dengan sederetan angka yang pada umum-nya terkelompokan menjadi tiga bagian, setiap bagian kelompok memiliki pengertian yang berbeda dan dipisahkan dengan simbol titik (.)

Berikut ini adalah aturan dalam membuat versi software berdasarkan Semantik versioning (SemVer)

1. Aturan Pertama 

Sebuah nomor versi software berpola X.Y.Z di mana X, Y, dan Z adalah bilangan bulat.

• X adalah versi mayor
• Y adalah versi minor
• Z versi patch

Setiap rilis maka elemen versi sofware HARUS meningkat, Sebagai contoh seperti dibawah ini

• Rilis ke 1 >> 1.0.0
• Rilis ke 2 >> 1.0.1
• Rilis ke 3 >> 1.1.1
• Rilis ke 4 >> 2.0.0

2. Aturan ke-dua

Untuk versi software dalam fase Release Life Cycle Software dapat ditambahkan dengan AlphaNumerics [0-9A-Za-z] & simbol strip dan serta diawali karakter alpha [A-Za-z], Sebagai contoh adalah sebagai berikut.

• Versi 1.0.0 Alpha ke 1 >> 1.0.0alpha1
• Versi 1.0.0 Alpha ke 2 >> 1.0.0alpha2
• Versi 1.0.0 Beta ke 1 >> 1.0.0beta1
• Versi 1.0.0 Beta ke 2 >> 1.0.0beta2

3. Aturan ke-tiga

Setelah sebuah versi software rilis maka setiap ada modifikasi dari source code software tersebut akan melahirkan rilis versi yang baru.

4. Aturan ke-empat

Angka pada versi patch harus bertambah apabila terjadi perbaikan bug/error dari sebuah versi software, sebagai contoh.

• Perbaikan bug/error di Versi 1.0 ke 1 >> 1.0.1
• Perbaikan bug/error di Versi 1.0 ke 2 >> 1.0.2
• Perbaikan bug/error di Versi 1.0 ke 3 >> 1.0.3
• Perbaikan bug/error di Versi 1.0 ke 4 >> 1.0.4

5. Aturan ke-lima

Versi minor pada versi software harus bertambah jika terdapat modul/fungsional baru yang kompatibel dengan versi mayor atau terjadi perbaikan yang besar pada versi software tersebut.

• Penambahan fungsional di Versi 1 ke 1 >> 1.1.0
• Penambahan fungsional di Versi 1 ke 2 >> 1.2.0
• Penambahan fungsional di Versi 1 ke 3 >> 1.3.0
• Penambahan fungsional di Versi 1 ke 4 >> 1.4.0

6. Aturan ke-enam

Versi mayor pada versi software harus bertambah apabila terjadi perubahan yang menyebabkan modul/fungsional yang telah ada sebelumnya menjadi tidak kompatibel, hal ini biasa terjadi apabila ada  perubahan pada kode program yang bersifat core/inti atau fundamental dari sofware tersebut.

• Perubahan core software ke 1 >> 2.0.0
• Perubahan core software ke 2 >> 3.0.0
• Perubahan core software ke 3 >> 4.0.0

source:dendieisme.blogspot.com

[Read More...]

Pengujian Perangkat Lunak

Software Testing (Pengujian Perangkat Lunak)

Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean.

Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas.

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

Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah:
Pengujian adalah
proses eksekusi suatu program dengan maksud menemukan kesalahan
Test case yang baik
adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya
Pengujian yang sukses
adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya

Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang ditemukan. Data yang dikumpulkan pada saat pengujian dilakukan memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak secara keseluruhan, tetapi ada satu hal yang tidak dapat dilakukan oleh pengujian, yaitu

pengujian tidak dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak.

Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekayasa perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:

-->semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan, maksudnya mengungkap kesalahan dari cacat yang menyebabkan program gagal.
-->Pengujian harus direncanakan lama sebelum pengujian itu mulai,
maksudnya semua pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan
-->Prinsip Pareto berlaku untuk pengujian perangkat lunak,
maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program.
-->Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”,
Selagi pengujian berlangsung maju, pengujian mengubah focus dalam usaha menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem.
-->Pengujian yang mendalam tidak mungkin
karena tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program menengah pun sangat besar.

-->Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent

Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program computer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program computer dapat diuji. Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi.

Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.

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

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

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

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

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

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

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

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

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

Baca juga tentang
Tahapan-tahapan dalam developmen software  

[Read More...]

"The following ink may have run out"

Pada artikel sebelumnya telah disinggung beberapa penyakit pada printer canon , pada kesepatan kali ini akan di bahas lebih mendalam tentang masalah yang sering muncul pada printer canon salah satunya adalah ketika kita tidak menfungsikan salah satu cartridge dengan alasan rusak dan lain sebagainya. Secara otomatis driver akan meminta memasukkan cartridge "The following ink may have run out" bila kita akan mulai mengenprint..solusinya mari kita menipu komputer dan driver printer agar tidak akan mempedulikan cartridge warna/hitam ada atau tidak,, tinta anda, apakah asli-palsu, penuh-kosong, refill-bukan..untuk lebih jelas langsung saja ke TKP

Ciri - ciri printer canon yang blinking setelah di reset adalah :

Pada saat printer dinyalakan, printer canon akan nyala dengan normal dengan indikator lampu power nyala hijau penuh.
kemudian pada saat kita mencoba untuk ngeprint, barulah muncul masalah ini, yaitu
printer canon pixma IP ... : cirinya ngeblink dengan lampu orange kedip - kedip
printer canon MP .... : cirinya keluar error E15 atau E16

Permasalahan ini di tunjukkan dengan tampilan peringatan yang bunyinya demikian
" The following ink may have run out. "
The following ink may have run out Black : berarti cartridge hitam perlu di resume / reset
The following ink may have run out Colour : berarti cartridge warna perlu di resume / reset

Pesan peringatan Printer Canon IP dan MP Blinking Setelah di Refill seperti yang ada di gambar berikut.

Cara Mengatasi Printer Canon Setelah di Refill Blinking adalah :

1. Matikan printer, cabut kabelnya dari stop kontak.
2. Tunggu sekira lima detik
3. Dengan kabel dalam keadaan tidak terpasang (tidak tercolok ke listrik) dan kabel USB tidak tersambung ke komputer/laptop , tekan dan tahan tombol power sekira tiga detik dengan jari tengah
4. Tetap tahan jari tengah anda di tombol power, tangan yang satunya mencolokkan kabel printer ke stop kontak. Lampu power akan menyala warna hijau (tidak kedap-kedip)

tekan power dengan jari tengah,tahan
5. Tetap tahan jari tengah anda. Jari telunjuk menekan tombol resume dua kali (lampu akan berganti dari hijau-orange-hijau)

6. Setelah itu, lepaskan kedua jari anda, tunggu printer hingga ready (ditunjukkan dengan lampu hijau menyala tidak putus-putus)

setelah menekan resume dua kali, lampu hijau akan menyala tidak putus-putus
7. Jika tadinya anda sudah meng-install software printer tersebut, ­anda harus menghapusnya (uninstall)
8. Hubungkan printer ke computer
9. Komputer akan men­-detect printer anda sebagai printer baru
10. Maka install kembali software printer anda. Ini bertujuan untuk ‘menipu’ komputer anda agar tidak ‘mengingat’ bahwa tinta anda adalah tinta refill atau sudah mau habis. Sebagai bukti bahwa anda berhasil ‘menipu’ komputer anda, maka klik [Start]-[Settings]-[Printers and Faxes] dan anda akan melihat tampilan ‘Copy iP 1900 series (copy 1)’. Ini tandanya bahwa anda berhasil menginstall software anda.

11. Gunakan printer seperti biasa
12. Apabila anda hendak mematikan printer, langsung saja cabut kabel powernya. Tidak usah tekan tombol apapun pada printer
13. Begitu seterusnya. Apabila anda ingin menggunakannya kembali, gunakan cara yang sama: cabut kabel-tahan power-colokkan kabel-tekan resume dua kali-gunakan.
Dengan cara seperti ini, printer tidak akan mempedulikan tinta anda, apakah asli-palsu, penuh-kosong, refill-bukan. Printer akan menge-print sesuai keinginan anda. Memang pada tampilan layar anda akan muncul tanda seru (layaknya tinta mau habis), tapi hal ini tidak usah dihiraukan.

Selamat mencoba.

[Read More...]