Software Performance Engineering
A Software-Oriented Approach: Fokus pada Arsitektur, Design, dan Pemilihan Implementasi
Pada software development, delivery functionality dari software sudah jelas merupakan faktor yang sangat penting. Akan tetapi, selama software tersebut digunakan atau selama lifetime software cost dari software ternyata lebih ditentukan oleh seberapa baik software kita mencapai tujuan kualitas atribut seperti, performance, reliability, availability atau maintainability dibandingkan dari fungsionalitasnya. Semakin bagus kualitas atribut yang dimiliki maka cost keseluruhan terhadap software kita akan semakin rendah.
Software performance memiliki pengertian sebagai sejauh mana kemampuan dari software atau komponen-komponennya memenuhi tujuan dari ketepatan waktu. Jadi, performance pada dasarnya adalah karakteristik apa pun dari produk software yang pada prinsipnya kita dapat mengukurnya dengan duduk di depan komputer dengan stopwatch di tangan kita.
Ada dua dimensi penting dari software performance yang perlu kita hitung dan perhatikan. Keduanya yaitu tingkat responsivitas dan skalabilitas. Responsiveness adalah kemampuan suatu sistem untuk memenuhi waktu respons atau throughput yang diinginkan. Pada sistem software secara realtime responsiveness ini diukur dengan seberapa cepat merespon sebuah event atau request.
Scalability adalah kemampuan dari sistem, jaringan, software, atau proses untuk dapat menangani jumlah beban request yang terus menerus bertambah. Skalability menjadi aspek yang sangat penting bagi software sekarang ini.
Software performance sangat penting untuk keberhasilan dan impact dari software. Namun, banyak sekali software yang tidak dapat memenuhi performance sejak saat dibuat.
Perbaikan permasalahan yang dimiliki sebuah software sangat mahal dapat mengakibatkan time to market menjadi tertunda, biaya yang membengkak, revenue yang hilang, menurunkan tingkat produktivitas dari team, dan bahkan dapat mengakibatkan relasi customer yang rusak.
Dalam kasus yang ekstrim perbaikan tidak dapat dilakukan tanpa design dan pembuatan ulang yang ekstensif. Akhirnya cost dari pembuatan dan maintenace software menjadi dua kali.
Cara Pendekatan Lama
Banyak organisasi yang menggunakan pendekatan Rush dahulu Fix it Later pada performance sebuah software. Pendekatan ini mengutamakan untuk berkonsentrasi pada ketepatan delivery dan menunda performance sampai tahap pengujian. Masalah kinerja yang terdeteksi kemudian, diperbaiki dengan menambahkan perangkat keras tambahan, menyetel perangkat lunak (biasanya dalam mode krisis), atau keduanya.
Pendatakan ini dilakukan karena beberapa mitos dalam dunia performance. berikut mitos-mitos yang berbahaya yang harus dihindari dan difahami.
- Masalah performance jarang terjadi. Pada kenyataannya jumlah, ukuran, dan kompleksitas dari sistem software kita semakin meningkat bedasarkan waktu. Di sisi lain banyak developer yang ada ternyata kurang ahli dalam menangani performance. Akibatnya permasalahan performance menjadi suatau hal yang umum dan dimaafkan.
- Hardware itu banyak, cepat, dan murah. Pada kenyataannya memang kecepatan prosesor meningkat drastis tetapi jaringan itu jauh lebih lambat. Lebih lanjut tidak ada yang memiliki anggaran hardware yang tidak terbatas.
- Responsive software terlalu mahal untuk dibuat. Pada kenyataannya, ini tidak dibanding kan cost untuk kehilangan pelanggan dan lain-lainya. Disisi lain ada beberapa pendekatan atau proses development yang akan memberikan cost yang lebih efektive dan murah tetapi kita menghasilkan software yang responsive.
- Kita dapat melakukan tune permasalahan nanti. Pada kenyataannya, mitos ini terjadi karena asumsi bahwa performance yang buruk terjadi karena code yang buruk. Padahal rata-rata performance yang buruk di sebabkan lebih banyak oleh arsiterkur yang kurang pas, design yang tidak tepat. Dengan demikian, kita tidak dapat memperbaiki performance hanya dengan membuat codenya lebih baik tetapi arsitekturnya dan design serta pemilihan cara implementasi yang lebih baik.
Cara Pendekatan Baru
Bayangkan apabila kita dapat mendelivery sebuah software dengan tepat waktu, anggaran yang sesuai, dan memenuhi syarat performance yang di inginkan pada saat pertama kali software direlease. Bayangkan jika performance dan stress test berhasil dilakukan pada kali pertama, Bayangkan kita sudah memiliki ramalan akan kapasitas hardware sebelum software kita deploy di production.
Apakah harapan kita di atas cuma hayalan atau cerita isapan jempol saja. Ternyata keadaan ideal di atas dapat juga kita capai apabila kita melakukan rencana dan proses development dengan benar. Software Performance Engineering merupakan sebuah cara untuk mencapai kondisi ideal di atas.
Software Performance Engineering (SPE) adalah pendekatan kuantitatif sistematis untuk pengembangan sistem software yang hemat biaya untuk memenuhi persyaratan performance. SPE adalah pendekatan berorientasi perangkat lunak yang berfokus pada arsitektur, desain, dan pilihan implementasi.
SPE memberi Anda informasi yang kita butuhkan untuk membangun perangkat lunak yang memenuhi persyaratan kinerja tepat waktu dan sesuai anggaran.
Proses SPE dimulai pada awal siklus hidup pengembangan software dan menggunakan metode kuantitatif untuk mengidentifikasi arsitektur dan software desain yang memuaskan serta untuk menghilangkan arsitektur desain yang kemungkinan memiliki kinerja yang tidak dapat diterima sebelum developer menginvestasikan waktu yang signifikan dalam implementasi.
SPE berlanjut melalui fase desain, pengkodean dan kinerja dengan pengujian beban yang terperinci untuk memprediksi dan mengelola kinerja softttware yang berkembang serta memantau dan melaporkan kinerja aktual versus spesifikasi dan prediksi.
Metode SPE meliputi: pengumpulan data kinerja; teknik analisis kinerja kuantitatif; strategi prediksi; pengelolaan ketidakpastian; penyajian dan pelacakan data; pengujian kinerja, pengujian load atau strest test, verifikasi dan validasi model; faktor penentu keberhasilan; dan prinsip desain kinerja, pola dan antipatterns.
Penghambat SPE
Akan berbahaya jika kita beranggapan ketika kita telah menghire para jawara coding, para specialis arsitektur, dan para ahli agile coach akan menjamin penerapan SPE dilakukan secara sistematis. Kita tetap harus memastikan penerapan SPE ini ada pada SLDC yang sedang dijalankan. Mintalah laporan mengenai performance dan kuallitas aplikasi yang sedang di buat secara berkala dan sesuai dengan persyaratan kinerjanya. Dengan demikian, semuanya bisa terpantau dan kita bisa selalu mengarahkan team agar SPI ini tetap pada jalurnya.
Selain itu perhatikan juga beberapa hambatan berikut yang sering sekali pada kehidupan proses pembuatan software menghambat bahkan menggagalkan SPE inisative ini.
- Fokus pada hal-hal kecil. Fokus pada hal-hal kecil atau kosmetik dan tidak memerhatikan keseluruhan stabilitas sistem. Mungkin di bagian depan terlihat cepat tapi beberapa bagian tertentu sistem kira rapuh.
- Berasumsi bahwa setiap orang akan mendukung. Ketika mengadopsi suatu teknologi atau pendekatan baru kita harus memperjuangkan dengan sekuat tenaga. Anda harus mencari dukungan dari semua pihak mulai dari mangement, team , dan pengguna atau user dari software yang kita buat.
- Tidak tahu langkah selanjutnya. Banyak yang sudah merencanakan SPE tetapi projectnya mati karena ketidakpastian pendanaan, komitment management, dan pemenuhan persyaratan teknis. Pada akhirnya project-project SPE mati karena tidak tau bagaimana melangkah maju. Pemilihan awal menggunakan SPE juga kadang pencetus kegagalan SPE. Untuk awal disarankan pilihlah project yang tidak terlalu ketat, sangat penting dan menjaga kelangsungan hidup organisasi. Karena kalau project-project ini akan mendapat tekanan yaang ekstrim sehingga jika mendapat masalah maka akan dengan mudah menyalahkan teknologi baru dan pendekatannya yang akhirnya kembali lagi ke cara lama.
- Tidak ada management yang fokus mengurus SPE. Seperti kebanyakan project, kurangnya fokus dan tidak ada management yang mengurus akan meningkatkan kemungkinan kegagalan.
- Ambil jalan termudah. Ketika mengahadapi permasahalan dan ketakutan komitmen maka tidak jarang banyak team yang mengambil jalan termudah. Hal ini jelas akan membuat project SPE ini gagal. Salah satu aspek tersulit dari SPE adalah mendapatkan persyaratan kinerja kuantitatif dan banyak yang merasa enggan berkomitment pada hal ini.
- Penggunaan metrik dan alat ukur yang salah. Ketika ada salah menggunakan cara mengukur dan alat ukur yang di gunakan salah maka pasti project SPE Anda akan gagal.
- Developer tidak dilibatkan. Ketika team developer tidak terlibat project SPE dari awal maka mereka cendrung memandang dengan di masukannya mereka ke team SPE akan menambah beban mereka dan berfikir tidak ada manfaat sama sekali. Jelas team musti disadarkan dan diyakinkan akan perlunya dan keuntungan ketika menggunakan SPE.
- Tidak ada pendanaan khusus unutk SPE.
- Menggunakan orang atau team yang salah.
- Berasumsi team sudah mengerjakan SPE tanpa benar-benar memasukan SPE kedaam SDCL.
Kesimpulan
Kita mengubah paradigma untuk mengelola kinerja perangkat lunak dari pemecahan masalah ke praktik terbaik untuk keunggulan kinerja. Dengan pendekatan ini akan menghasilkan.
- Arsitek tahu bahwa arsitektur mereka akan mendukung persyaratan kinerja sebelum menggunakan kode.
- Manajer proyek dapat melacak status kinerja saat perangkat lunak sedang dikembangkan.
- Pakar kinerja punya waktu untuk menjalankan uji beban dan stres tanpa menemui “kejutan”.
- Risiko untuk mencapai persyaratan kinerja diidentifikasi dan ditangani di awal proses, sehingga menghemat waktu dan uang.
- Perangkat lunak yang memenuhi persyaratan kinerja dikirimkan tepat waktu dan sesuai anggaran.
SPE ini juga pada tataran implementasinya dapat dikombiinasikan dengan agile prosess sehingga lebih memberikan impact.
“Utterly demystifies the job (no longer the art) of performance engineering. Monsters, begone! Wizards, away! It leaves you feeling that you could really do this on your own. And, thanks to Connie and Lloyd, you can.”
— From the Foreword, by Paul Clements
The Legend Programmer Channel
References
- https://www.researchgate.net/publication/221445724_Best_Practices_for_Software_Performance_Engineering
- https://en.wikipedia.org/wiki/Performance_engineering
- http://www.spe-ed.com/classic-site/speis.htm
Sponsor
Membutuhkan kaos dengan tema pemrograman :
Dapat menghubungi The Legend.
