Bukan. Pendekar Kereta yang saya sebut disini adalah orang-orang yang dengan gagah berani naik KRL Ekonomi, naik di ATAP kereta :-) Kenapa disebut Pendekar ? Karena untuk naik ke ATAP membutuhkan usaha yang tidak mudah. Harus bisa memanjat dinding gerbong kereta dengan hanya berpijak pada pijakan seadanya. Bisa bertumpu pada bingkai jendela gerbong yang sudah rusak, ada yang memilih memanjat melalui sambungan gerbong. Di bagian sambungan antar gerbong, ada bagian yang menonjol berbentuk silinder, mungkin dulunya digunakan sebagai cerobong asap. Karena sekarang kereta menggunakan tenaga listrik atau diesel, jadi cerobong itu tidak aktif dan aman sebagai tempat memanjat.

KuraKura dan Landak pun bertemu di atas batu kali, bercanda ria seperti biasa. Sampai tiba-tiba, Landak berkata, "Kamu ngga pengen jadi angsa ? Pasti kamu cantik deh kalo jadi angsa. Kamu juga akan bisa berlari cepat mengejarku". KuraKura tertegun, bingung mau jawab apa. KuraKura memang mengagumi Landak, tapi memenuhi permintaan Landak itu tak semudah yang diucapkan. Landak masih berbicara dengan penuh semangat, tapi KuraKura sudah tak mampu mencerna semua kata-kata Landak. Yang bisa dilakukannya hanya pura-pura mengerti dan tersenyum. Sejak saat itu, Landak tak pernah datang ke pinggir sungai lagi. Tak juga menunggu KuraKura di batu tempat mereka biasa bertemu. KuraKura sempat tercenung beberapa lama.

Dengan usaha keras, dibarengi latihan lompat batu tiap hari (duh kayak tradisi Nias aja neh), si KuraKura lamban akhirnya berubah menjadi seekor angsa yang cantik, gesit, ramping kakinya. Namanya pun berganti menjadi KurAngsa. Setiap hari KurAngsa berkaca, mematut diri melihat bayangannya di permukaan air sungai. "Betapa cantiknya aku...", begitu gumam KurAngsa dalam hati.

Dari kejauhan tampak bayangan mendekat. Ternyata si Landak yang telah lama tak bersua. Namun KurAngsa pura-pura tidak mengenalnya. "Aku kan sekarang sudah cantik, buat apa berteman dengan Landak penuh duri, huh, bisa-bisa nanti durinya menusuk bulu-bulu lembutku", demikian kata KurAngsa. Landak menyapa dengan agak ragu, "Benarkah kamu KuraKura ?" KurAngsa menjawab dengan ketus, "Heh, siapa kamu, enak aja, namaku KurAngsa. Siapa itu KuraKura ?"
Landak tercengang, tak mampu berkata-kata lagi. Wajah Landak menunjukkan keheranan yang sangat. "Kok KuraKura tak mengenaliku lagi ?" KurAngsa tak peduli, dan meninggalkan Landak yang masih tertegun.


>>> Apa yang kita sangka akan menjadi perubahan baik bagi orang lain, belum tentu akan menghasilkan perubahan sesuai kemauan kita. Jadi, terimalah apa adanya, tidak lebih, tidak kurang. <<<

Parameter-parameter tersebut, antara lain adalah :
1. Jumlah error LOC (Line Of Code).
2. User acceptance dan customer satisfaction.
3. Fungsionalitas software yang dihasilkan.
4. Kemudahan pengembangan produk software yang telah ada.
Masih banyak lagi yang lainnya, tapi untuk sementara, sebagai gambaran, saya akan membahas 4 parameter diatas sebagai sebagian penentu kualitas software.

Jumlah error LOC, artinya adalah berapa jumlah baris pada code program yang dinilai sebagai kesalahan program. Tentunya yang mengetahui adanya kesalahan LOC ini dari pihak produsen software. Sumbernya bisa dari komplain user tentang software yang tidak sesuai keinginan mereka, kemudian setelah di-cek ke code programnya ternyata memang terjadi kesalahan coding.

Saat program diujicobakan untuk digunakan oleh user, sebisa mungkin dimaksimalkan tingkat acceptance dari user, sebisa mungkin diusahakan agar user merasa nyaman menggunakan software tersebut. Tentu saja dengan tidak mengabaikan kebutuhan user. Meskipun terkadang, terdapat kasus dimana user kurang bisa dengan spesifik mendefinisikan kebutuhannya, sehingga pada saat software-nya sudah jadi, diujicobakan, ternyata berbeda dengan persepsi user mengenai software yang diinginkan.

Fungsionalitas, berkaitan dengan kebutuhan user, dan definisi user tentang kebutuhan mereka. Apabila telah ada kesamaan persepsi antara kebutuhan user dengan apa yang didefinisikan dan ditangkap oleh pihak pengembang, hampir bisa dipastikan (90%) fungsionalitas software akan sesuai dengan keinginan dan mendekati bentuk yang dibayangkan oleh user. Kemungkinan perubahan biasanya hanya pada desain layoutnya saja.

Code program yang dihasilkan, harus ditulis dengan struktur yang rapi sehingga mudah dibaca oleh programmer seandainya di kemudian hari harus dilakukan modifikasi program.

Jika penilaian software yang dihasilkan sudah masuk kategori "berkualitas", dua pihak sama-sama diuntungkan. User mendapatkan software yang berkualitas dan sesuai kebutuhannya. Sedangkan pengembang software mendapatkan reliabilitas sebagai produsen software berkualitas.

Sama-sama untung kan.....jadi...mari mulai memperhatikan kualitas software yang kita hasilkan.

"Jangan terlalu teknis, dari sisi analisanya harus kuat dong."
Lhaaa ??? Dulu katanya (si dosen saat memberi petunjuk tentang tugas) proposal itu harus berisi fakta, perbandingan, data, dsb. secara teknis dan ilmiah. Analisa harus dikuatkan dengan bukti-bukti teknis serta fakta. Kalau memang faktanya begitu adanya, dan prosesnya memang seperti itu, apa harus ditutup-tutupi untuk alasan 'biar ngga terlalu teknis'.

Solution
Ya sudahlah, cokelat dah jadi keju (emang bisa gituh ?). Sekarang yang penting "menyelamatkan" nilai teman-teman sekelompokku, kasihan mereka, hampir jadi "korban" gara-gara case study yang aku usulkan. Ngga ada yang salah dengan case study, hanya mungkin si dosen belum mendapatkan 'big idea' dari case study yang aku ambil ini.
Weekend besok...diisi dengan finishing (tepatnya perombakan total) proposal case study ini.

Moral story

Maybe it caused by my lack of skill on programming. When designing an information system, you must have very good understanding on any programming language, algorithms, program flows, etc.