Tren Terbaru Software dan Karakteristiknya

Software atau perangkat lunak penggunaannya sudah “menjalar” ke semua aspek kehidupan. Jika kita lihat diberbagai instansi atau organisasi, maka kita akan mengenal istilah Sistem Informasi, mulai dari Akademik (SIA) di sekolah-sekolah, sampai ke Sistem Informasi Ketenagakerjaan (SIK). Beragam produksi Software juga menjadi pilihan atas penggunaan Software tersebut, mulai dari yang harga rendah, sedang atau harga tinggi, atau mulai dari software luar negeri atau software lokal.
Merebaknya penggunaan Software di satu sisi menguntungkan Programmer dan developer Software, karena banyaknya order dan pendapatan yang bisa diperoleh. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak. Jadi pengembang dan software house di Indonesia belum bisa mulai memperhatikan masalah kualitas perangkat lunak ini.

Kualitas perangkat lunak (software quality) adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak (software engineering). Kajian dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak.

Bagaimanapun juga mengukur kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak), sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain lagi (usabilitas dan aspek desain).
Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak (process) dan hasil produk yang dihasilkan (product). Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Hal ini berangkat dari pengertian kualitas (quality) menurut IEEE Standard Glossary of Software Engineering Technology [3] yang dikatakan bahwa:
“The degree to which a system, component, or process meets customer or user needs or expectation.”

Dari sudut pandang produk, pengukuran kualitas perangkat lunak dapat menggunakan standard dari ISO 9126 atau best practice yang dikembangkan para praktisi dan pengembang perangkat lunak. Taksonomi McCall adalah best practice yang cukup terkenal dan diterima banyak pihak, ditulis oleh J.A. McCall dalam technical report yang dipublikasikan tahun 1977 [1].

Di lain pihak, dari sudut pandang proses, standard ISO 9001 dapat digunakan untuk mengukur kualitas perangkat lunak. Dan diskusi tentang ini berkembang dengan munculnya tema kajian tentang CMM (The Capability Maturity Model) yang dikembangkan di Software Engineering Institute, Carnegie Mellon University serta beberapa kajian lain seperti SPICE (Software Process Improvement and Capability Determination) dan BOOTSTRAP. CMM, SPICE dan BOOTSTRAP mengukur kualitas perangkat lunak dari seberapa matang proses pengembangannya.

Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall [1], atribut tersusun secara hirarkis, dimana level atas (high-level attribute) disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria (criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat (cause-effect) [4][5].

Berikut adalah Faktor Kualitas (Quality Factor dan Quality Criteria) dari Perangkat Lunak
1. Correctness—> Completeness, Consistency, Traceability
2. Reliability —> Accuracy, Error Tolerane, Consistency, Simplicity
3. Efficiency —> Execution Efficiency, STorage Efficiency
4. Integrity —> Access Control, Access Audit
5. Usability —> Communicativeness, Operability, Training
6. Maintainability —> Consistency, Conciseness, Simplicity, Modularity, Self-documentation
7. Testability —> Simplicity, Modularity, Instrumentation, Self -documentation
8. Flexibility —> Expandability, Generality, Modularity, Self-doc
9. Portability —> Software System Independence, Hardware Independent, Self-documentation
10. Reusability —> Generality, software System Independence Hardware Independence, Modularity
11. Interoperability —> Communication Commonality, Data Commonalit Modularity.

Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria dalam suatu faktor sesuai dengan bobot (weight) yang telah ditetapkan [2]. Rumus pengukuran yang digunakan adalah:
F1 = w1c1 + w2c2 + … + wncn
Dimana:
F1 adalah nilai total dari faktor a
wn adalah bobot untuk kriteria i
cn adalah nilai untuk kriteria i

Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai berikut:
Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor
Tahap 2: Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)
Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <= 10)
Tahap 4: Berikan nilai pada tiap kriteria
Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn

Requerment Software Engineering

Definisi
Requirement menurut IEEE Standard Glossary of Software Engineering Technology (IEEE Std 610.12-1990) dapat diartikan sebagai berikut.
• Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan masalah atau mencapai tujuan
• Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standard, spesifikasi atau dokumen formal lain
• Gambaran yang terdokumentasi dari kondisi atau kemampuan yang disebut pada kondisi 1 dan 2 diatas

Menurut Sommerville requirement adalah spesifikasi dari apa yang harus diimplementasikan, deskripsi bagaimana sistem harusnya berkerja atau bagian-bagian yang ada didalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem.

