Manajemen Versi Dan Rilis

MANAJEMEN VERSI DAN RILIS

Versi

merupakan bentuk perubahan baru bersifat signifikan dari bentuk sebelumnya. akan berbeda halnya dengan istilah Software Versioning (memberi versi perangkat lunak) yang berfokus pada proses penetapan nama atau nomor versi unik terhadap identitas perangkat lunak.

Rilis

pelepasan atau peluncuran produk perangkat lunak. Jika sebuah produk dirilis maka, produk itu sudah paten artinya telah melewati fase pengujian dan pengembangan lengkap.

Software Release Life Cycle

jumlah dari tahap pengembangan dan kematangan untuk perangkat lunak komputer: mulai dari pengembangan awal hingga rilis akhirnya, dan termasuk versi terbaru dari versi yang dirilis untuk membantu meningkatkan perangkat lunak atau memperbaiki bug perangkat lunak yang masih ada dalam perangkat lunak.

Proses Software Release Life Cycle:

Pre-Alpha

merujuk pada semua aktifitas pembuatan dan pengembangan software sebelum dilakukan testing, aktifitas ini bisa berupa analisa kebutuhan, desain perangkat lunak, pengembangan unit maupun pengujian unit software.

Alpha

Tahap pertama untuk melakukan pengujian pada software (penggunaan alpha berasal dari huruf pertama dalam sistem alfabet Yunani kuno yang diartikan sebagai angka 1). Pada tahap ini developer software biasanya melakukan pengujian terhadap software dengan menggunakan teknik bernama white box techniques. Tambahan validasi kemudian dilakukan dengan menggunakan teknik bernama black box or gray box techniques oleh tim pengujian yang lain. Perpindahan pada metode pengujian black box dalam sebuah organisasi ini disebut dengan alpha release. Software alpha bisa saja tidak stabil dan dapat menyebabkan error maupun kehilangan data, jarang sekali software pada tahap alpha tersedia secara bebas untuk publik, terkecuali digunakan untuk bonus pre-order.

Beta

Tahap pengembangan software yang mengikuti tahap alpha (penggunaan istilah beta berasal dari bahasa Yunani kuno yang diartikan sebagai angka 2). Tahap ini biasanya tahap dimana software telah memiliki fitur yang lengkap, beberapa organisasi menyebut tahap ini sebagai prototype atau technical preview. Fokus dari tahap beta adalah mengurangi dampak buruk pada pengguna, yang biasanya berupa pengujian penggunaan produk. Beta release biasanya merupakan tahap pertama sebuah perangkat lunak tersedia untuk pihak diluar pengembang software. Pengguna dari versi beta ini disebut beta tester, biasanya adalah pengguna atau calon pengguna dari produk yang ada, mau melakukan pengujian terhadap produk perangkat lunak tanpa bayaran dan biasanya menerima hasil akhir software secara cuma-cuma atau dengan pengurangan harga (untuk software berbayar). Beberapa pengembang software meluncurkan closed beta maupun open beta dimana closed beta version adalah produk yang diluncurkan untuk sekelompok orang atau grup sebagai pengguna penguji sedangkan open beta diluncurkan untuk komunitas pengguna secara umum maupun siapa saja yang tertarik. Pengguna kemudian melaporkan adanya kesalahan yang ditemukan maupun memberi saran untuk tambahan fitur yang seharusnya ada pada produk akhir 22/5/2013 5

Release Candidate

merujuk pada suatu versi perangkat lunak yang dilihat sebagai potensi sebuah produk akhir, yang kemudian akan diluncurkan jika tidak terdapat kesalahan fatal pada produk software yang ada. Pada tahap ini produk sudah lebih stabil dan semua fitur sudah didesain dan diuji melalui beberapa kali beta testing tanpa menunjukkan kesalahan. Beberapa developer software seperti Apple Inc. menggunakan istilah ‘Golden Master’ untuk mengindikasikan versi RC yang dimilikinya. Beberapa developer menggunakan istilah Gamma dan Delta untuk mengindikasikan versi yang sudah komplit tapi masih butuh beberapa pengujian, Omega atau Zenith untuk mengindikasikan versi pengujian akhir yang dipercaya sudah lebih bebas kesalahan dan siap untuk diproduksi.

Release To Manufacturing

