chapter 12 bridging Document
Menjembatani DokumenSebuah kebutuhan yang baik menganalisa untuk menyiapkan sebuah kebutuhan spesifikasi perangkat lunak dengan hati -hati dan mengantarkan kepaada tim pengembang dan tester, hanya untuk mempunyai beberapa pengangan penerima tentang pengembangan perangkat lunak. berikut adalah beberapa tipe komplain :
· konten ini tidak terlalu cukup detail. sakarang kami harus untuk melakukan analisa pekerjaan untuk mengejar dahulu informasi ini.
· konten ini tidak detail di kebutuhan. kami tidak membutuhkan semua informasi ini, hanya sebuah ide yang umum. kami sudah tahu yang mana untuk di bangun. kami tidak mempunyai waktu untuk membaca konten ini. nyatanya, kami tidak berpikir kami akan mengerjakannya.
· dokumen ini berisi terlalu banyak informasi desain. analis sedang mencoba untuk melakukan pekerjaan desain yg kami kira kami lakuakan. ini biasanya di sebut "requirments" telah dieliminasi pilihan kreatif kami.
· dokumen ini tidak tertata pada sebuah pemikiran. kami tidak dapat menemukan informasi yang kami inginkan.
· Banyak sekali teks disini. tapi kami harus menghitung sebuah waktu untuk kesusahan tentunya Ada banyak teks di sini, tapi kami mengalami kesulitan mencari tahu persis apa persyaratan. Kami harus menyeberang melalui semua teks deskriptif dan informasi latar belakang dalam setiap paragraf besar dan harap kami menafsirkan kebutuhan sendiri dengan benar. Kami bahkan tidak tahu betapa banyak persyaratan yang ada.
Anggota tim project aplikasi perangkat lunak membuat macam dokumen jembatan, seperti sebuah SRS, dokumen ini mengkomunikasikan kepada orang lain jadi mereka dapat melakukan bagian dari pekerjaan projek mereka. yang mana, dokumen ini dijalankan seperti sebuah menjembatan antara komunitas pekerja satu dan grup yang lain yang melakukan pekerjaan.
Pemilik project ini, menuliskan dokumen jembatan khusus dari point - point yang dimiliki dari sudut pandang pemilik project. kepercayaan yang bagus ini, pemilik menseleksi informasi yang telah masuk, dan dia menuliskan dan mengatur dokumen tersebut secara terstruktur sehingga dia mempunyai rasa dari prespektif yang sama. tapi itu tidak perlu berpikiran sama ke arah itu.
Maka, ketika SRS itu selesai pembatas dari analisa kebutuhan dan mendapatkan di atas pikiran pengembang, terkadang kebanyakan orang tidak tepat dengan pikiran pengembang.
kami berfikiran kita harus menuliskan tiap - tiap dokumen jembatan dari dokumen prespektif konsumen-aliran dokumen user-dari pada itu sudut pandang pemilik project. menganalisa kebutuhan adalah sumber yang penting untuk melihat pada input informasi terkandung yang penting diperhatikan, penguji, manjer proyek, dan lainnya yang mana akan harus mengunakan spesifikasi untuk menentukan bagaimana menuliskan dan struktur terbaik. pelanggan dari project adalah salah satu sumber inputan yang penting mengenai informasi apa yang terkandung, bagaimana mengatur proyek, gaya tulisan, dan menepatkan tingkat kedetailan. bekerja secara bersama untuk mendefinisikan struktur dokument - dokumen dan mengambarkan isi sebuah pendekatan koloborasi untuk mengembangkan kebutuhan.
kami baru - baru ini menjumpai sebuah masalah jembatan dokumen pada sebuah perusaahan telepon yang mana telah berkerja dengan kami. organisasi tersebut telah mempunyai banyak menganalisa bisnis yang mana membuat spesifikasi kebutuhan sehingga mereka (hand off) untuk system arsitek pada project perusahaan tersebut. seorang arsitek mengkomplain kepada kami bahwa dokumen SRS tersebut tidak selalu cocok dengan kebutuhanya benar. walaupun terkadang project bisnis analis telah menyelesaikan sebagaian dari desain tingkat teratas, yang mana arsitek mempertimbangkan seperti apa yang dipertanggung jawabanya. pada situasi lainya, kebutuhan utama dari tulisan saat tingkat kebutuhan user. kemudian arsitek mengantur kebutuhan fungsionalnya. Arsitek kemudian harus menurunkan kebutuhan fungsional yang diperlukan. Ia menganggap ini sebagai tanggung jawab analis, bukan miliknya.
Ini adalah merupakan situasi klasik di mana arsitek dan analis bisnis perlu duduk bersama dan menyepakati apa informasi harus masuk ke dokumen SRS. Analis bisnis di organisasi ini telah melakukan yang terbaik untuk menyediakan informasi yang mereka mengira arsitek dibutuhkan di tingkat yang tepat detail. Beberapa masukan tambahan dari para arsitek untuk mengarahkan upaya analis akan pergi jauh ke arah memastikan bahwa spesifikasi masa depan benar menjembatani kesenjangan antara perkembangan kebutuhan dan desain perangkat lunak.
Kami hanya mengusulkan bahwa analis, pengembang, dan pemangku kepentingan lainnya menempatkan kepala mereka bersama-sama untuk memutuskan bagaimana cara terbaik untuk mempersiapkan spesifikasi kebutuhan yang mereka buat. Fokus pada isi yang sesuai, ini sebenarnya dapat menyebabkan dokumen lebih pendek karena penulis memiliki pemahaman yang lebih jelas tentang apa yang akan dimasukkan dan apa yang tidak. Prinsip yang sama menyepakati bentuk dan isi berlaku untuk merancang dokumen, rencana proyek, dan deliverable proyek lain yang ditargetkan pada pembaca yang spesifik.
Siapa yang Membuat Panggilan itu?
Pertanyaan utama yang perlu dipertimbangkan ketika memutuskan bagaimana detail untuk membuat kebutuhan adalah: Siapa yang kita inginkan untuk membuat keputusan tentang rincian kebutuhan dan kapan? Jika kita bersedia untuk menunda banyak keputusan utama tentang kemampuan dan karakteristik produk kepada para pengembang, kita tidak perlu untuk memasukkan informasi sebanyak dalam dokumentasi kebutuhan. Namun, jika kita ingin menjelaskan dengan tepat apa yang kita harapkan akan dikirimkan, spesifikasi lebih lengkap yang diperlukan. kita perlu menyeimbangkan biaya dan risiko. Biayanya lebih untuk mengembangkan kebutuhan secara lebih rinci daripada meninggalkan kebutuhan yang lebih umum. Memilih jumlah yang tepat detail untuk memasukkan tergantung pada risiko yang terkait dengan meninggalkan keputusan tentang spesifik bagi pengembang.
Kami beri gambaran tentang detail kebutuhan. sebuah Rumah memiliki sistem alarm keamanan.Untuk menonaktifkan sistem, kami masukan kode pada keypad numerik. Pada satu tataran, kita bisa menyatakan kebutuhan untuk fungsi tersebut cukup sederhana: ketika sistem alarm berbunyi dan sensor bereaksi, user akan memasukan sebuah password untuk menonaktifkan bunyi sensor. statemen ini mengatakan maksud secara umum, tapi informasi ini tidak cukup bagi pengembang untuk tahu apa yang didesain dan dibangun. Berikut adalah beberapa pertanyaan yang muncul ketika mempertimbangkan implikasi dari kebutuhan fungsional:
· Apakah dari jumlah minimum dan maksimum dari digit diperbolehkan dalam kode akses
· Bagaimana seharusnya sistem berkesimpulan bahwa pengguna telah selesai memasukkan kode akses sehingga dapat mengevaluasi kode akses? atau haruskah user mengindikasikan bahwa password sudah terisi penuh , jadi seperti halnya pada evaluasi password
· Bagaimana pemilik rumah menetapkan dan mengubah password? Apakah ada default?
· Berapa lama sistem menunggu pengguna untuk memasukkan kode sandi yang benar sebelum terdengar alarm?
· apakah yang dilakukan sistem ketika user memasukan kode yang salah sebelum waktu penghitung habis?
· berapa banyak mencoba memasukan user dapat ? Atau fungsi waktu memungkinkan: user dapat memasukan sesuka mungkin kode dengan interval yang tetap.
· Jika pengguna memasukkan kode sandi yang salah, apakah timer reset ke nol atau apakah hitungan terus berjalan mundur sampai alaram berbunyi ?
· apa yang dilakukan sistem jika user tidak memasukan kode sandi dengan benar dalam jangka waktu yang sudah ditentukan?
Jelas, seseorang harus menjawab pertanyaan ini. Jika analis tidak menyediakan informasi semacam ini dengan detail di SRS, tanggung jawab turun ke pengembang untuk mengidentifikasi semua pertanyaan penting dan baik melacak jawaban atau membuat keputusan berdasarkan penilaian sendiri. Setiap analis harus memutuskan apakah dia ingin pengembang untuk datang dengan jawaban untuk pertanyaan cepat pada desain dan waktu konstruksi, atau apakah ia lebih suka memiliki pelanggan dan ahli subjek merekam informasi yang diperlukan dalam spesifikasi kebutuhan.
When More Detail Is Needed
Ada beberapa situasi di mana penulis hanya menuliskan spesifikasi yang sanggat detail dan disertai dengan penjelasan yang kompleks, informasi kebutuhan meningkatkan resiko pada proyek. ketika menghadapi sebuah situasi seperti ini akan menghabiskan banyak waktu daripada mengembangkan merinci kebutuhan.
pengembangan akan menjadi tenaga outsourcing. Setiap kali Anda melakukan outsourcing pembangunan perangkat lunak, proyek Anda akan mendapatkan keuntungan dari kebutuhan dokumentasi yang komprehensif. Ketika para pengembang adalah dari benua atau samudra lain, Anda tidak memiliki kesempatan untuk berhari-hari interaksi untuk menyempurnakan rincian, menjawab pertanyaan, dan menyelesaikan ambiguitas. Dalam budaya tertentu, pengembang akan menerapkan persis apa yang ditentukan, bahkan jika itu tidak lengkap atau masuk akal. Tanpa memiliki banyak kesempatan untuk klarifikasi, Anda tidak punya pilihan selain menyediakan semua informasi yang diperlukan dalam bentuk spesifikasi tertulis, desain, dan kasus uji penerimaan. Lakukan yang terbaik untuk menghapus ketidakpastian sebelum mengirim spesifikasi keluar untuk implementasi.
Proyek anggota tim terpisah secara geografis. Diperlukan sedikit pemisah antara peserta proyek untuk menghambat komunikasi. suatu project untuk menuliskan program seorang ilmuwan penelitian yang duduk hanya beberapa meter dari meja kami. Suatu hari ia pindah ke kantor baru sekitar seratus meter jauhnya. Produktivitas kami menurun drastis. Sekarang membutuhkan waktu lebih lama untuk mendapatkan pertanyaan kami dijawab. Kami harus mengatur pertemuan, menelepon, atau berjalan ke lorong dan berharap untuk menangkap telpon tersebut, padahal sebelumnya kami hanya harus memanggil pertanyaan kami untuk mendapatkan tanggapan segera.Jika Anda kwatir tentang ketersediaan perwakilan pelanggan untuk menyediakan detail yang hilang selama desain dan konstruksi, sebaiknya Anda menghasilkan informasi kebutuhan pengembang. Pengujian akan didasarkan pada kebutuhan. Jika penguji akan mencoba dan menuliskan sistem yang konprehensif tentang penggunaan dari kebutuhan tersebut. penguji harus tahu persis bagaimana sistem seharusnya berperilaku dalam berbagai keadaan. Bahkan, konsep "persyaratan dapat diuji" telah diusulkan sebagai tolok ukur perangkat lunak. Pengujian harus mencakup segala aspek tidak hanya perilaku hasil yang diharapkan tetapi juga pengecualian atau kesalahan diketahui kondisi yang dapat timbul. Oleh karena itu, spesifikasi persyaratan perlu untuk menjelaskan pengecualian ini cukup baik sehingga penguji dapat menentukan apakah perangkat lunak berfungsi dengan benar. mengidentifikasi kemungkinan masalah yang akan terjadi dan penanganan untuk membuat perangkat yang kuat.
diperlukan Perkiraan yang akurat. Manajer proyek atau pengembang yang harus menghasilkan upaya dan estimasi jadwal dari persyaratan harus cukup detail untuk memahami apa yang mereka hadapi. Editor harus mengedit dan menanggapi arahan masukkan oleh perintah" Cara SRS ditulis tidak memberikan petunjuk bahwa item ini salah satunya sangat lebih kompleks daripada 700 persyaratan fungsional lainnya dalam dokumen. Sulit untuk memperkirakan biaya pelaksanaan tanpa terurai bahwa pernyataan tingkat tinggi ke detail yang cukup untuk mendapatkan pegangan baik pada, kompleksitas ukurannya, dan kesulitan.
penelusuran kebutuhan yang dibutuhkan Persyaratan penelusuran adalah tindakan menciptakan hubungan logika antara persyaratan fungsional individu, asal- usul mereka (seperti kasus penggunaan, fitur produk, atau aturan bisnis), dan produk kerja yang diciptakan untuk memenuhi kebutuhan masing-masing. Seperti produk kerja hilir termasuk elemen desain, modul source code, test case, help screens, dan dokumentasi. jika penelusuran kebutuhan penting ke project, kita harus menspesifikan kebutuhan secara detail. Beberapa Persyaratan penelusuran mengkonfirmasi bahwa keadaan berikut terpenuhi:
· Semua kebutuhan ke depan untuk menelusuri elemen dari desain perangkat lunak.
· Setiap elemen desain dapat dicari kembali dengan persyaratan tertentu.
· Semua kode ditulis menelusuri kembali ke elemen desain sehingga untuk suatu kebutuhan.
· Semua persyaratan diimplementasikan dalam kode.
· Uji kasus ada untuk setiap Kebutuhan.
· Semua kasus uji melacak untuk setidaknya satu kebutuhan.
Ketika Detil Kurang Apakah tepat
Saat yang tepat untuk meninggalkan deskripsi persyaratan pada tingkat abstraksi yang lebih tinggi dalam keadaan beberapa. Mengenali bahwa ini panduan secara luas. Melakukan analisis risiko dan manfaat untuk menyeimbangkan potensi downside dari mengabaikan informasi penting terhadap upaya yang diperlukan untuk memasukkannya.
Pengembang memiliki pengalaman domain yang cukup besar. Pengembang yang memiliki pengetahuan yang luas aplikasi domain kadang-kadang dapat menyediakan banyak rincian persyaratan yang diperlukan. Hati-hati terhadap pengembang yang terlalu percaya, yakin bahwa mereka memahami apa yang pengguna butuhkan tanpa bertanya. Idealnya, perwakilan luas dari kelas pengguna tertentu akan bekerja dengan analis persyaratan untuk mengembangkan persyaratan. (Lihat Bab 6.) Selalu ada risiko ketika memutuskan menggunakan pengganti yang tidak akan menggunakan software yang dikembangkan. Pengembang teknologi canggih mungkin tidak mewakili pengguna akhir yang khas. Bahkan pengembang yang sangat berpengalaman kadang-kadang tidak menyadari kebutuhan saat ini dalam lingkungan bisnis yang berubah. Jika pengetahuan mereka sudah usang, mereka tidak dapat melakukan pekerjaan dengan baik penyediaan persyaratan hilang.
Pedoman yang tersedia. Ketika pedoman atau acuan tersedia untuk digunakan sebagai model, Anda tidak perlu untuk memasukkan semua rincian persyaratan dalam spesifikasi. Para pengembang dapat beralih ke produk yang ada atau dokumentasi sebagai acuan untuk rincian yang tidak disediakan dalam spesifikasi saat ini. Ini mungkin terjadi ketika rekayasa ulang aplikasi.
Solusi paket akan digunakan. Proyek-proyek yang akan memperoleh solusi paket komersial untuk seluruh atau sebagian dari kebutuhan mereka tidak perlu kebutuhan yang sangat rinci. Tidak ada gunanya menulis persyaratan fungsional komprehensif karena vendor paket sudah melakukan itu (atau jadi Anda berharap). Namun, itu jarang bahwa paket akan sepenuhnya memenuhi kebutuhan Anda, sehingga Anda masih harus menentukan persyaratan untuk paket ekstensi, integrasi, dan kustomisasi.
kebutuhan yang berarti
Tidak ada persyaratan spesifikasi pernah dapat sepenuhnya menggambarkan suatu produk. semua spesifikasi kebutuhan akan tahu persis apa yang dimaksudkan tanpa analis ejaan itu. Sebagai contoh, itu tidak masuk akal untuk berpikir bahwa setiap pembaca akan secara otomatis tahu mana fungsi sistem mengharuskan pengguna untuk login dan mana yang tidak. Ini tidak realistis untuk mengharapkan setiap pembaca untuk membedakan bagian-bagian dari sistem yang menuntut respon yang cepat terutama kali-dan untuk mengetahui apa yang waktu respon harus-dari bagian-bagian yang tidak memiliki ekspektasi kinerja tertentu.
contoh detail tingak kebutuhan
Anda mungkin memilih untuk mendokumentasikan kebutuhan fungsional Anda pada tingkat tinggi dan memiliki pengembang bekerja dengan pelanggan untuk mengisi kekosongan pada waktu desain dan konstruksi. Atau, Anda mungkin memiliki analis Anda bekerja dengan pelanggan dan ahli subjek untuk datang dengan rincian dan merekam mereka di SRS. Tanpa memandang mana Anda meletakkan informasi, ini adalah contoh semakin dekat dengan apa yang pengembang dan penguji akhirnya perlu tahu sehingga mereka dapat membangun dan memverifikasi perangkat lunak.
Persyaratan mutu juga menentukan berbagai pilihan arsitektur. Jika mereka yang berberdampak tinggi pada kebutuhan yang tidak tertulis karena orang-orang dengan pengetahuan yang mengasumsikan bahwa orang lain berbagi wawasan mereka, produk tersebut bisa gagal untuk memenuhi harapan untuk integritas kinerja, keandalan, dan sebagainya. Sebuah pengerjaan proyek yang mahal maka dapat dimulai dengan, membangun arsitektur baru untuk mencoba untuk memenuhi tuntutan lingkungan operasi.
0 komentar:
Posting Komentar