Ada beberapa macam requirement menurut Sommerville yaitu:

a. User Requirement (kebutuhan pengguna)

Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan perasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

b. System requirement (kebutuhan system)

Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

c. Software design specification ( spesifikasi rancangan perangkat lunak)

Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

Secara umum, requirement dibagi menjadi 2 yaitu

Functional requirement : menjelaskan tentang fungsional dari sistem
Non-Functional requirement : yang berperan untuk member batasan pada solusi atau biasa disebut quality requirement.
Requirement yang baik mempunyai karakteristik untuk tetap konsisten, dibutuhkan, tidak ambigu, dan bisa diverifikasi. Selain itu requirement juga harus lengkap, kenapa?
• Kesesuaian dengan keinginan pelanggan.
• Mengestimasi serta menjaga jadwal dan biaya pengembangan
• Menjaga arsitektur, desain, implementasi, dan tes dari pengembangan agar terhindar dari ketidak lengkapan dan kesalahan karena asusmsi yang salah.
• Menghindari ambigu
• Keamanan, telah terbukti banyak kegagalan terjadi karena tidak lengkapnya requirement.

Donald Firesmith merekomendasikan menggunakan multi requirement model sehingga sudut pandang bisa lebih luas dan detil, model tersebut harus di identifikasi, analisis, dan didokumentasikan. Gunakan checklist untuk memeriksa apakah model telah terimplementasi dalam requirement. Buatlah model sesuai dengan kebutuhan proyek secara spesifik. Serta memastikan pengalaman dan keragaman anggota team untuk menyesuaikan dengan kekomplekan sistem yang sedang dibangun. Selain itu gunakan repository untuk menyimpan metadata requirement untuk mendapatkan requirement sesuai dengan kebutuhan proyek, dan gunakan alat yang mampu mengidentifikasikan metadata dan report yang kurang. Dengan metode requirement iterative dan incremental, secara berkelanjutan kebutuhan pelanggan dan pengguna akan selalu berkembang sehingga requirement juga akan ikut berkembang, hal ini berarti requirement yang lengkap menjadi state yang relative.

Kelengkapan requirement harus tetap dijaga karena banyak requirement engineering yang tidak tahu bahwa sebenarnya requirement mereka kurang lengkap sehingga bisa menimbulkan “bencana” dalam pengembangan sistem, untuk itu perlu dibuat beberapa model requirement agar sudut pandang terhadap setiap detil bisa dipantau, den mengunakan repository untuk memudahkan dokumentasi dan verifikasi kepada stakeholder, selain itu memungkinkan juga melakukan check kelengkapan requirement berdasarkan template model proyek yang telah dispesifikasikan sesuai dengan kompleksitasnya.

Banyak orang sering salah dalam mendefinisikan requirement untuk sistem yang mereka bangun, kerena mereka kurang mendapat pelatihan dan pengalaman dalam membuat requirement. Bahkan di bangku kuliah yang mengajarkan mata kuliah system engineering hanya mengajarkan pengenalan untuk materi menulis requirement.

Aspek yang penting dari sistem engineering adalah merubah kebutuhan user menjadi jelas, ringkas, dan dapat diverifikasi. Requirement yang baik menyatakan sesuatu yang dibutuhkan, dapat diverifikasi, memungkinkan, dan Jelas.

Terdapat beberapa masalah yang sering ditemui dalam membuat requirement, diantaranya adalah : membuat asumsi yang buruk, menulis implementasi (HOW) daripada requirement (WHAT), menjelaskan operasional daripada kebutuhan, mengunakan istilah yang salah, mengunakan bahasa yang kurang tepat, requirement tidak lengkap, dan menspesifikasikan requirement secara berlebihan.

Asusmsi yang buruk terjadi karena pembuat requirement tidak mempunyai akses yang cukup terhadap informasi yang dibutuhkan. Hal ini bisa dikurangi dengan cara mendokumentasikan informasi yang kritis seperti kebutuhan, tujuan, batasan, misi dan lain-lain. Selain itu semua asumsi juga harus didokumentasikan sehingga ketika direview asumsi bisa diperbaiki jika tidak sesuai.

Spesifikasi requirement harus menyatakan Apa yang dibutuhkan (WHAT), bukan bagaimana hal tersebut di sediakan (WHY). Caranya dengan mentanyakan mengapa (WHY) anda membutuhkan requirement tersebut.