disebut juga Going Gold digunakan untuk software yang siap untuk dikirimkan maupun digunakan oleh pengguna. Istilah ini biasanya digunakan untuk software yang digunakan untuk produksi masal dimana software dijual sebagai bagian dari kelengkapan hardware komputer atau distribusi masal retail (berkebalikan dengan software yang khusus diproduksi untuk proyek komersial atau distribusi terbatas). RTM biasanya merupakan tahap sebelum software disediakan untuk umum (GA).

General Availability

titik dimana semua hal yang diperlukan untuk kegiatan komersialisasi produk telah dilakukan dan software sudah siap untuk disediakan pada pasar atau publik baik melalui web atau media fisik. Istilah lain yang memiliki arti yang hampir sama dengan GA adalah First Customer Shipment (FCS), istilah ini digunakan oleh beberapa perusahaan seperti Sun Microsystem dan Cisco untuk mendeskripsikan software yang telah dikirimkan untuk mendapatkan pendapatan. Beberapa versi mungkin di klasifikasikan sebagai Long Term Support (LTS) yang disertai dengan kemampuan untuk diupgrade ke versi LTS selanjutnya dan akan terus didukung, update ataupun ditambah patch untuk waktu yang panjang dibandingkan versi non-LTS. 29/5/2013 9  

Support Release

dalam sistem operasi Windows disebut dengan Service Pack tidak selalu ada dalam sebuah daur hidup perangkat lunak. Biasa disebut juga dengan Update Patch, paket ini berisi koleksi update, perbaikan maupun penambahan fitur dalam sebuah paket yang dapat diinstal. END OF LIFE Tahap ini adalah tahap dimana sebuah software sudah tidak lagi diproduksi, dijual maupun didukung dengan support release. 10       

Semantic Versioning (SemVer) 

Jadi apa itu Semantic Version? Simplenya Semantic Version ini adalah sistem penomoran versi sebuah produk/software. Berfungsi untuk membedakan satu versi dengan versi lainnya.

Dalam SemVer, ada 3 istilah dan melakukan versioning: Major, minor, patch. Gambarannya adalah seperti ini:

contohnya: 2.33.7

• 2 adalah versi major nya
• 33 adalah versi minor nya
• 7 adalah versi patch nya

Kita akan bahas lanjut seputar apa itu major, minor, patch dibawah.

Major version

Versi major adalah tentang perubahan yang terjadi terhadap public API. Bila versi major tersebut bernilai 1, berarti software tersebut baru dirilis ke publik. Ya, jika kamu baru pertama kali merilis software/library kamu ke publik, dengan catatan sudah "stabil", maka seharusnya kamu menggunakan nilai 1 untuk versi major nya.

Kondisi kapan versi major harus ditambah adalah ketika kamu melakukan perubahan terhadap public API yang mana perubahan tersebut sudah tidak mendukung versi sebelumnya.

Kita ambil contoh ketika React merilis versi 16. Apa saja perubahan yang terjadi?

1. Behavior dalam scheduling dan lifecycle. Salah duanya adalah menggunakan "Fiber" dalam reconciliation dari yang sebelumnya menggunakan "Stack", dan memanggil setState di methods render akan menyebabkan perubahan dari yang sebelumnya tidak.
2. Perubahan struktur direktori. Dari yang sebelumnya hanya memisahkan antara versi asli dan versi "minified" nya, sekarang ditambah: Versi production dan development meskipun masih tetap ada versi "minified" ataupun aslinya.

Yang artinya, perubahan yang terjadi dari versi major terbaru "berpengaruh" terhadap "behavior" dari versi sebelumnya. Seharusnya, versi major ini jangan cepat berubah. Atau users akan kabur karena sering kali terjadi perubahan yang membuat users harus "mempelajari lagi".

Di level aplikasi, mungkin bumping major version dilakukan ketika user seharusnya tidak bisa menikmati fitur sebelumnya bila memang menggunakan SemVer. Misal, dari yang sebelumnya (v1.x.x) pembayaran bisa menggunakan kartu kredit, di versi sekarang (v2.x.x) tidak bisa karena blablabla.

Minor Version

Jika major version adalah tentang perubahan yang menyebabkan dampak terhadap behavior sebelumnya, di minor version tidak. Kita ambil contoh React Hooks, di versi 16.8.x. React Hooks adalah tentang membuat component dengan gaya fungsional, namun tetap stateful.

