10 Faktor yang Harus Diperhatikan Untuk Membuat Software yang Berkualitas

Halo sobat-sobat IT Indonesia khususnya yang di UIN Maliki Malang. Ane mau berbagi beberapa tips buat kalian yang hobi banget coding atau bikin program (Anak TI khususnya). Tips ini berguna jika kita ingin membuat sebuah software yang handal serta berkualitas, apalagi kalo kita pengen jadi software developer atau Software Engineer. Yuk di simak dulu :)

1. Cohesion
Cohesion berarti adalah seberapa fokus modul tersebut pada tugasnya. Kalau method methodnya mirip dalam berbagai aspek, maka dikatakan sebagai high cohesion. Cohesion akan turun dilihat bila sebuah method mengakses data yang tidak relevan dengan fungsinya. Ada beberapa macam cohesion

Yang harus dihindari
1. Coincidental cohesion
Adalah tipe yang terendah. Mencari class class seperti ini susahnya bukan main untuk dirubah. Contohnya adalah:

2. Logical cohesion
adalah apabila bagian dari modul dikelompokkan karena mereka melakukan hal yang sama secara logical, walaupun berbeda. Contoh:

3. Temporal cohesion
Yaitu module yang bagian bagiannya dikelompokan berdasarkan kapan mereka memproses sesuatu yang biasanya berbarengan. Contoh:

4. Procedural cohesion
Adalah apabila module melakukan sesuatu yang berhubungan secara prosedur. Contoh:

cohesion yang bisa digunakan
5. Communicational cohesion
Terjadi apabila module tersebut melakukan komunikasi terhadap data yang sama. Misalnya:

6. Sequential Cohesion
Adalah apabila sebuah modul, beroperasi pada sebuah data dari mulai input hingga output. Misalnya:

7. Function cohesion
Adalah apabila sebuah modul dikelompokkan karena mereka melakukan sebuah tugas modul. Misalnya mengkalkulasi gaji pegawai. Gaji pegawai tersebar di beberapa tabel, dan kadang membutuhkan data di tempat lain. Tetapi efisiensi terjadi, karena modul untuk menghitung gaji tersebut hanya pada modul tersebut, dan komunikasi tidak keluar dari satu modul tersebut. Hal ini akan sangat mempermudah maintainability dan expandability nantinya. Contoh:

Yang paling sering digunakan adalah communicational cohesion, tetapi yang terbaik sebetulnya adalah functional cohesion. Yaitu dimana sebuah modul fokus pada sebuah tugas. Yang sering menjadi masalah adalah temptation untuk menggabungkan beberapa functional module menjadi satu yang bercampur menjadi communicational cohesion.

2. Complexity
Salah satu cara melihat maintainability adalah kompleksitas kode. Cara ini sering disebut sebagai Cyclomatic Complexity, atau lebih dikenal dengan McCabe, atau juga dikenal sebagai Path Testing. Pada McCabe, yang diperhatikan adalah berapa banyak entry point, exit point, dan berapa banyak branch yang harus dilakukan program. Semakin kompleks sebuah code, maka rating McCabe semakin tinggi. Kode seperti ini biasanya tingkat kohesinya rendah. Kode yang tingkat kohesinya tinggi, biasanya menggunakan prosedur prosedur yang cukup simple. Pada rating McCabe yang tinggi, biasanya ada banyak return, ada banyak elseif, dan nested if..
Program dengan rating yang tinggi, cenderung juga untuk develop bug, dan terkenal sulit diperbaiki dan dilacak bugnya. Bila melakukan sebuah hal yang kompleks, lebih baik dipecah ke beberapa tahap atau module module yang masing masing spesialis melakukan tugasnya (lihat functional cohesion)

3. Extensibility
Adalah hal penting dalam maintainability. Apabila dalam suatu point, misalnya client membutuhkan untuk promosi kartu kredit yang BCA misalnya, berapa banyak code yang harus dirubah? Atau client meminta program untuk compile laporan dari beberapa divisi yang berkaitan, misalnya gudang dan retail, berapa sulit dan berapa banyak yang harus dirubah?