Istilah juga penting untuk diperhatikan, penulis requirement harus bisa membedakan istilah shall (bisa), will (akan) ,dan should (harus). Requirement mengunakan Shall (bisa), pernyataan fakta mengunakan will (akan), dan Tujuan mengunakan Should (harus). Saat ini Requirement Spesification telah berpindah dari yang berkarateristik waterfall menjadi iterative, incremental, parallel, dan timebox.

Iterative Requirement Engineering : cocok digunakan untuk proses pengembangan yang terdapat fase penting yang belum pasti, misalnya pada software yang dibuat untuk ditawarkan kepada pelanggan, requirement pada software ini bisa berubah 180 deraajat karena pelanggan bisa membutuhkan sesuatu yang belum dipikirkan oleh pengembang, oleh sebab itu model iterative requirement engineering cocok untuk pengembangan software diatas, untuk memperbaiki dan meningkatkan kualitas software perlu melakukan iterasi yang berulang-ulang.

Incremental Requirement Engineering : Jika software yang akan dibuat terlalu besar dan komplek sehingga tidak bisa dibuat semua sekaligus, maka incremental requirement engineering sesuai untuk pengembangan software tersebut. Hal ini dikarenakan requirement elicitation, analysis,dan specification biasanya dilakukan secara incremental, dengan penambahan requirement dilakukan harian atau mingguan setelah perubahan signifikan dilakukan. Contoh yang paling mudah ditemukan adalah software seperti **legal copy** of microsoft word atau **legal copy** of corel draw yang mempunyai banyak versi seiring dengan perubahan tahun.

Parallel Requirement Engineering : dilaksanakan jika pengembangannya memiliki banyak aktifitas dan harus atau bisa dilakukan secara bersamaan, biasanya dalam proyek tersebut memiliki banyak sumber daya manusia dan hanya memiliki tenggat waktu yang rasional.

Timebox Requirement Engineering : jika proyek diselesaikan dalam waktu tertentu (deadline), maka harus dilakukan dengan memberikan batasan waktu (timebox) terhadap fase.Yang perlu diperhatikan adalah keempat karateristik tersebut tidak harus dipilih salah satu dalam pengembangan requirement, namun sebaiknya digunakan semuanya, karena sejatinya keempat karakteristik tersebut tidak bersebrangan dan bisa mendukung satu sama lain untuk kelangsungan suatu proyek.
Modern Requirement

Yang menjadi tulang punggung dari modern requirement adalah repository. Dengan adanya repository memungkinkan untuk mengkontrol requirement dengan lebih fleksibel. Siapa yang menulis requirement, siapa yang mensetujui dapat mudah diketahui, perubahan dan history perubahan requirementpun bisa dilakukan, status pengerjaan requirement pun bisa diset dan dilihat ketika tahap pengembangan.

Selain itu dokumen requirement bisa dengan mudah digenerate dari repository dengan banyak versi untuk stakeholder yang berbeda-beda. Selain itu modern requirement juga terintegrasi dengan aktifitas dari stakeholder (misal IDE untuk menganalisa dan mendesign perangkat lunak) sehingga memudahkan dalam kerja sama tim pengembang perangkat lunak.

Pada akhirnya modern requirement mampu menghilangkan permasalah yang muncul di traditional requirement. Pembuatan requirement saat ini lebih cepat, lebih murah, dan mudah dikelola, selain itu requirement yang kurang lengkap dan tidak konsisten, ambigu, susah dimengerti lebih mudah diketahui dan diperbaiki karena fasilitas evaluasi modern requirement yang bisa melakukan review dan perubahan requirement di repository dengan mudah dan cepat.
Modern Requirement tool

Terdapat beberapa tool yang medukung modern requirement diantaranya adalah iRise Application Simulator. Tujuan dari iRise adalah memungkinkan bisnis analis / requirement engineering untuk mengembangkan requirement sekaligus dengan membuat simulasi aplikasi sehingga ketidaksamaan persepsi requirement dapat dihindari antar stakeholder. Selain itu terdapat JIRA , yang merupakan bug, issue tracking, dan project manajement system. JIRA didesain dengan focus penyelesaian tugas dengan mudah dan fleksibel. Selain itu memungkinkan untuk menuliskan fungsional baru sehingga JIRA bisa dipergunakan sebagai requirement repository.
Sumber :

1. http://romisatriowahono.net
2. http://en.wikipedia.org/wiki/Requirement
3. http://www.irise.com/products/
4. http://www.atlassian.com/beyond/go_beyond.jsp
5. http://santang.wordpress.com/2008/10/16/software-dan-karakteristiknya/