Sebelumnya untuk membuat component yang stateful, kita harus menggunakan class-based component. Tidak sedikit masalah yang dihadapi di class-based component: boilerplate, this binding, constructor, dsb. Dengan React hooks, kita bisa menyelesaikan masalah tersebut. Karena boilerplate-free, automatic this bindung, dan zero constructor. Because it just a function!

Hooks tidak mengubah cara kita membuat component, melainkan "menambah". Ya, minor version adalah tentang "fitur baru". Asiknya, upgrade minor version tidak akan menyebabkan dampak yang terjadi terhadap kondisi yang sudah ada.

Aman untuk diupgrade (sebagai users), dan aman untuk di rilis (sebagai owner).

Juga, bila terjadi "deprecated" terhadap public API, maka minor version harus ditambah nilainya. Deprecated adalah kondisi dimana API tersebut akan "dihilangkan" dan users harus menggantinya ke API terbaru sebelum melakukan upgrade ke major version terbaru. Bila version minor ditambah, maka versi patch harus di reset ke 0.

Patch Version

Di versi ini adalah tentang fix bug yang tidak menyebabkan perubahan terhadap public API. Karena fix bug biasanya hanya terkait terhadap kode internal, bukan public API yang digunakan oleh users.

Biasanya, versi patch di version ditambah bila terjadi bug yang sangat krusial. Bila perubahan tersebut tidak terlalu krusial, alias hanya berdampak "kecil" terhadap public API, seperti fix typo; Enhancement in performance dsb, rilis tersebut dilakukan di versi minor. Alias, digabung dan dianggap sebagai "fitur".

Namun bila bug seperti memory leak, seputar security dsb, maka harus melakukan bumping version patch dengan catatan tidak merubah behavior yang ada di public API.

Demo sederhana

Kita membuat library untuk berinteraksi dengan AWS S3. Karena belum stabil, kita rilis kode tersebut dengan versi 0.1.0 dengan catatan kode tersebut sudah bisa digunakan untuk melakukan proses upload dan membaca file dari S3.

Lalu kita menambah fitur baru, delete file. Kita tambah versi minornya, yang berarti menjadi 0.2.0. User yang sudah menggunakan kode kamu, bisa melakukan upgrade version terhadap library kamu untuk bisa menikmati fitur delete tanpa harus meragukan kompatibilitas terhadap kode yang ada sebelumnya yang bergantung dengan library kamu.

Lalu kamu menemukan bug dan mem-fix nya. Memory leak, proses tetap berjalan meskipun user sudah membatalkan proses tersebut yang menyebabkan library tetap mengupload namun konten nya kosong. Maka kamu harus melakukan bump version patch, yang berarti menjadi 0.2.1.

Lalu kamu membuat fitur baru: Rename file yang sudah ada. Selain itu, kamu juga melakukan fix terhadap bug-bug kecil seperti typo yang mengganggu. Dan juga, kamu melakukan beberapa improvement. Misal, bila user membaca file yang sama dalam 10 detik, maka library akan memberikan versi cache nya daripada harus me-request terus-menerus ke file yang sama dalam 10 detik oleh user yang sama.

Maka kamu melakukan bumping version terhadap versi minor, dan me-reset versi patch nya, yakni menjadi 0.3.0.

Ketika kita sudah merasa bahwa library ini sudah stabil untuk digunakan, kita bisa merilis fitur major nya yang berarti versi 1.0.0 dengan fitur-fitur yang sudah dijelaskan di minor version (namun bukan yang seputar patch nya).

Lalu perubahan terjadi, sekarang oktober 2019 dan AWS sudah tidak akan mendukung S3 per-desember 2019 nanti. Sebagai gantinya, AWS merilis S4 (Super Simple Storage Service) yang mana hampir sama dengan S3 namun menggunakan protokol http3 untuk proses read nya dan menggunakan protokol TUS untuk uploadnya.

Maka kita harus melakukan bumping version versi minor, bahwasannya API uploadFile akan deprecated, sebagai gantinya gunakan updateFile namun tetap di versi tersebut method uploadFile masih berjalan. Yang berarti, versi sekarang harus ditambah minor nya menjadi 1.1.0.

Lalu sekarang 10 desember, dan 20 desember AWS sudah tidak mendukung AWS S3 lagi. Maka kamu merilis versi baru library kamu yang berarti menjadi versi 2.0.0 dengan catatan method uploadFile sudah tidak bisa digunakan lagi dan menjadi updateFile sebagai gantinya.