4. Scalability
Menentukan berapa lama program tersebut akan bisa bertahan seiring dengan perkembangan perusahaan. Program dengan scalability tinggi, sekali dibuat, walaupun untuk sebuah toko kelontong, tetapi akan tetap bisa digunakan sewaktu toko kelontong tersebut suatu saat menjadi sebuah hypermarket besar. Hal ini juga tidak terlepas dari peran efisiensi dari kode. Jangan banyak melakukan function function yang tidak perlu, lakukan caching, dan hindari repetition. Kalau seandainya harus ada repetition, lebih baik pisahkan menjadi subroutines yang terpisah. Perhatikan juga memory leaks, atau overflow error. Jangan ambil data yang tidak perlu. Misalnya hanya membutuhkan 1000 rows, tetapi yang difetch adalah 10000 rows pada client, kemudian melakukan join pada client program menggunakan LINQ atau HQL misalnya. Hal ini akan cepat membuat server wear-off, kecapean, dan overload, atau bahkan bisa terjadi network congestion.

5. Reliability
Definisi reliability adalah kemungkinan terjadinya error dalam environment yang ideal untuk waktu yang tertentu. Kalau kemarin ada yang bilang mengenai virus tidak termasuk, maka kalau program dia bisa berfungsi tanpa henti tanpa error, itu termasuk dalam reliability testing. Pada intinya, adalah bagaimana program bisa berfungsi dalam situasi yang ideal. Yang perlu diperhatikan adalah
1. Design
Apa yang harus dilakukan oleh program? Apakah design tersebut berguna? Biasanya design akan memusatkan perhatian pada suatu aspek. Karena itu design sebaiknya dipecah pecah menjadi beberapa design design dengan scope yang lebih sempit, sehingga meminimalisir hal hal yang tidak diinginkan. Misalnya program inventory, jangan sampe mengutak atik tabel dari program penjualan.
2. Programming
Adalah bahasa yang dipakai. Penggunaan classes, methods, abstraction, layers, hierarchy, modules, dst yang akan membantu untuk mengisolir sebuah tugas dengan tugas lainnya. Java saat ini memiliki tingkat reliability yang sangat tinggi, karena Java benar benar compartmentalized, dan memaksa user untuk membuat object object terpisah untuk tugas tugas module. Akan sulit mencampur adukkan tugas yang satu dengan yang lain dalam sebuah module di Java. PHP sebaliknya mudah untuk mencampur adukkan tugas tugas yang tidak berhubungan dalam sebuah file php.
3. Accuracy
Mengenai keakuratan data yang diberikan. Program harus dapat memberikan data yang diminta dengan akurat, dan menampilkan hanya data yang diminta sesuai yang diminta oleh user. Jangan sampai misalnya ada data bulan lalu ikut tercampur hanya karena dia pernah di-edit bulan ini dan timestampnya berubah.

6. Robustness
Ini adalah tahap berikutnya dari reliability, atau bisa dikategorikan bagaimana reliability program pada situasi yang TIDAK ideal. Test yang dilakukan biasa disebut sebagai fuzzy test. Fuzz test dilakukan dengan memasukkan random data ke program, atau sengaja melakukan perusakan pada bagian program, dan mencatat defect-nya. Misalnya dengan melakukan direct API call ke bagian bagian yang tidak seharusnya di-call, atau melakukan perubahan perubahan pada database, atau misalnya menyuruh program untuk menghitung pembagian dengan sebuah array yang kosong, atau menularkan virus ke program, atau bahkan sampai merusak databasenya.
Biasanya pada robustness testing, akan terlihat bugs, seperti memory leak, crash, atau kegagalan transaction pada database, atau kadang sama sekali tidak mau start. Bila terjadi kerusakan disini, biasa bisa dilakukan reproduksi untuk melihat dimana program crash, untuk kemudian memperbaikinya.

