Download
1 / 50
500 likes | 712 Views
Chapter 6. PROSES REKAYASA PERSYARATAN. PRODI PENDIDIKAN TEKNIK INFORMATIKA DAN KOMPUTER JURUSAN PENDIDIKAN TEKNIK ELEKTRO FAKULTAS TEKNIK UNIVERSITAS NEGERI MAKASSAR. KELOMPOK 3. 092904006 SYAPUTRI ARTAMI S 092904010 AYU ANGGRIANI H 092904011 RUDI DIAN SYAH 092904030 ZUL FADLY SULTHAN
E N D
Chapter 6 PROSES REKAYASA PERSYARATAN PRODI PENDIDIKAN TEKNIK INFORMATIKA DAN KOMPUTER JURUSAN PENDIDIKAN TEKNIK ELEKTRO FAKULTAS TEKNIK UNIVERSITAS NEGERI MAKASSAR
KELOMPOK 3 092904006 SYAPUTRI ARTAMI S 092904010 AYU ANGGRIANI H 092904011 RUDI DIAN SYAH 092904030 ZUL FADLY SULTHAN 092904035 JUMIATI 092904041 HUSNAENI 092904043 NURHALIMAH
Tujuan • Memehamikegiatan-kegiatanrekayasapersyaratandanhubungan-hubungannya • Mengetahuibeberapateknikelisitasidananalisispersyaratan • Memahamiartipentingvalidasipersyaratandanbagaimanapeninjauanpersyaratandigunakanpada proses ini • Memahamimengapamanajemenpersyaratandiperlukandanbagaimanamanajementersebutmendukungrekayasapersyaratan lain
Pokokpembahasan 6.1. StudiKelayakan 6.2. Elisitasidananalisispersyaratan 6.3. Validasipersyaratan 6.4. Manajemenpersyaratan
Rekayasa persyaratan adalah proses yang melibatkan semua kegiatan yang dibutuhkan untuk membuat dan memelihara dokumen persyaratan sistem. Ada empat kegiatan proses rekayasa persyaratan tingkat tinggi yang generik adalah : Studi kelayakan sistem Elisitasi dan analisis persyaratan Validasi persyaratan Manajemen persyaratan
Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai dengan studi kelayakan. Input bagi studi kelayakan adalah deskripsi garis besar sistem dan bagaimana sistem akan digunakan dalam organisasi. • Hasil studi kelayakan berwujud laporan yang merekomendasikan apakah kegiatan tersebut layak diteruskan dengan rekayasa persyaratan dan proses pengembangan sistem. • Studi kelayakan merupakan studi singkat dan terfokus yang bertujuan untuk menjawab sejumlah pertanyaan berikut : • Apakah sistem memberikan konstribusi bagi tujuan organisasi secara keseluruhan. • Apakah sistem dapat diimplementasi dengan menggunakan teknologi terbaru dan dalam batasan biaya dan jadwal ? • Apakah sistem dapat diintegrasi dengan sistem lain yang sudah ada ?
Setelahstudi kelayakan awal, tahap berikutnya dari proses rekayasa persyaratan adalah elisitasi dan analisis persyaratan. • Pada tahap ini, staf pengembangan perangkat lunak teknis bekerja dengan pelanggan dan end-user sistem untuk mencari domain aplikasi, layanan apa yang harus diberikan sistem, kinerja sistem yang diharapkan, batasan perangkat keras, dan seterusnya. • Elisistasi dan analisis persyaratan dapat melibatkan berbagai macam orang dalam organisasi. • Stakeholder mencakup end-user yang berinteraksi dengan sistem dan orang lain pada organisasi yang akan dipengaruhi oleh sistem tersebut. • Perekayasa yang mengembangkan atau memelihara sistem lain yang berhubungan, manajer bisnis, pakar domain, representatif badan perdagangan, dan seterusnya juga bisa merupakan stakeholder sistem.
Elisitasi dan analisis merupakan proses yang sulit karena sejumlah alasan : • Stakeholder seringkali tidak tahu apa yang mereka inginkan dari sistem komputer kecuali dalam hal-hal yang paling umum. • 2. Stakeholder pada suatu sistem biasanya menyatakan persyaratan dalam pemikiran mereka dan dengan pengetahuan imlisit mengenai pekerjaan mereka. • 3. Beda stakeholder,beda pula persyaratanya, dan mereka mungkin menyatakannya dengan cara yang berbeda pula. • 4. Faktor-faktor politis dapat mempengaruhi persyaratan sistem. • 5. Lingkungan ekonomi dan bisnis di mana analisis dilakukan bersifat dinamis. Lingkungan ini tentu berubah pada saat proses analisis. Dengan demikian, arti penting dari persyaratan tentu bisa berubah. Persyaratan baru munngkin muncul dari stakeholder yang baru yang pada awalnya tidak dihubungi.
Kegiatan-kegiatan proses tersebut adalah: • Pemahaman domain : analisis harus mengembangkan pemahaman mereka mengenai domain aplikasi. • 2. Pengumpulan persyaratan : ini merupakan proses interaksi dengan stakeholder pada sistem untuk mendapatkan persyaratan mereka. • 3. Klasifikasi : kegiatan ini mengambil kumpulan persyaratan yang tidak terstruktur dan mengaturnya menjadi kelompok-kelompok yang bertalian secara logis. • 4. Resolusi konflik : kegiatan ini berkenaan dengan menemukan dan menyelesaikan konflik jika banyak stakeholder yang terlibat,dan terjadi konflik persyaratan. • 5. Prioritasi : tahap ini mencakup interaksi dengan stakeholder untuk menemukan persyaratan yang paling penting,karena dalam beberapa hal akan lebih penting dari yang lain. • 6. Pemeriksaan persyaratan : tahap ini, persyaratan diperiksa untuk mengetahui apakah sudah lengkap, konsisten, dan mengikuti apa yang benar-benar diinginkan stakeholder dari sistem tersebut.
6.2.1. Elisitasi Berorientasi sudut pandang • Untuk sistem berukuran menengah atau besar, biasanya terdapat beberapa end-user dengan tipe berbeda. Banyak stakeholder yang memiliki kepentingan terhadap persyaratan sistem. Berikut kami berikan contoh, stakeholder sistem untuk sistem ATM bank mencakup : • Nasabah bank pada saat itu yang menerima jasa dari sistem; • Representatif dari bank lain yang memiliki perjanjian timbal balik yang memungkinkan menggunakan ATM bersama; • Manajer cabang-cabang bank yang mendapatkan informasi manajemen dari sistem; • Staf counter pada cabang-cabang bank yang terlibat dalam pengoperasian sistem dari hari ke hari, menangani keluhan nasabah, dll;
Administrator database yang bertanggung jawab terhadap integrasi sistem dengan database nasabah bank; • Manajer keamanan bank yang harus menjamin bahwa sistem tidak akan menimbulkan kekacauan keamanan dalam bentuk apapun; • Departemen pemasaran bank yang mungkin tertarik untuk menggunakan sistem sebagai cara untuk pemasaran bank; • Perekayasa pemeliharaan perangkat keras dan lunak yang bertanggung jawab untuk memelihara sistem dan meng-upgrade perangkat keras dan lunak.
Setiap metode memiliki gagasan yang berbeda mengenai apa yang dimaksud dengan “sudut pandang”. Suatu sudut pandang dapat dianggap sebagai : • Sumber atau tempat masuknya data. • Kerangka kerja representasi. • Penerima layanan. • Keuntungan jenis sudut pandang ini adalah: • Sudut pandang bersifat eksternal terhadap sistem sehingga merupakan cara yang natural untuk membentuk struktur proses elisitasi persyaratan. • Relatif mudah untuk memutuskan apakah suatu sudut pandang bersifat valid. • Sudut pandang dan layanan merupakan cara yang berguna dalam penstrukturan persyaratan non-fungsional. Setiap layanan bisa memiliki persyaratan non-fungsional yang berhubungan.
Metode VORD ( viewpoint oriented requirments definition/definisi persyaratan berorientasi sudut pandang) telah dirancang sebagai kerangka kerja berorientasi layanan untuk elisitasi dan analisis persyaratan . TahapUtamametode VORD: • Identifikasi sudut, yang mencakup pencarian sudut pandang yang menerima layanan sistem dan pengidentifikasian layanan-layanan khusus yang diberikan bagi setiap sudut pandang. • Penstrukturan sudut pandang, yang mencakup pengelompokkan sudut pandang yang berhubungan menjadi suatu hierarki. Layanan-layanan yang umum diberikan pada tingkatan yang lebih tinggi pada hierarki dan diwarisi oleh sudut pandang tingkat rendah. • Dokumentasi sudut pandang, yang mencakup penyempurnaan deskripsi sudut pandang dan layanan yang teridentifikasi. • Pemetaan sistem sudut pandang, yang mencakup pengidentifikasian objek pada desain berorientasi objek dengan menggunakan informasi layanan yang dicakup dalam sudut pandang.
6.2.2 SKENARIO • Skenario adalah deskripsi sesi interaksi contoh. Skenario bisa sangat berguna untuk menambahkan detail garis besar deskripsi persyaratan. • Sknario dimulai dengan garis besar interaksi dan pada saat elisitasi, detil ditambahkan untuk menyusun deskripsi yang lengkap mengenai interaksi tersebut. • Skenario yang umum dapat mencakup : • Deskripsi status sistem pada awal skenario; • Deskripsi aliran event yang normal pada skenario; • Deskripsi mengenai apa yang bisa salah dan bagaimana penanganannya; • Informasi mengenai kegiatan lain yang bisa berlangsung pada saat yang sama; • Deskripsi status sistem setelah berakhirnya skenario.
Skenario Event • Skenario event digunakan paa VORD untuk mendokumentasikan prilaku sistem jika dihadapkan pada event-event tertentu. • Aturan diagramatik yang dipakai pada skenario event adalah : • Data yang diberikan dari sudut pandang atau diberikan ke sudut pandang digambarkan dengan elips. • Informasi kontrol masuk dan keluar ada di atas setiap kotak. • Data keluar dari kanan setiap kotak. Jika tidak tertutup, ini berarti bahwa data tersebut bersifat internal bagi sistem. • Eksepsi digambarkan di dasar kotak. Jika ada beberapa eksepsi yang mungkin, seluruhnya dimasukkan dalam satu kotak. • Nama event berikutnya yang diharapkan setelah skenario selesai ditunjukkan pada kotak yang diarsir.
Pada gambar diatas menunjukkan bahwa ketika kartu dimasukkan, diminta nomor identifikasi pribadi (PIN) nasabah. Nasabah memasukkan kartunya beserta PIN. Jika kartu tersebut merupakan kartu valid yang dapat diproses oleh mesin, kontrol berlanjut ketahap berikutnya. Padatahappertamaadatigaperkecualian (eksepsi) yang mungkin: Waktuhabis Kartu invalid Kartucurian
USE-CASE Use-case adalah teknik berdasarkan skenario untuk elisitasi persyaratan. Use case sekarang telah menjadi fitur dasr notasi UML untuk mendeskripsikan model sistem berorientasi objek Peraga 6.11 Use-Case peminjaman Gambar diatas mengilustrasikan hal-hal penting pada notasi use-case.aktor pada proses ini direpresentasikan sebagai gambar orang dan setiap kelas interqaksi direpresentasikan sebagai elips nama.
6.2.3.ETNOGRAFI • Etnografi adalah teknik observasi yang dapat dipakai untuk memahami persyaratan sosial dan organisasional. Nilai etnografi membantu menemukan persyaratan sistem yang implisit yang merefleksikan proses sebenarnya, bukan proses formal, dimana orang orang terlibat. • Etnografi terutama efektif untuk menemukan 2 tipe persyaratan: • Persyaratan yang berasal dari cara orang bekerja yang sebenarnya dan bukan cara yang ditentukan oleh definisi proses. • Persyaratan yang berasal dari kerja sama dan kesadaran akan kegiatan orang lain.
Peraga 6.14 Etnografidanpembuatanprototipeuntukanalisispersyaratan
Validasi persyaratan berkenaan dengan pengidentifikasian bahwa persyaratan benar-benar mendefinisikan sistem yang diinginkan pelanggan. • Validasi persyaratan penting karena error pada dokumen persyaratan dapat menimbulkan biaya pengerjaan ulang yang ekstensif jika ditemukan pada saat pengembangan atau setelah sistem dipakai. • Biaya melakukan perubahan sistem, yang merupakan akibat dari masalah persyaratan, lebih besar dari perbaikan desain atau kesalahan pengkodean.
Pada saat proses validasi persyaratan tipe pemeriksaan yang berbeda harus diterapkan pada persyaratan-persyaratan di dokumen persyaratan. Pemeriksaan ini meliputi : • Pemeriksaan validitas. • Pemeriksaan konsistensi. • Pemeriksaan kelengkapan. • Pemeriksaan realisme. • Kemampuan dapat diverifikasi.
Ada sejumlahteknikvalidasipersyaratan yang dapatdigunakansecarabersamaanatauberdirisendiri: Peninjauanpersyaratan Pembuatanprototipe Pembuatan test-case Analisiskonsistensiterotomasi
6.3.1. PENINJAUAN PERSYARATAN • Peninjauan persyaratan biasanya merupakan proses manual yang melibatkan banyak pembaca, baik dari staf pelanggan maupun kontraktor yang memeriksa dokumen persyaratan untuk menemukan kejanggalan dan hal-hal yang terlewatkan. • Peninjauan persyaratan dapat bersifat informal atau formal. Peninjauan informal hanya melibatkan kontraktor yang membahas persyaratan dengan sebanyak mungkin stakeholder sistem. Sedangkan dalam peninjauan formal, tim pengembang harus “menuntun” pelanggan melalui persyaratan sistem, menjelaskan akibat dari setiap persyaratan.
Manajemen persyaratan adalah proses pemahaman dan pengendalian perubahan pada persyaratan sistem. • Proses manajemen persyaratan dilakukan bersama dengan proses rekayasa persyaratan yang lainnya. • Perencanaan dimulai pada saat yang sama dengan elisitasi persyaratan awal dan manajemen persyaratan aktif harus dimulai segera setelah versi draft dokumen persyaratan tersedia.
6.4.1 PERSYARATAN YANG BERTAHAN LAMA DAN BERUBAH-UBAH • Dari sudut pandang evolusi, persyaratan terbagi menjadi dua kelas: • Persyaratan bertahan . ini merupakan persyaratan yang relatif stabil, yang berasal dari kegiatan inti organisasi dan berhubungan langsung dengan domain sistem. • Persyaratan yang berubah-ubah. Ini merupakan persyaratan yang mungkin berubah pada saat pengembangan sistem, atau setelah sistem dipakai.
6.4.2. PERENCANAAN MANAJEMEN PERSYARATAN • Perencanaan merupakan tahap pertama yang penting pada pada proses manajemen persyaratan. Manajemen persyaratan sangat mahal dan untuk setiap proyek, tahap perencanaan menetapkan tingkat rincian manajemen persyaratan yang diperlukan. • Pada tahap ini, kita harus membuat keputusan mengenai : • Identifikasi persyaratan. • Proses manajemen perubahan. • Kebijakan agar dapat ditelusuri. • Dukungan alat bantu CASE ( CASE tool ).
Ada banyak hubungan antara persyaratan dan persyaratan lainnya dan antara persyaratan dan desain sistem. • Ada tiga tipe informasi kemampuan penelusuran yang dapat dipertahankan: • Informasi kemampuan penelusuran sumber. • Informasi penelusuran persyaratan. • Informasi ke-mamputelusuran-an (traceability) desain.
Manajemenpersyaratanmembutuhkanpendukungterotomasidanalat bantu CASE (CASE tool) yang dipakaiharusdipilihpadasaatfaseperencanaan . Alatbantu (tool) dibutuhkanuntuk: Penyimpananpersyaratan Manajemenperubahan Manajemenpenelusuran
6.4.3. MANAJEMEN PERUBAHAN PERSYARATAN • Manajemen perubahan persyaratan harus diterapkan pada semua perubahan yang diusulkan untuk perubahan. • Ada tiga tahapan utama untuk proses manajemen perubahan : • Analisis masalah dan spesifikasi perubahan. • Analisis dan perhitungan biaya perubahan. • Implementasi perubahan.
“semogabermanfaat” TerimaKasih