Referensi:

• https://www.bakhel.com/2019/02/pengertian-dan-perbedaan-antara-versi-dan-rilis-perangkat-lunak.html
• https://slideplayer.info/slide/3176468/
• https://blog.evilfactory.id/mengenal-semantic-versioning/
• https://azishapidin.com/blog/mengenal-semantic-versioning/

Read More

Software Quality Requirements and Evaluation Berdasarkan Model ISO/IEC 25010:2011

System/Software Product Quality berdasarkan model ISO/IEC 25010:2011 memiliki 8 karakteristik:

Functional Suitability

Sejauh mana suatu produk atau sistem menyediakan fungsi yang memenuhi kebutuhan (yang dinyatakan dan yang tersirat) bila digunakan dalam kondisi yang telah ditentukan.

Functional Suitability memiliki 3 karakteristik:

·         Functional Completeness

Sejauh mana seperangkat fungsi mencakup semua tugas dan tujuan pengguna yang telah ditentukan

·         Functional Correctness

Sejauh mana suatu produk atau sistem memberikan hasil yang benar dengan tingkat presisi yang diperlukan

·         Functional Appropriateness

Sejauh mana fungsi-fungsi memfasilitasi pemenuhan tugas dan tujuan yang telah ditentukan. Misalnya pengguna hanya disajikan dengan langkah-langkah yang diperlukan untuk menyelesaikan tugas, tidak termasuk langkah-langkah yang tidak perlu

 

Performance Efficiency

Kinerja relatif terhadap jumlah sumber daya yang digunakan dalam kondisi yang ditetapkan

Karekteristiknya adalah:

·         Timely-Behavior
Sejauh mana respon, waktu proses, dan tingkat keseluruhan produk atau sistem memenuhi persyaratan ketika melakukan fungsinya

·         Resource Utilization

Sejauh mana jumlah dan jenis sumber daya yang digunakan oleh produk atau sistem memenuhi persyaratan ketika melakukan fungsinya

·         Capacity

      Sejauh mana batas maksimum parameter produk atau sistem memenuhi persyaratan

Compatibility

Sejauh mana produk, sistem, atau komponen dapat bertukar informasi dengan produk, sistem, atau komponen lain dan/atau menjalankan fungsi-fungsi yang diperlukan sementara berbagi lingkungan perangkat keras atau perangkat lunak yang sama.

Karekteristiknya adalah:

·         Interoperability

Sejauh mana dua atau lebih sistem, produk, atau komponen dapat saling bertukar informasi dan menggunakan informasi yang telah ditukar

·         Co-existence

Sejauh mana suatu produk dapat melakukan fungsi yang diperlukan secara efisien sementara berbagi lingkungan dan sumber daya umum dengan produk lainnya, tanpa adanya dampak merugikan pada produk lain

 

Usability

Sejauh mana suatu produk atau sistem dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu dengan efektivitas, efisiensi, dan kepuasan dalam konteks penggunaan yang telah ditentukan

 

Karekteristiknya adalah :

·         Operability

Sejauh mana suatu produk atau sistem memiliki atribut yang membuatnya mudah dioperasikan dan dikendalikan

·         Learnability

Sejauh mana suatu produk atau sistem dapat digunakan oleh pengguna tertentu untuk mencapai tujuan tertentu dari pembelajaran untuk menggunakan produk atau sistem dengan efektivitas, efisiensi, kebebasan dari risiko dan kepuasan dalam konteks penggunaan yang telah ditentukan

·         Appropriateness Recognisability

Sejauh mana pengguna dapat mengenali apakah suatu produk atau sistem tepat untuk kebutuhan mereka

·         User Error Protection

Sejauh mana suatu sistem melindungi pengguna dari membuat kesalahan

·         User Interface Aesthetics

Sejauh mana antarmuka pengguna memungkinkan interaksi menyenangkan dan memuaskan bagi pengguna

·         Accessibility

Sejauh mana suatu produk atau sistem dapat digunakan oleh orang-orang dengan cakupan karakteristik dan kemampuan yang luas untuk mencapai suatu tujuan tertentu dalam konteks penggunaan yang telah ditentukan

 

Reliability

