Senin, 15 Februari 2016
10 ( Sepuluh ) Perangkap dalam Rekayasa Kebutuhan!
Sedikit ilmu yang saya dapatkan dari perkuliahan, semoga bermanfaat bagi pembaca.
Kali ini saya akan membahas mengenai perangkap dalam rekayasa perangkat lunak. Perangkap perangkat lunak yang dimaksud di sini adalah hal-hal yang menyebabkan suatu perangkat lunak itu menjadi perangkat lunak yang tidak sesuai dengan kebutuhan, bisa disebut errror atau cacat baik dalam skala besar atau kecil.
Berikut adalah hal-hal yang dianggap sebagai perangkap dalam Rekayasa Kebutuhan.
1. Tidak mengerti tentang "kebutuhan".
Kebutuhan yang dimaksud pada bahasan kali ini adalah Kebutuhan akan Perangka Lunak. Para pemangku kepentingan (Stakeholder) memiliki pandangan atau pemikiran yang berbeda tentang kebutuhan sehingga menyebabkan kebingungan ketika proses untuk mengetahui spesifikasi kebutuhan akan perangkat lunak.
Solusi yang bisa dilakukan adalah dengan meningkatkan keberadaan jenjang kebutuhan. Jangan sampai kebutuhan sebagai dasar terbentuknya sebuah perangkat lunak itu sendiri diabaikan atau tidak begitu dipikirkan. Selain itu pembelajaran tentang Rekayasa Kebutuhan Perangkat Lunak kepada stakeholder juga perlu dilakukan untuk paling tidak menyamakan pandangan yang sebelumnya berbeda tentang perangkat lunak
2. Kurangnya Keterlibatan Pelanggan
Pelanggan adalah stakeholder yang menjadi target perangkat lunak atau yang akan menggunakan (komersil) perangkat lunak. Oleh karena itu tidak wajar jika pelanggan memiliki keterlibatan yang minim dalam proses spesifikasi kebutuhan perangkat lunak. ada 2 hal yang menyebabkan minimnya keterlibatan perangkat lunak, yaitu
1. pelanggan yang tidak mau terlibat.
2. Pengembanga tidak melibatkan user dari berbagai latar belakang ( non super user)
2 hal ini akan menyebabkan kebutuhan yang sebenarnya tidak tersampaikan sehingga perangkat lunak bisa jadi tidak memuaskan pelanggan nantinya.
Solusi untuk permasalahan ini adalah dengan mengidentifikasi kelas-kelas pengguna sehingga nantinya kita bisa mengidentifikasi individu-individu dari tiap kelas tersebut. mengidentifikasi kelas-kelas pengguna bisa dengan memperhitungkan frekuensi penggunaan fitur dan level akses.
3. Kebutuhan yang kabur atau ambigu
Hal ini bisa disebabkan karena pelanggan atau pengguna tidak bisa menyampaikan kebuthan dengan menggunakan bahasa alamiah. Kebutuhan ambigu ini akan mengakibatkan pengembang menggunakan pandangan masing-masing mengenai kebutuhan padahal belum tentu yang dimaksud sesuai dengan kebutuhan yang sebenarnya.
Solusi untuk permasalahan ini adalah pengembang harus terus berusaha untuk mendapatkan kebuthan secara spesifik dan terukur dari pengguna atau pelanggan, bukan kebutuhan yang umum atau kabur. Selain itu kebutuhan juga harus dipastikan dapat dicapai dan direalisasikan.
4. Tidak Ada Prioritas
Hal ini disebabkan karena pelanggan menganggap semua kebutuhannya penting dan pengembang cenderung meremehkan kebutuhan yang sebenarnya adalah kebutuhan yang penting. Selain itu hal ini juga bisa disebabkan karena pengembang tidak memperhitungkan keterbatasan kemampuan sumber daya yang ada sehingga kenyataan nantinya tidak sesuai dengan harapan.
Solusi untuk permasalahan ini adalah memperhitungkan kebutuhan fungsional yang diturunkan dari deskripsi usecase sehingga akan lebih mudah dikenali dan diprioritaskan. Penggunaan tingkat skala prioritas dengan berdasarkan nilai yang diproyeksikan oleh pengguna atau pengembang menyangkut hal-hal seperti perkiraan biaya, risiko teknis, dll.
5. Membangun fungsionalitas yang tidak digunakan siapapun
Hal ni disebabkan karena pengguna tidak bisa membedakan antara kebutuhan dan keinginan sehingga beberapa fungsi nantinya hanya digunakan beberapa saat saja. Selain itu terlalu seringnya pengembang berasumsi serta menambahkan perangkat lunak agar terlihat menakjubkan sebenarnya malah menyebabkan fitur tidak digunakan sehinggan mengeluarkan biaya dan tenaga secara sia-sia.
Solusi untuk hal ini adalah menggali lebih dalam tentang masing-masing kebutuhan. Dengan mengetahui latar belakang kebutuhan itu muncul, maka kita akan bisa mengklasifikasikan antara kebutuhan dan keinginan.
6. Paralis Analisis
Hal ini disebabkan karena perancang dan programmer tidak mau bekerja berdasarkan spesifikasi yang belum lengkap padahal spesifikasi kebutuhan itu sendiri lengkap ditengah atau menjelang akhir proyek.
Solusi untuk hal ini adalah dengan melakukan proses pengembangan Perangkat Lunak secara iteratif dengan menetapkan milestones (*kejadian penting).
7. Scope Creep
Hal ini disebabkan karena konsumen seringkali tidak tahu yang sebenarnya ia butuhkan. Selain itu juga disebabkan karena keinginan yang di anggap kebutuhan dan terus berubah-berubah.
Solusi untuk permasalahan ini adalah dengan menempatkan dokumen spesifikasi kebutuhan perangkat lunak sebagai sutau kontrak kesepakatan antar kedua belah pihak. Selain itu pertimbangan risiko munculnya perubahan kebutuhan mengharuskan pemberian waktu tenggang dan sumber daya cadangan.
8. Proses perubahan kebutuhan yang tidak memadai
Hal ini disebabkan karena penyampaian permintaan kebutuhan secara informal kepada programmer dan tidak didokumentasikannya alasan terjadi perubahan.
Solusi dari permasalahan ini adalah dengan memperbaiki mekanisme pengontrolan perubahan. Selain itu juga bisa dengan menggunakan perkakas bantu untuk manajement perubahan dan pelacakan, misalnya dengan sub-version-sytem, bug tracking system, dan change control board.
9. Analisa perubahan dampak yang tidak memadai
Hal ini disebakbkan karena kurangnya pengetahuan dan pengalaman dari sistem analys untuk menyetujui perbuahan yang diminta konsumen.
Solusi dari permasalah ini adalah dengan memahami metode analisis yang sistematis dan baku terhadap setiap perubahan keputusan
10. Kontrol versi yang tidak memadai.
Penyebab utama hal ini adalah pengelolaan perubahan dokumen yang kurang baik.Sehingga untuk menyelesaikan permasalahan ini dalah dengan meningkatkan manajemen dokumentasi, merevisi SKPL setiap adanya perubahan yang telah disepakati oleh semua pihak yang berkepentingan, serta menggunakan perkakas bantu sub-versi.
