KONSEP DAN PRINSIP ANALISIS
1. ANALISIS KEBUTUHAN PERANGKAT LUNAK
Analisis kebutuhan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi. Perangkat lunak tingkat sistem dan perancangan perangkat lunak. Analisis persyaratan memungkinkan perekayasa system menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface perangkat lunak dengan elemen – elemen system yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak. Analaisi persyaratan perangkat lunak mengijinkan perekayasa perangkat lunak (dlm peran ini sering disebut analisis) utk memperhalus alokasi perangkat lunak dan membangun model – model data fungsional, dan domain tingkah laku yang akan di proses oleh perangkat lunak. Analisis persyaratan memberikan model – model yang akan diterjemahkan ke dalam data, arsitektur, interface, dan desain procedural kepada perancang perangkat lunak. Akhirnya, spesifikasi persyaratan memberikan cara kepada pengembang dan pelanggan untuk menilai kualitas perangkat lunak yang telah di bangun.
Analisis persyaratan perangkat lunak dapat dibagi menjadi 5 area kerja :
• Pengenalan masalah
• Evaluasi dan Sintesis
• Pemodelan
• Spesifikasi
• Kajian
Pada awalnya, analisis mempelajari spesifikasi system (bila ada) dan rencana proyek peangkat lunak. Penting untuk memahami perangkat lunak dalam suatu konteks system dan mengkaji ruang lingkup perangkat lunak yang telah digunakan untuk memunculkan estimasi perencanaan. Selanjutnya, adalah membangun komunikasi untuk analisis untuk menjamin pengenalan masalah. Tujuan analisis adalah mengenali elemen masalah dasar seperti dirasakan oleh pemakai / pelanggan.
Sintesis evaluasi dan pemecahan masalah adalah area mayor selanjutnya dari kerja analisis. Analisis harus membatasi semua objek data yang dapat di observasi secara eksternal, mengevaluasi aliran dan muatan informasi; mendefinisikan dan menguraikan semua fungsi perangkat lunak; memahami tingkah laku perangkat lunak dalam konteks kejadian yang mempengaruhi system; membangun karakteristik interface system; dan menemukan batasan desain tambahan. Masing – masing dari tugas tersebut berfungsi untuk menjelaskan masalah sehingga pendekatan atau penyelesaian keseluruhan dapat disintesis.
Sebagai contoh, pemasok besar suku cadang kendaraan bermotor membutuhkan system control inventaris. Analisis mendapatkan bahwa masalah yang berhubungan dengan system manual yang ada meliputi :
Ketidakmampuan untuk dengan cepat memperoleh status suatu komponen
Dua atau tiga hari berkali – kali memperbaharui suatu file kartu
Pemesanan kembali secara bertingkat kepada penjual yang sama karena tidak ada cara untuk menghubungkan para penjual dengan komponen dan sebagainya.
Sekali masalah di identifikasi, maka analisis menentukan informasi apa yang akan dihasilkan oleh system baru dan data apa yang akan diberikan kepada system. ¹Misalnya pelanggan menginginkan laporan harian yang menunjukkan suku cadang yang diambil dari inventaris dari beberapa jumlah suku cadang yang sama yang masih ada. Pelanggan menunjukkan bahwa petugas inventaris akan mencatat nomor identifikasi dari masing – masing suku cadang pada saat suku cadang tersebut keluar dari area inventarisasi.
Setelah mengevaluasi masalah yang ada dan juga informasi yang diperlukan (input – output), analis akan mulai mensintesa satu penyelesaian atau lebih. Untuk memulainya, data, fungsi – fungsi pemrosesan, dan tingkah laku system, di definisikan secara detail. Sekali informasi itu dibangun, maka arsitektur dasar pengimplementasian dipertimbangkan. Pendekatan klien / server tampaknya akan sesuai, tetapi apakah kebutuhan pemakai / pelanggan untuk hubungan itu dibenarkan? Proses evaluasi dan sintesis berlangsung sampai analisis dan pelanggan yakin bahwa perangkat lunak dapat ditentukan untuk langkah – langkah pengembangan selanjutnya.
Melalui sintesis analisis dan evaluasi, focus utama analisis adalah pada “apa” (what), bukan “bagaimana” (how). Data apakah yang diproduksi dan konsumsi, batasan apakah yang dipakai?
Selama aktifitas sintesis evaluasi dan solusi, analis menciptakan model – model system untuk lebih memahami aliran data dan control, operasi behavioral dan pemrosesan fungsional, serta muatan informasi. Model tersebut berfungsi sebagai pondasi bagi desain perangkat lunak dan sebagai dasar untuk membuat spesifikasi perangkat lunak.
2. TEKNIK KOMUNIKASI
Analisis persyaratan perangkat lunak selalu dimulai dengan komunikasi antara dua bagian atau lebih. Seorang pelanggan memiliki masalah yang dapat di pertanggung jawabkan melalui pemecahan berbasis komputer. Pengembang merespon permintaan bantuan (help) dari pelanggan. Komunikasi sudah dimulai. Tetapi sperti ditulis sebelumnya, jalan dari komunikasi ke pemahaman kadang – kadang penuh dengan lobang.
2.1 MENGAWALI PROSES
Teknis analisis paling umum digunakan utnuk menjembatani jurang komunikasi antara pelanggan dan pengembang dan sekaligus untuk memulai proses komunikasi, adalah dengan melakukan pertemuan pendahuluan atau wawancara. Pertemuan pertama antara perekayasa perangkat lunak (analis) dengan pelanggan dapat disamakan dengan kakunya kencan pertama antara dua remaja. Keduanya tidak tahu apa yang akan mereka katakana atau tanyakan; keduanya merasa mengkhawatirkan yang mereka katakana akan disalah artikan; keduanya berpikir kemana arah mereka (keduanya memiliki pengharapan yang sangat berbeda); keduanya ingin pertemuan itu segera berakhir; tetapi pada saat yang sama, keduanya ingin berhasil.
Akan tetapi, komunikasi harus diawali. Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan – pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan mengarah kepada pemahaman yang mendasar atas masalah, orang yang menginginkan penyelesaian, sifat penyelesaian yang dinginkan, dan efektivitas pertemuan pertama itu sendiri. Rangkaian pertama dari pernyataan bebas konteks berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan. Sebagai contoh, analis dapat bertanya :
¤ Siapa dibalik permintaan untuk pekerjaan ini ?
¤ Siapa yang akan menggunakan pemecahan ini ?
¤ Apa keuntungan ekonomi dari pemecahan yang berhasil ?
¤ Apakah ada sumber lain untuk pemecahan yang anda inginkan ?
Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan :
Bagaimana anda akan menandai output yang baik yang akan didapatkan oleh pemecahan yang berhasil ?
Masalah apakah yang akan diselesaikan oleh pemecahan ini ?
Dapatkah anda memperlihatkan kepada saya (atau menjelaskan) lingkungan dimana pemecahan tersebut akan digunakan ?
Adakah masalah atau batasan kinerja yang khusus yang akan mempengaruhi cara pemecahan tersebut didekati?
Rangkaian pertanyaan yang terakhir berfokus pada efektivitas pertemuan. Gause dan Weinberg [GAU89] membuat pertanyaan – pertanyaan mengusulkan daftar berikut ini :
Apakah anda adalah orang yang tepat untuk menjawab pertanyaan – pertanyaan ini ? apakah jawaban anda bersifat resmi ?
Apakah pertanyaan saya ini bersifat relevan dengan masalah yang anda hadapi ?
Apakah anda mengajukan terlalu banyak pertanyaan ?
Apakah ada orang lain yang dapat memberikan informasi tambahan ?
Apakah ada hal lain yang harus saya tanyakan kepada anda ?
Pertanyaan – pertanyaan tersebut (dan lainnya) akan membantu anda “memecahkan es” dan mengawali komunikasi yang perlu untuk berhasilnya analisis. Tetapi format pertemuan Tanya jawab bukan merupakan pendekatan yang sudah berhasil. Pada dasarnya, sesi Q&A seharusnya digunakan hanya pada pertemuan pertama dan kemudian diganti dengan format pertemuan yang mengkombinasikan elemen – elemen pemecahan masalah, negoisasi, dan spesifikasi. Pendekatan terhadap pertemuan – pertemuan tipe tersebut akan dibahas pada bagian selanjutnya.
2.2 Teknik Spesifikasi Aplikasi yang Terfasilitasi
Pelanggan dan pengembang perangkat lunak, tanpa mereka sadari, sering memiliki mind set “kita dan mereka”. Kedua konstituen tersebut bukannya bekerja sebagai tim, tetapi malah membatasi “daerah kekuasaan” mereka sendiri dan berkomunikasi melalui serangkaian memo, surat resmi, dokumen, dan sesi tanya jawab. Sejarah menunjukkan bahwa pendekatan tersebut tidak bekerja dengan baik. Kesalahpahaman, hilangnya informasi penting, dan hubungan kerja yang berhasil tidak pernah dapat terjalin.
Karena masalah itulah maka sejumlah peneliti independen mengembangkan pendekatan time – oriented untuk mengumpulkan kebutuhan yang di aplikasikan selama masa awal analisis dan spesifikasi. Disebut facilitated application specification techniques (FAST), pendekatan itu mendorong munculnya tim gabungan antara pelanggan dan pengembang yang bekerja yang bekerja bersama untuk mengidentifikasi masalah, mengusulkan elemen pemecahan, menegoisasi pendekatan yang berbeda, dan mengkhususkan rangkaian persyaratan pemecahan awal [ZAH90]. Sekarang FAST digunakan terutama oleh masyarakat system informasi, walau teknik tersebut juga menawarkan potensi untuk komunikasi yang berkembang pada semua jenis aplikasi.
Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing – masing pendekatan menggunakan scenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntunan dasar berikut ini :
Peretemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan.
Aturan main untuk persiapan dan partisipasi dibuat.
Sebuah agenda yang cukup formal diusulkan untuk mencakupkan semua hal penting tetapi tidak terlalu formal agar dapat mengalirkan gagasan bebas.
Seorang fasilisator (dapat dari pelanggan, pengembang, atau orang luar) untuk mengontrol pertemuan.
Sebuah “mekanisme definisi” (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan.
Tujuannya adalah untuk mengidentifikasi masalah, mengusulkan elemen pemecahan, menegoisasikan pendekatan yang berbeda, dan mengkhususkan rangkaian persyaratan pemecahan awal dalam suatu atmofsir yang kondusif terhadap pencapaian tujuan.
Untuk memahami secara lebih baik terhadap aliran kejadian pada saat mereka bertemu dalam pertemuan FAST tertentu, disajikan scenario pendek yang menjadi garis besar bagi urutan kejadian yang mengarrah kepada pertemuan, yang terjadi selama pertemuan, dan mengikuti perttemuan tersebut.
Pertemuan awal antara pengembang dan pelanggan (subbab 11.2.1) terjadi dan pertanyaan dan jawaban dasar akan membantu untuk membangun ruang lingkup masalah dan persepsi keseluruhan dari suatu pemecahan. Sebelum pertemuan awal tersebut, pengembang dan pelanggan menulis “permintaan produk” sebanyak satu atau dua halaman. Tempat pertemuan, waktu dan tanggal untuk FAST ditentukan, fasilitator dipilih. Perwakilan baik dari organisasi pengembang maupun organisasi pelanggan di undang untuk dating. Permintaan produk di edarkan ke semua undangan sebelum tanggal pertemuan.
Sambil mengkaji permintaan sebelum dimulainya pertemuan tersebut, masing – masing peserta FAST diminta untuk membuat daftar objek yang merupakan bagian dari lingkungan yang mengelilingi system, objek lain yang dihasilkan oleh system, dan objek yang dihasilkan oleh system untuk melakukan fungsi – fungsinya. Sebagai tambahan, masing – masing peserta diminta membuat daftar yang lain mengenai pelayanan (proses dan fungsi) yang memanipulasi atau berinteraksi dengan objek. Akhirnya, daftar mengenai batasan (misalnya, biaya ukuran, berat) dan criteria kerja (misalnya, kecepatan, akurasi) juga dikembangkan. Para peserta diberitahu bahwa daftar tersebut tidak perlu sempurna, tetapi diharapkan dapat mencerminkan persepsi masing – masing orang terhadap system yang ada.
Sebagai contoh, diasumsikan bahwa tim FAST yang bekerja untuk perusahaan produk konsumen telah memberikan deskripsi produk sebagai berikut :
Penelitian kami menunjukkan bahwa pasar untuk system keamanan rumah berkembang pada laju 40 persen per tahun. Kami ignin memasuki pasar tersebut dengan membangun sebuah system keamanan rumah berbasis mikroprosesor yang akan melindungi dari dan atau mengenali berbagai situasi yang tidak di inginkan, sperti pemasukan illegal, api, banjir, dan lain sebagainya. Produk tersebut secara tentative disebut Safe Home dan akan menggunakan sensor sesuai untuk mendeteksi setiap keadaan, dapat deprogram oleh pemilik rumah, dan akan secara otomatis menelpon sebuah agen pemonitor jika berhasil mendeteksi suatu keadaan.
Pada dasarnya, lebih banyak lagi informasi yang akan diberikan pada tahap ini. Akan tetapi, sekalipun ada informasi tambahan, ambiguitas akan tetap ada, penghilangan tetap saja aka nada, dan kesalahan (error) tetap akan terjadi. Untuk saat ini, deskripsi produk tersebut cukup memadai.
Tim FAST terdiri dari perwakilan dari bagian pemasaran, rekayasa perangkat lunak, rekayasa perangkat keras, dan pemanufakturan. Seorang fasilitator dari luar akan digunakan.
Masing – masing person pada tim FAST (Gambar 11.2) mengembangkan daftar tersebut. Objek yang digambarkan untuk Safe Home dapat meliputi detector asap, sensor pintu dan jendela, detector gerakan, sebuah alarm, sebuah kejadian (sebuah sensor yang telah diaktivasi), sebuah panel control, display, nomor telepon, panggilan telepon, dan sebagainya. Daftar layanan dapat meliputi setting alarm, pemonitoran sensor, pemencetan nomor telepon, pemograman control panel, dan pembacaan display (perhatikan bahwa layanan bertindak menurut objek). Dengan cara yang sama, masing – masing undangan FAST akan mengembangkan daftar batasan (misalnya, system harus memiliki biaya pembuatan kurang dari $200, harus user friendly, dan harus berinterface langsung dengan sambungan telepon standar) serta criteria kinerja (misalnya, sebuah kejadian sensor harus dikenali dalam waktu satu detik; skema prioritas kejadian harus di implementasikan).
Pada saat pertemuan dimulai, topic pertama diskusi adalah kebutuhan akan justifikasi untuk produk baru – setiap orang harus setuju bahwa pengembangan produk (atau akuisisi) dijustifikasi. Sekali persetujuan dibuat, masing – masing partisipan menyajikan daftar mereka yang akan digunakan untuk diskusi. Daftar tersebut dapat ditempel di dinding ruangan dengan menggunakan sembarang kertas yang besar, atau dengan kertas lainnya, atau ditulis pada papan. Idealnya, masing – masing entri daftar harus dapat dimanipulasi secara terpisah sehingga daftar tersebut dapat digabungkan, dihapus, dan dapat ditambah. Pada tahap ini kritik dan debat tidak diperbolehkan.
Setelah daftar individual disajikan dalam satu area topic, maka kelompok kemudian membuat daftar gabungan. Daftar gabungan akan mengurangu entri yang acak dan menambahkan gagasan baru yang muncul selama presentasi, tetapi tidak akan menghapus apapun. Setelah daftar gabungan untuk semua topic dari semua area dibuat, diskusi – dipimpin oleh fasilitator. Daftar gabungan tersebut kemudian dipersingkat, diperpanjang, atau dirumuskan lagi hingga dapat secara tepat mencerminkan produk / system yang akan dikembangkan. Sasaran akan mengembangkan daftar konsesus pada setiap area topic (objek, pelayanan, batasan, dan kinerja). Daftar tersebut kemudian dikesampingkan pada kegiatan selanjutnya.
Begitu daftar consensus telah dilengkapi, tim tersebut terbagi ke dalam subtim yang lebih kecil; masing – masing bekerja untuk mengembangkan sebuah spesifikasi-mini untuk satu entri atau lebih pada setiap daftar. Spesifikasi-mini adalah suatu tambahan dari kata atau frase yang dimasukkan pada daftar. Misalnya, Spesifikasi-mini untuk control panel objek Safe Home dapat berupa :
§ Dipasang di dinding,
§ Ukurannya kira – kira 9×5 inci,
§ Berisi 12 papan ketik dan kunci khusus,
§ Berisi display LCD dari bentuk yang diperlihatkan pada sket [tidak ada disini],
§ Semua interaksi pelanggan terjadi melalui kunci yang digunakan untuk mengaktifkan dan mematikan system,
§ Perangkat lunak untuk memberikan panduan interaksi, echo, dll yang dihubungkan ke semua sensor.
Masing – masing subtim kemudian menyajikan spesifikasi mininya ke semua undangan FAST untuk di diskusikan. Penambahan, penghapusan, dan penambahan lebih jauh lagi dilakukan. Dalam banyak kasus, pengembangan spesifikasi mini akan membuka objek, pelayanan, batasan, atau persyaratan kinerja baru yang akan ditambahkan ke daftar orisinil. Selama diskusi, tim dapat memunculkan suatu masalah yang tidak dapat dipecahkan selama pertemuan. Daftar masalah dikumpulkan agar gagasan – gagasan tersebut dapat di tindak lanjuti kemudian.
Setelah spesifikasi mini ini dilengkapi, masing – masing undangan FAST membuat daftar kinerja validasi untuk produk / system dan menyajikan adfatar tersebut kepada tim. Daftar konsensus mengenai criteria validasi kemudian dibuat. Akhirnya, satu partisipan atau lebih (atau orang luar) diberi tugas untuk menulis draft spesifikasi lengkap dengan menggunakan semua input dari pertemuan FAST.
FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju yang konkrit ke arah pengembangan spesifikasi.
2.3 Penyebaran Fungsi Kualitas
Penyebaran fungsi kualitas / Quality Function Deployment (QFD) adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak. Pertama kali dikembangkan di Jepang dan pertama kali digunakan di Kobe Shipyar of Mitsubishi Heavy Industries, Ltd. Pada awal tahun 1970-an, QFD “berkonsentrasi pada pemaksimalan kepuasan pelanggan” [ZUL92]. Untuk melakukannya, QFD menekankan pemahaman mengenai apa yang berharga bagi pelanggan dan kemudian menyebarkannya ke seluruh proses rekayasa.
QFD mengidentifikasi tiga tipe persyaratan [ZUL92] :
Persyaratan Normal. Sasaran dan tujuan dinyatakan bagi sebuah produk atau system selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas. Contoh persyaratan normal adalah tipe tampilan grafis yang diminta, fungsi system spesifik, dan tingkat kinerja yang didefinisikan.
Persyaratan yang diharapkan. Persyaratan ini implicit terhadap produk atau system dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya akan menyebabkan ketidakpuasan yang mendalam. Contoh persyaratan yang diharapkan adalah mudahnya interaksi manusia dengan mesin, reabilitas dan kebenaran operasional keseluruhan, dan mudahnya instalasi perangkat lunak.
Exciting requirement. Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga.
Dalam kenyataan, QFD melingkupi seluruh proses rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis persyaratan. Kami menyajikan sebuah kajian hanya dari konsep – konsep ini (disesuaikan untuk perangkat lunak computer) pada paragraph selanjutnya.
Dalam pertemuan dengan pelanggan, penyebaran fungsi digunakan untuk menentukan nilai dari masing – masing fungsi yang dibutuhkan bagi system. Penyebaran informasi mengidentifikasi baik objek data maupun event yang harus diambil dan dihasilkan oleh system. Keduanya diikatkan pada fungsi. Terakhir penyebaran tugas menguji tingkah laku system atau produk dalam konteks lingkungannya. Analisis nilai dilakukan untuk menentukan prioritas relative dari persyaratan yang ditentukan selama masing – masing dari tiga penyebaran tersebut.
QFD menggunakan wawancara dan observasi pelanggan, survai, dan pengujian data historis (misalnya, pelaporan masalah) sebagai data kasar bagi aktivitas pengumpulan persyaratan. Data – data itu kemudian diterjemahkan ke dalam table persyaratan – disebut consumer’s voice table – yang dikaji dengan pelanggan. Berbagai diagram, metrics, dan metode evaluasi kemudian digunakan untuk menyarikan persyaratan yang diharapkan dan untuk mendapatkan kebutuhan yang sangad diharapkan.
3. PRINSIP – PRINSIP ANALISIS
Lebih dari dua decade terakhir, para peneliti mengidentifikasi masalah – masalah analisis dan penyebab – penyebabnya, serta mengembangkan berbagai notasi pemodelan dan serangkaian penelitian yang sesuai untuk menanggulanginya. Masing – masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional :
Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
Fungsi – fungsi yang akan dilakukan oleh perangkat lunak harus di definisikan.
Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
Model – model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah – pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan (atau hirarki).
Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Sebagai tambahan untuk prinsip analisis operasional tersebut, Davis [DAV95a] mengusulkan serangkaian5 prinsip panduan untuk “rekayasa persyaratan”:
Mengembangkan prototype yang memungkinkan seorang pemakai memahami bagaimana interaksi manusia dengan mesin terjadi. Karena persepsi mengenai kualitas prangkat lunak sering di dasarkan pada persepsi “friendliness” interface, maka prototyping (dan terasi yang dihasilkan) sangatlah dianjurkan.
Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan langkah pertama dalam membangun kemampuan penelusuran kembali ke pelanggan.
Menggunakan pandangan persyaratan bertingkat. Pembangunan data, fungsional, dan model tingkah laku member perekayasa perangkat lunak tiga pandangan berbeda. Hal ini mengurangi kemungkinan bahwa inkonsistensi akan diketahui.
Memprioritaskan persyaratan. Batas waktu yang tegas dapat menghalangi implementasi setiap persyaratan perangkat lunak. Bila model proses inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan dalam inkremental pertama harus di identifikasi.
Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas selalu ada. Penggunaan kajian teknis formal merupakan satu – satunya cara untuk mengurangi ambiguitas tersebut.
Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.
4. PROTOTYPING PERANGKAT LUNAK
Analisis harus dilakukan tanpa mengabaikan pardigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang di ambil oleh analisis akan bermacam – macam. Dalam situasi yang lain, dilakukan pengumpulan persyaratan (melalui FAST, QFD, atau teknik “cuci otak” yang lain [JOR89], pengaplikasian prinsip analisis, dan penyusunan model perangkat lunak yang akan di bangun yang disebut prototype, untuk penilaian pelanggan dan pengembang.
4.1 Pemilihan Pendekatan Prototyping
Paradigma protyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering disebut throwaway prototyping. Dengan menggunakan pendekatan tsb, prototype melulu sebagai sebuah demonstrasi kasar dari persyaratan. Pendekatan tidak terbatas, yang disebut juga evolutionary prototyping, menggunakan prototype sebagai bagian pertama dari aktivitas analisis yang akan diteruskan kedalam desain dan kontruksi. Prototipe perangkat lunak merupakan evolusi pertama dari system yang diselesaikan.
Secara umum, sembarang aplikasi yang menciptakan tampilan visual yang dinamis, berinteraksi erat dengan pemakai manusia, atau membutuhkan algoritma atau pemrosesan kombinatorial yang harus dikembangkan dalam sebuah gaya evolusioner, adalah calon untuk prototyping
4.2 Metode dan peranti prototyping
Supaya prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan yang di rekomendasi. Untuk melakukan prototyping secara cepat, ada tiga kelas metode dan peranti generic: teknik generasi keempat, komponen perangkat lunak reusable, spesifikasi formal, dan lingkungan prototyping.
Teknik Generasi Keempat (4GT). Teknik generasi keempat meliputi suatu array yang luas dari query database dan bahasa pelaporan, program dan generator aplikasi, serta bahasa nonprocedural. Karena 4GT memungkinkan perekayasa perangkat lunak memunculkan kode yang dapat dieksekusi dengan cepat, maka 4GT ideal untuk prototyping yang cepat.
Komponen Perangkat Lunak Reusable. Pendektan lain ke rapid prototyping adalah dengan memasang, bukan membangun, prototype dengan menggunakan serangkaian komponen perangkat lunak yang ada.Pada setiap kasus, komponen perangkat lunak harus dirancang dengan cara terntentu sehingga memungkinkannya untuk dipakai kembali tanpa harus mempunyai pengetahuan yang mendetail mengenai kerja internalnya. Perlu di catat bahwa sebuah produk perangkat lunak yabg ada dapat digunakan sebagai sebuah prototype bagi produk kompetitif yang “baru dan telah dikembangkan”. Dengan cara tertentu, hal tsb merupakan suatu bentuk dari reusabilitas untuk prototyping perangkat lunak.
Lingkungan Prototyping dan Spesifikasi Formal. Selama dua decade terakhir, sejumlah bahasa spesifikasi formal dan peranti telah dikembangkan sebagai pengganti bagi teknik spesifikasi bahasa natural. Sekarang pengembang bahasa formal itu berada dalam proses pengembangan lingkungan interaktif yang (1) memungkinkan seorang analisis untuk secara interaktif menciptakan spesifikasi system atau perangkat lunak yang berdasarkan pada bahasa, (2) memanggil peranti otomatis yang menerjemahkan spesifikasi berdasarkan bahasa kedalam kode yang dapat di eksekusi, dan (3) memungkinkan pelanggan untuk menggunakan kode prototype yang dapat di eksekusi untuk menyaring persyaratan – persyaratan formal.
Sumber :
https://indrahimessi.wordpress.com/2010/12/21/konsep-dan-prinsip-analisis-rpl/
