Deras masuknya produk perangkat lunak dari luar negeri di satu sisi menguntungkan pengguna karena banyaknya pilihan produk dan harga. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak yang masuk ke Indonesia. Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia 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). APA YANG DIUKUR? 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 sebagai: 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...
Meluruskan Salah Kaprah Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak (Software Engineering), sedikit mengalami pergeseran makna di realita dunia industri, bisnis, pendidikan maupun kurikulum Teknologi Informasi (TI) di tanah air. Di industri, para tester, debugger dan programmer sering salah kaprah menyandang gelar Software Engineer. SMK di Indonesia juga latah dengan membuka jurusan Rekayasa Perangkat Lunak, meskipun secara kurikulum hanya mengajari bahasa C atau Pascal (mungkin lebih pas disebut jurusan pemrograman komputer) 😉 Tulisan ini berusaha meluruskan salah kaprah yang terjadi tentang Rekayasa Perangkat Lunak (Software Engineering) berdasarkan kesepakatan, acuan, dan standard yang ada di dunia internasional. Sejarah munculnya Rekayasa Perangkat Lunak sebenarnya dilatarbelakangi oleh adanya krisis perangkat lunak (software crisis) di era tahun 1960-an. Krisis perangkat lunak merupakan akibat langsung dari lahirnya komputer generasi ke 3 yang canggih, ditandai dengan penggunaan Integrated Circuit (IC) untuk komputer. Performansi hardware yang meningkat, membuat adanya kebutuhan untuk memproduksi perangkat lunak yang lebih baik. Akibatnya perangkat lunak yang dihasilkan menjadi menjadi beberapa kali lebih besar dan kompleks. Pendekatan informal yang digunakan pada waktu itu dalam pengembangan perangkat lunak, menjadi tidak cukup efektif (secara cost, waktu dan kualitas). Biaya hardware mulai jatuh dan biaya perangkat lunak menjadi naik cepat. Karena itulah muncul pemikiran untuk menggunakan pendekatan engineering yang lebih pasti, efektif, standard dan terukur dalam pengembangan perangkat lunak. Dari berbagai literatur, kita dapat menyimpulkan bahwa Rekayasa Perangkat Lunak adalah: Suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal requirement capturing (analisa kebutuhan pengguna), specification (menentukan spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai pemeliharaan sistem setelah digunakan. Kalimat “seluruh aspek produksi perangkat lunak” membawa implikasi bahwa bahwa Rekayasa Perangkat Lunak tidak hanya berhubungan dengan masalah teknis pengembangan perangkat lunak tetapi juga kegiatan strategis seperti manajemen proyek perangkat lunak, penentuan metode dan proses pengembangan, serta aspek teoritis, yang kesemuanya untuk mendukung terjadinya...
Menyegarkan Kembali Pemahaman tentang Requirement Engineering...
Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan). Banyak definisi yang diungkapkan oleh para peneliti tentang requirements engineering. Satu definisi yang cukup jelas dan diterima secara umum adalah yang diuraikan oleh Pamela Zave [Zave-97]: Requirements engineering adalah cabang dari software engineering yang mengurusi masalah yang berhubungan dengan: tujuan (dunia nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain (dalam satu famili). Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan sebuah project pengembangan software sebagian besar disebabkan oleh masalah requirements dan spesifikasinya [Standish-94]. Untuk merangkum masalah yang ingin dipecahkan dalam cabang ilmu requirements engineering, kebanyakan pakar mengamini ungkapan Ed Yourdon dalam foreword yang ditulisnya untuk buku Managing Software Requirements – A Unified Approach karya Dean Leffingwell [Leffingwell-00]. Ed Yourdon menggunakan istilah “the rock problem (masalah batu) sebagai diskusi dasar masalah yang selalu muncul dalam proses pengerjaan proyek software. Customer (pelanggan) yang datang kepada kita untuk mengerjakan sebuah proyek pengembangan software, adalah ibarat seseorang yang mengatakan kepada kita, “Tolong buatkan saya batu”. Ketika kita memberikan kepadanya sebuah batu, dia akan melihatnya sebentar dan mengatakan kepada kita, “Ya terima kasih, tapi sebenarnya yang saya inginkan adalah sebuah batu kecil berwarna biru”. Dan ketika kita bawakan untuknya batu kecil berwarna biru, dia mengatakan bahwa yang diinginkan adalah yang “bentuknya bulat”. Demikian seterusnya proses iterasi (iteration) terjadi berulangkali sampai akhirnya kita dapatkan yang...