3. prespektif stakeholder
Post on 09-Dec-2014
135 Views
Preview:
DESCRIPTION
TRANSCRIPT
Analisa Kebutuhan Perangkat Lunak
Prespektif Stakeholder
Djoko Soerjanto, M.Kom
https://www.facebook.com/groups/analisa.kpl
Pendahuluan Seorang manajer produksi suatu perusahaan,
mengajukan permintaan sistem pelacakan material kepada staf TI. Sistem ini diharapkan dapat melacak pemakaian material setiap bagian proses, sehingga nantinya bisa diketahui lebih cepat dan akurat asal permasalahan dan siapa yang bertanggung jawab.
Staf TI mengiyakan permintaan dan juga mengajukan jadwal pertemuan dengan manajer dan staf produksi. Akan tetapi direspon dengan menolak karena kesibukan masing-masing dan merasa itu menjadi tanggung jawab bagian IT.
Akhirnya staf TI membangun sistem berdasarkan asumsi-asumsi yang didasari dari pengalaman sebelumnya.
Situasi seperti di atas sering muncul dalam proses pengembangan PL.
Pelanggan tidak memahami bahwa pengembangan PL bukan hanya sekedar tanggung jawab pihak TI. Namun memerlukan semua pihak yang memiliki kepentingan dalam pengembangan proyek PL tersebut.
Pihak-pihak yang berkepentingan inilah yang disebut Pemangku Kepentingan ( stakeholder )
Kegagalan suatu proyek PL disebabkan salah satunya pada proses rekayasa kebutuhan.
Salah satu sumber permasalahan berasal dari pemangku kepentingan, karena ketidakpahaman dan ketidakmampuan pemangku kepentingan untuk menspesifikasi kebutuhan dengan baik.
Jadi, keterlibatan pemangku kepentingan antar pelanggan dengan pengembang adalah sangat krusial.
Siapakah Pemangku Kepentinghan
Itu ?
1. Pelanggan (Customer)
Seseorang atau organisasi yang meminta jasa pengembang untuk mengembangkan suatu perangkat lunak tertentu.
Contoh : pemilik modal (investor), pemilik sistem (System owner), dan pengguna (user)
2. Pemilik Modal
Seseorang atau sekelompok orang yang berperan dalam mendananai
atau membiayai suatu proyek pengembangan perangkat lunak.
3. Pemilik Sistem Seseorang atau sekelompok orang
yang berperan sebagai pemilik dari proses bisnis yang sedang direpresentasikan dalam sistem yang dibangun.
Pemilik sistem seringkali juga merupakan penyedia dana (pemodal) dari pengembangan proyek PL tersebut.
4. Pengguna Setiap orang yang secara langsung
menggunakan atau mengoperasikan perangkat lunak tersebut.
Pengguna sering juga disebut Operator.
5. Regulator
Seseorang atau suatu organisasi yang menetapkan aturan dan batasan baik
dalam pengembangan maupun pengoperasian perangkat lunak
tersebut.
6. Penyelia ( vendor )
Seseorang atau sekelompok orang atau organisasi yang menyediakan teknologi atau jasa yang digunakan
bagi pengembangan atau pengoperasian perangkat lunak
tersebut.
7. Pengembang (developer) Seseorang atau sekelompok orang
yang bertanggung jawab mengembangkan perangkat lunak tersebut.
Termasuk disini Manajer Proyek (project manager) / Pemimpin Tim (Team Leader), Analis Sistem (System Analys) / Requirements Engineers, Programmer / Implementator, Designer, dan Penguji (Tester)
8. Analis SistemSeseorang atau sekelompok orang yang bertugas menganalisa dan
merancang sistem dalam pengembangan perangkat lunak.
9. Programmer
Seseorang atau sekelompok orang yang bertugas membuat kode program
yang merupakan implementasi dari hasil rancangan yang sudah dibuat
oleh analis sistem.
Contoh instansiasi customerdari sistem ATM ( Automatic
Teller Machine)
Kelas InstansiasiPemilik Modal Pemilik BankPemilik Sistem Bagian Customer BankingPengguna - Pemilik kartu ATM
- Pemilik kartu ATM dari bank lain
- Teknisi ATM
Kelompok Kebutuhan Pelanggan dalam menyatakan kebutuhan
(keinginan) atas perangkat lunak, kadang bentuknya sering abstrak, tidak lengkap, kabur dan tidak teratur.
Oleh karena itu, Analis berperan untuk mengidentifikasi mana yang merupakan kebutuhan dalam bentuk yang spesifik, terukur, teruji, realistis dan dapat diwujudkan.
Maka, dirasa perlu adanya kategori kebutuhan.
Kelompok Kebutuhan Selain kebutuhan Fungsional dan Non
Fungsional, juga ada kebutuhan berdasar tingkat dari pemangku kepentingan.
Kelompok Kebutuhan
KebutuhanBisnis
KebutuhanPengguna
Aturan Bisnis
Atribut Kualitas
KebutuhanSistem
KebutuhanFungsional
AntarmukaEksternal
Batasan
Tujuan
Apa
Bagaimana
Fungsional Non Fungsional
Kelompok Kebutuhan Lapisan teratas merepresentasikan tujuan
tingkat tinggi, yaitu tujuan yang hendak dicapai dari membangun sistem.
Lapisan tengah, merepresentasikan kondisi serta kapabilitas apa saja yang harus tersedia untuk mencapai tujuan tersebut.
Lapisan bawah, merepresentasikan bagaimana kondisi dan kapabilitas tersebut disediakan oleh sistem. Selain itu juga merepresentasikan antarmuka dengan sistem lain dan batasan yang harus dipatuhi.
Kebutuhan Bisnis Kebutuhan bisnis ( business requirements),
merepresentasikan tujuan akhir yang hendak dicapai ketika sistem dipakai.
Sering disebut Tujuan Project (Project Goal) Tujuan ini berasal dari pemilik sistem atau
penyandang dana sebagai pemilik organisasi.
Dari kebutuhan ini, analis sistem dapat mengidentifikasi pengguna dari sistem yang akan dibangun.
Contoh Kebutuhan BisnisSistem Kebutuhan BisnisATM Meningkatkan
pertumbuhan nasabah menjadi 5% tiap tahun
SIM Akademik Penghematan biaya pengadaan kertas sampai 20%
Online Ticketing Meningkatkan market share menjadi 5%
SIM Perijinan Terpadu Menurunkan biaya perizinan sampai 40%.
Kebutuhan Pengguna Merupakan kebutuhan fungsional yang
merepresentasikan tujuan dari pengguna (khususnya pengguna akhir) ketika hendak menggunakan sistem yang dibangun.
Kebutuhan ini diturunkan langsung dari kebutuhan bisnis dengan cara mengidentifikasi pengguna serta sistem lain yang terkait pencapaian kebutuhan bisnis ini. Kemudian mengidentifikasi tujuan pengguna.
Kebutuhan pengguna dapat dipakai sebagai acuan kasus pengujian penerimaan pengguna.
Contoh Kebutuhan PenggunaSistem Kebutuhan PenggunaATM Nasabah akan cek saldo
Nasabah akan ambil uangSIM Akademik Mahasiswa hendak
menyusun KRS baru.Orang tua hendak melihat prestasi akademik anaknya.
Online Ticketing Calon penumpang memesan tiket pesawat.Penumpang mencetak tiket elektroniknya.
Ingat ! Kebutuhan pengguna memang pada
akhirnya menjadi sebuah fungsi atau fitur sistem. Akan tetapi tidak semuanya itu merupakan kebutuhan pengguna, terkadang fungsi atau fitur itu merupakan perwujudan dari aturan bisnis atau atribut kualitas yang harus dipenuhi oleh sistem.
Aturan Bisnis Business Rule merupakan kebutuhan
non fungsional yang meliputi aturan dan kebijakan dari perusahaan maupun pemerintah, industri, dll.
Terkadang aturan bisnis ini mengandung atribut kualitas yang harus dipenuhi dari suatu layanan dari sistem ketika memenuhi kebutuhan pengguna.
Contoh Aturan BisnisSistem Aturan BisnisATM Teknologi kartu yang digunakan
harus memenuhi baku IEC.Otoritas keuangan negara menetapkan penggunaan smart card untuk kartu kredit paling lambat tahun 2015
SIM Akademik Mahasiswa hendak menyusun rencana kuliah semester ini.
Online Ticketing Setiap pemesanan tiket harus menyebutkan identitas calon penumpang.
Aturan Kualitas Quality Attributes merupakan kebutuhan
non fungsional yang memperjelas kebutuhan fungsional dengan menambahkan karakteristik dari sistem dalam pelbagai dimensi yang penting, baik bagi pengguna maupun pengembang.
Karakteristik tersebut menunjukkan unjuk kerja, ketersediaan, ketangguhan, efisiensi, efektivitas, dan portabilitas yang dimiliki sistem.
Contoh Atribut KualitasSistem Atribut KualitasATM Kartu dapat digunakan sampai
1.000.000 kaliKetersediaan layanan minimal 92%
SIM Akademik Dapat melayani 100 transaksi per menit.Kapasitas penyimpanan minimal 10 tahun.
Online Ticketing Proses booking paling lama 1 menit. Update halaman jadwal penerbangan maksimal dalam 2 detik.
Kebutuhan Fungsional Merupakan kebutuhan yang
menspesifikasi fungsi atau fitur yang harus ada pada sistem untuk membantu pengguna mencapai tujuan.
Kebutuhan fungsional inilah yang menjadi acuan bagi analis dan penguji dalam membuat rancangan sistem dan pengujian sistem.
Contoh Kebutuhan FungsionalSistem Kebutuhan FungsionalATM Jika saldo akhir setelah dikurangi
jumlah debet akan lebih kecil dari saldo minimal yang diperkenankan, maka sistem menampilkan peringatan dan transaksi digagalkan.
SIM Akademik Dosen dapat mengubah presentase dari komponen penilaian.
Online Ticketing Sistem mengirimkan SMS ke penumpang jika terjadi perubahan jadwal penerbangan.
Antarmuka Eksternal External interface merupakan
kebutuhan non fungsional yang mendeskripsikan kondisi atau karakteristik yang harus dipenuhi sistem sebagai bentuk interaksi dengan entitas di luar dirinya.
Entitas luar bisa berupa sistem lain, atau individu ynag berinteraksi dengan sistem.
Contoh Antarmuka EksternalSistem Antarmuka EksternalATM Koneksi basis data menggunakan
TCP/IP.Menu minimalis dalam bahasa Indonesia dan Inggris.
SIM Akademik Sistem menggunakan protokol https via browser.Harus dapat ditampilkan di browser IE 7.0 ke atas, Firefox Opera dan Chrome.
Online Ticketing Sistem dapat mencetak e-tiket setidaknya dalam format PDF, DOC dan DOCX.Data e-tiket harus mematuhi metadata dengan OpenDoc agar dapat diimpor Departemen Perhubungan Udara.
Batasan Constraints, merupakan kebutuhan
non fungsional dari sistem yang membatasi pilihan yang dapat dilakukan oleh pengembang dalam pengambilan keputusan terkait proses perkembangan perangkat lunak.
Batasan ini terkait dengan metode dan teknologi yang digunakan.
Contoh BatasanSistem BatasanATM Monitor harus 14” dan resolusi
800x600Tinggi ATM antara 130 cm s/d 150 cm
SIM Akademik Ukuran transaksi tidak boleh melebihi 64KB.Sistem harus dibangun menggunakan open source.
Online Ticketing Jumlah karakte untuk nama depan tidak boleh lebih dari 20 karakter.Satu sesi koneksi dengan basis data tidak boleh lebih dari 10 menit.
TANGGUNG JAWAB & HAK PELANGGAN
Tanggung jawab Pelanggan
1) Memberitahukan kepada pengembang tentang bisnisnya dan mendefinisikan istilah-istilah bisnis yang digunakan.
2) Meluangkan waktu yang diperlukan untuk proses pengumpulan kebutuhan, mengklarifikasi, dan secara iteratif menyempurnakannya.
3) Menyediakan masukan yang diperlukan untuk spesifikasi kebutuhan spesifik dan presisi mungkin.Spesifik -> unik, sederhana, tidak bias, jelas dan konsisten.
4) Membuat keputusan tepat waktu berkaitan dengan kebutuhan yang diminta.
5) Mengulas kembali setiap dokumen kebutuhan dan mengevaluasi semua prototipe.
6) Mengkomunikasikan setiap perubahan kebutuhan sesegera mungkin.
Hak Pelanggan Mengharapkan analis belajar tentang
bisnis dan tujuan pelanggan akan sistem yang dibangun.
Mengharap analis menspesifikasikan kebutuhan yang telah didapatkan dari proses penyusuan kebutuhan yang telah dilakukan.
Meminta analis menjelaskan semua produk yang dihasilkan dari rekayasa kebutuhan.
Mengharapkan pengembang memperlakukan pelanggan dengan rasa hormat dan menjaga sikap profesional dan mau bekerjasama sepanjang interaksinya.
Menjelaskan karakteristik dari produk sehingga memudahkan dan menyenangkan untuk digunakan.
Menerima sistem yang memenuhi kebutuhan fungsional dan non fungsional sepanjang yang telah dikomunikasikan dengan pengembang.
Contoh Tanggung Jawab Yang Tidak dilakukan Pelanggan
Tanggung Jawab Deskripsi#1 Manajer produksi tidak berusaha
memberikan pengetahuan yang cukup kepada pengembang tentang ranah sistem.
#2 Manajer tidak berkenan menyediakan waktu yang cukup untuk proses rekayasa kebutuhan.
#3 Tidak spesifik mengungkapkan masukan spesifikasi sistem.
#4 Tidak menghargai proses yang digunakan analis dalam rekayasa kebutuhan.
Sign-off Istilah merujuk penandatanganan
dokumen spesifikasi kebutuhan oleh kedua belah pihak.
Penandatanganan ini menandai persetujuan pihak pelanggan terhadap spesifikasi kebutuhan yang telah diformalisasi oleh pengembang. Selain itu sebagai janji dari pengembang kepada pelanggan untuk memenuhi semua kebutuhan dalam produk yang dikembangkan.
Sikap ekstrem pemangku kepentingan atas ‘sign-off’
Mereka tidak peduli, dan mengganggap sign-off sebagai prasayarat bahwa pengembang mulai bekerja dan tidak mengganggu mereka lagi.
Mereka takut dipersalahkan, seringkali bukanlah keyperson yang dapat mengambil keputusan.
Solusi ? Persetujuan kedua pihak, bahwa sign-off
adalah upaya untuk memiliki pemahaman yang sama terhadap ranah sistem, yang meliputi fungsionalitas, kualitas dan batasan yang hendak dibuat.
Pemahaman ini dibangun dari setiap informasi dan kebutuhan yang berhasil dikumpulkan (elisitasi) dan feedback dari pelanggan saat verifikasi.
Pemahaman ini akan berkembang sedikit demi sedikit mengikuti waktu.
Question ?
top related