Sejauh mana sistem, produk, atau komponen melakukan fungsi tertentu dalam kondisi tertentu untuk jangka waktu tertentu

 

Karekteristiknya adalah :

·         Maturity

Sejauh mana sistem, produk, atau komponen memenuhi kebutuhan untuk keandalan pada operasi normal

·         Availability

Sejauh mana sistem, produk, atau komponen operasional (dapat beroperasi) dan dapat diakses bila diperlukan untuk digunakan

·         Fault Tolerance

Sejauh mana sistem, produk, atau komponen beroperasi sebagaimana dimaksud meskipun adanya kesalahan perangkat keras atau perangkat lunak

·         Recoverability

Sejauh mana, ketika terjadi gangguan atau kegagalan, produk atau sistem dapat memulihkan data yang secara langsung terkena dampak dan membangun kembali keadaan yang diinginkan system

 

Security

Sejauh mana suatu produk atau sistem melindungi informasi dan data sehingga orang, produk, atau sistem lain memiliki tingkat akses data yang sesuai dengan jenis dan tingkat otorisasi mereka.

 

Karekteristiknya adalah :

·         Confidentiality

Sejauh mana suatu produk atau sistem memastikan bahwa data hanya dapat diakses oleh mereka yang berwenang untuk memiliki akses.

·         Integrity

Sejauh mana sistem, produk, atau komponen mencegah akses tidak sah terhadap, atau modifikasi, program komputer atau data

·         Non-repudiation

·         Sejauh mana tindakan atau kejadian dapat dibuktikan telah terjadi, sehingga peristiwa atau tindakan tersebut tidak dapat ditolak/disangkal kemudian

·         Accountability

·         Sejauh mana tindakan dari suatu entitas dapat ditelusuri secara unik untuk entitas tersebut

·         Authenticity

Sejauh mana identitas subjek atau sumber daya dapat terbukti menjadi salah satu yang diklaim

Maintainability

Sejauh mana efektivitas dan efisiensi di mana suatu produk atau sistem dapat dimodifikasi oleh pengembang yang dimaksudkan

 

Karekteristiknya adalah :

·         Modularity

Sejauh mana sistem atau programkomputer terdiri dari komponen berlainan sehingga perubahan pada salah satu komponen memiliki dampak minimal pada komponen lainnya

·         Reusability

Sejauh mana aset dapat digunakan di lebih dari satu sistem, atau dalam membangunaset lainnya

·         Analysabilty

Sejauh mana efektivitas dan efisiensi di mana dimungkinkan untuk menilai dampak perubahan yang dimaksudkan untuk satu atau lebih bagian-bagian produk atau sistem, untuk mendiagnosis kekurangan/cacat atau penyebab kegagalan suatu produk, atau untuk mengidentifikasi bagian yang akan dimodifikasi

·         Modifability

Sejauh mana suatu produk atau sistem dapat secara efektif dan efisien dimodifikasi tanpa menimbulkan kerusakan/cacat atau menurunkan kualitas produk yang sudah ada

·         Testability

Sejauh mana efektivitas dan efisiensi di mana kriteria uji dapat dibentuk untuk sistem, produk, atau komponen dan tes dapat dilakukan untuk menentukan apakah kriteria tersebut telah dipenuhi

 

Portability

Sejauh mana efektivitas dan efisiensi di mana sistem, produk, atau komponen dapat ditransfer dari satu perangkat keras, perangkat lunak, atau lingkungan operasional atau penggunaan lain ke lainnya

 

Karakteristiknya adalah:

·         Adaptability

Sejauh mana suatu produk atau sistem dapat secara efektif dan efisien disesuaikan untuk perangkat keras, perangkat lunak atau lingkungan operasional atau penggunaan lain yang berbeda atau lebih berkembang

·         Installability

Sejauh mana efektivitas dan efisiensi di mana suatu produk atau sistem dapat berhasil dipasang (di-instal) dan/atau dihapus (dilepas) di lingkungan yang telah ditentukan

·         Replaceability

Sejauh mana suatu produk dapat menggantikan produk perangkat lunak lain (yang telah ditentukan) dengan tujuan yang sama dalam lingkungan yang sama

Reference:

- D. H. Trenggono, “Perancangan Sistem Peminjaman Berbasis Web Sebagai Media Layanan di Studio Multimedia SMK 2 Sewon,” Skripsi, pp. 10–17, 2014.

Read More