7. Fault Tolerance
Tahap berikutnya dalam reliability testing adalah Fault Tolerance. Tidak semua programmer bisa merancang Fault Tolerance program, tetapi program program yang critical harus melalui Fault Tolerance testing. Fault Tolerance mentargetkan system self-stabilization, sebuah situasi dimana sebuah system akan sanggup membuat dirinya error free dalam lingkungan yang penuh error. Beberapa cara yang umum digunakan adalah
1. Replikasi. Yaitu membuat beberapa instance yang identik, dan mengirimkan task secara paralel, kemudian memilih hasil yang tepat sesuai quorum atau hasil terbanyak.
2. Redundancy. Adalah cara untuk mengimplementasikan identical instances, dan melakukan switch apabila salah satu dari instance tersebut mengalami kegagalan. Konsep ini juga biasa dikenal sebagai failover
3. Diversity. Yaitu membuat beberapa implementasi yang berbeda untuk spesifikasi yang sama, dan menggunakan modul modul tersebut sesuai dengan situasi yang terjadi di lapangan. Misalnya sebuah modul yang biasa bekerja pada hard drive, pada waktu terjadi kegagalan hard disk, maka aplikasi akan melakukan penggantian modul yang bekerja melalui ramdisk.

Inti dari fault tolerance adalah tidak ada single point of repair. Artinya, aplikasi harus tetap beroperasi tanpa terinterupsi oleh kegagalan sembari melakukan proses self repair. Selama dia melakukan repair, tugas diserahkan kepada modul modul yang sesuai untuk menangani situasi tersebut, mengisolasi titik titik failure point, dan melakukan rekonstruksi data, kemudian melakukan resume setelah repair selesai dilaksanakan. NIST mengkategorikan kerusakan komponen berdasarkan lokalisasinya, penyebabnya, efeknya, dan lama perbaikannya. Dari sana bisa program harus menentukan tindakan yang bisa diambil untuk menghindari dirinya tidak berfungsi. Terkadang sebuah failure bisa menyebar ke tempat lain, misalnya kerusakan database, yang menyebabkan pemrosesan data yang keliru, dan menyebabkan program untuk mengirim data yang salah ke module lain, yang pada gilirannya juga memproses data yang keliru. Hal ini berpotensi menimbulkan system-wide-failure. Sebuah aplikasi yang memiliki fault tolerance tingkat lanjut biasanya bisa mengenali kelainan kelainan ini, dan mengisolirnya, sehingga kerusakan tidak menyebar.

8. Security
Security adalah bagaimana aplikasi anda memproteksi terhadap akses yang tidak semestinya. Apakah user bisa melangkahi role-nya? Apakah anda telah memperhitungkan semua kemungkinan yang bisa terjadi di lingkungan aplikasi bekerja? Misalnya aplikasi finance, apakah ada orang lain yang bisa merubah data payroll?

9. Understandibilty
Lebih ke arah teknik programming. Aplikasi yang baik, codenya lebih baik mudah dimengerti, sehingga memudahkan maintenance nantinya. Kode yang mudah dibaca akan mudah dirubah. Programmer akan bisa menemukan lokasi yang akan dirubah dengan cepat dan mudah.

10. Usability
Adalah aspek biasa, yang terlalu sering dibahas disini. Aspek ini adalah berapa mudah aplikasi anda digunakan oleh user? GUI yang bagus, AI yang pandai, bantuan bantuan bagi pemakai, akan membantu kualitas software anda. Karena aspek ke-10 ini adalah yang paling sering dibahas disini, ane rasa ane tidak perlu lagi membahas.

Sebenarnya ane juga belum begitu mengerti sih, cuma optimalisasi kode itu perlu dibiasakan. Dari 10 faktor di atas, mungkin terasa sulit untuk diterapkan sekaligus karena ada faktor kebiasaan dan juga faktor eksternal lainnya (Permintaan klien, deadline, dll). Kalopun kalo kalian pengen tahu lebih lanjut, bisa langsung aja ikut diskusi di topik tersebut.

Topik sekaligus sumbernya dari sini —->> MEMBUAT APLIKASI YANG BENAR-BENAR BERKELAS DAN BERKUALITAS.

Terima kasih buat agan magico yang udah bikin thread ini :)

3 Responses to “10 Faktor yang Harus Diperhatikan Untuk Membuat Software yang Berkualitas”

  1. […] lupa, dalam merancang dan membuat program jangan sembarangan juga. Silahkan baca Faktor-Faktor yang harus diperhatikan dalam membangun aplikasi yang berkelas dan berkualitas dalam blog ini. Walaupun ane juga belum pernah membuat aplikasi berbasis Android, setidaknya ane […]

  2. Kasper Suits…

    […Be Sure You Accept This Link Exchange Invitation…]…

Leave a Reply

Your email address will not be published. Required fields are marked *