Tugas Rekayasa Perangkat Lunak
Disusun Oleh : M Ikhsan Ariya Girinata
41813120052
Dosen : Wachyu Hari Haji, S.Kom, MM
FAKULTAS ILMU KOMPUTER JURUSAN SISTEM INFORMASI Mata Kuliah : REKAYASA PERANGKAT LUNAK Jakarta 2015
Analisis kebutuhan perangkat lunak : Analisis kebutuhan perangkat lunak (software requirements analysis) merupakan aktivitas awal dari siklus hidup pengembangan perangkat lunak. Untuk proyek-proyek perangkat lunak yang besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information engineering dan software project planning. Tahap analisis adalah tahapan pengumpulan kebutuhan-kebutuhan dari semua elemen system perangkat lunak yang akan di bangun. Pada tahap ini dibentuk spesifikasi kebutuhan perangkat lunak, fungsi perangkat lunak yang dibutuhkan, performansi (unjuk kerja) sistem perangkat lunak, penjadwalan proyek, identifikasi sumber daya (manusia , perangkat keras dan perangkat lunak yang dibutuhkan) dan taksiran biaya pengembangan perangkat lunak. Kegunaan analisis adalah untuk memodelkan permasalahan dunia nyata agar dapat dimengerti. Permasalahan dunia nyata harus dimengerti dan dipelajari supaya spesifikasi kebutuhan perangkat lunak dapat diungkapkan. Tujuan aktivitas ini adalah untuk mengetahui ruang lingkup produk (product space) dan pemakai yang akan menggunakannya. Analisis yang baik akan mengungkapkan hal-hal yang penting dari permasalahan, dan mengabaikan yang tidak penting. Setiap metode analisis mempunyai pandangan yang berbeda. Tetapi pada dasarnya semua metode analisis memiliki prinsip analisis yang sama, yaitu : 1. Menggambarkan domain informasi masalah 2. Mendefinisikan fungsi perangkat lunak 3. Menghasilkan model yang menggambarkan informasi, fungsi dan kelakuan yang dibagi secara rinci pada sebuah model lapisan (hirarki) 4. Informasi pokok pada tahap analisis memudahkan tahap implementasi yang lebih rinci. Tujuan tahap analisis adalah : 1. Menjabarkan kebutuhan pemakai 2. Meletakkan dasar-dasar untuk tahap perancangan perangkat lunak
3. Mendefinisikan semua kebutuhan pemakai sesuai dengan lingkup kontrak yang disepakati kedua belah pihak (pengembang dan pengguna). Apa yang Disebut Kebutuhan (Requirement) Menurut arti kamus, kebutuhan adalah sesuatu yang diminta, sesuatu yang dibutuhkan. Sedangkan menurut IEEE (The Institute of Electrical and Electronics Engineers) kebutuhan adalah : o Kondisi atau kemampuan yang diperlukan pemakai untuk menyelesaikan suatu persoalan, atau untuk mencapai sebuah objek. o Kondisi atau kemampuan yang harus dipenuhi oleh sistem, dalam arti memenuhi kontrak, standar, spesifikasi atau dokumen formal lain yang diinginkan. Tahap kebutuhan akan perangkat lunak dimulai dengan : 1. Dikenalinya adanya sebuah permasalahan yang membutuhkan sebuah penyelesaian. Identifikasi sebuah permasalahan mungkin dapat dilakukan dengan berorientasi pada aplikasi, berorientasi pada bisnis, atau berorientasi pada kenaikan produktivitas (product improvement oriented). 2. Munculnya ide untuk membuat sebuah perangkat lunak baru (sebagai sebuah kemajuan). Ada dua jenis kebutuhan : 1. Behavioral a. Apa yang dilakukan oleh sistem (input dan output dari dan ke sistem). b. Hubungan informasi antara input dan output sehingga menghasilkan sebuah fungsi transformasi. 2. Non-behavioral Mendefinisikan atribut sistem yang terkait untuk membentuk pekerjaan tersebut. Termasuk deskripsi lengkap tentang efisiensi, keamanan (security), rehability maintenability (bagaimana perawatan untuk sistem), dan portability (bisa dipindahkan dari satu perangkat keras ke perangkat keras lainnya).
Mencari kesalahan diakhir siklus hidup pengembangan perangkat lunak ternyata akan banyak mengeluarkan uang. Jika dapat dideteksi, dilakukan perbaikan pada setiap tahap proses. Jika tidak dapat dideteksi, kesalahan baru kelihatan setelah produk selesai dibuat. Mengapa Kebutuhan Penting ?
Perhatikan gambar dampak kumulatif berikut ini :
Teknik komunikasi dan prinsip-prinsip analisis : Teknik Komunikasi :
Komunikasi antara analis dan customer
Teknik FAST (Facilitated Application Specification Techniques) o Tujuan : mengidentifikasi masalah, mengusulkan elemen pemecahan, negosiasi pendekatan yang berbeda, dan mengkhususkan persyaratan pemecahan awal untuk mencapi tujuan o Tim gabungan bisa tdd : Fasilitator Tim dari Customer Tim pengembang Perekam
Beberapa hal yang biasa ditanyakan :
Pemahaman dasar dari masalah
Orang yang membutuhkan solusi
Keadaan dari solusi yang diinginkan
Efektivitas komunikasi dan kolaborasi awal antara konsumen dengan developer
Berikut ini ada beberapa hal yang perlu diperhatikan :
Perolehan o memperoleh kebutuhan dari semua stakeholder Penguraian o membuat model analisis yang mampu melakukan identifikasi kebutuhan data, fungsi dan perilaku Negosiasi o menyepakati sistem penyajian yang realistis bagi konsumen dan developer Spesifikasi o Meliputi : Dokumen tertulis Sekelompok model Matematika formal Sekumpulan skenario user (use-cases) Prototipe Validasi o Hal-hal yang divalidasi adalah : Kesalahan isi atau interpretasi Area dimana klarifikasi dibutuhkan Informasi yang hilang Inkonsistensi (masalah utama ketika produk atau sistem besar direkayasa) Kebutuhan yang konflik atau tidak realistis. Manajemen Kebutuhan
Cara untuk memperoleh kebutuhan :
Pertemuan diadakan dan dihadiri baik oleh software engineer maupun konsumen
Aturan persiapan dan partisipasi dibuat Agenda ditawarkan Seorang fasilitator (bisa konsumen, developer atau orang luar) mengendalikan pertemuan Mekanisme definisi digunakan (bisa berupa kertas kerja, grafik, bulletin board elektronik, forum virtual dsb
Tujuannya hal-hal diatas adalah untuk :
Menemukan permasalahan Mengajukan elemen-elemen solusi Negosiasi pendekatan yang berbeda Menentukan sekelompok kebutuhan solusi awal
Prinsip-prinsip analisis : Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:
Domain informasi dari suatu masalah harus direpresentasikan dan dipahami. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
Model-model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecahpecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan. Proses analisis harus bergerak dari informasi dasar ke detail implementasi. Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu: Model Fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output.
Pembuatan model prototype perangkat lunak : a. Prototyping Perangkat Analisis harus dilakukan tanpa mengabaikan paradigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang diambil oleh analisis akan bermacam- macam. Dalam banyak kasus sangat mungkin untuk mengaplikasikan prinsip operasional dan menarik sebuah model perangkat lunak yang melaluinya sebuah desain dapat dikembangkan, pengaplikasian prinsip analisis dan penyusunan model perangkat lunak yang akan dibangun yang disebut prototype untuk penilaian pelanggan danpengembang.
b. Pemilihan prototyping Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas sering disebut : throw away prototyping. Dengan menggunakn pendekatan tersebut, prototyping sebagai sebuah demonstrasi kasar dari sebuah persyaratan.Kemudian prototype dikesampingkan dan perangkat lunak direkayasa dengan menggunakan suatu paradigma yang berbeda.Pendekatan tidak terabatas sering disebut evolusionary prototyping,menggunakan prototyping sebagai bagian utama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi. c. Metode dan Peranti Prototyping Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dengan dapat menilai hasil dan perubahan yang di rekomendasikan. Untuk melakukan prototyping dengan tepat ad tiga kelas metode dan peranti generik, teknik generasi keempat komponen perangkat lunak reusable, spesifikasi normal,dan lingkungan prototyping. Dalam proses analisis proses pendekatan dilakukan, dan salah satunya adalah prototyping. Prototyping adalah sebuah proses pengumpulan persyaratan, pengaplikasian prinsip analisis, dan penyusunan model perangkat lunak yang akan dibangun untuk penilaian dan pengembangan. Akhirnya
ada lingkungan yang membutuhkan konstruksi prototipe pada awal analisis, karena model adalah satusatunya alat dimana persyaratan dapat ditarik secara efektif. Model tersebut kemudian dikembangkan dalam perangkat lunak produksi. Ada empat model prototype: 1. Prototype kertas, menggambarkan system dengan menggunakan media kertas. Prototype kertas tidak bisa diuji coba dan diimplementasikan. 2. Prototype berbasis PC, memanfaatkan program aplikasi untuk menunjukkan interaksi manusia dan komputer. 3. Prototype kerja, merupakan implementasi sebagian fungsi system yang ingin dilihat unjuk kerjanya, dan diwujudkan dalam sebuah program. 4. Prototype program, program benar-benar dibuat dan dapat berfungsi dengan baik. Selain itu, program juga terus menerus ditambah dan dilengkapi.
Paradigma prototyping dapat terbatas atau tidak terbatas. Pendekatan terbatas disebut throaway prototyping. Dengan menggunakan pendekatan ini, prototipe sebagai sebuah demonstrasi dari sebuah persyaratan. Sedangkan pendekatan tidak terbatas, yang disebut juga evolutionary prototyping., menggunakan prototipe sebagai bagian pertama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi. Sebelum pendekatan terbatas atau tidak terbatas dilaksanakan perlu dilakukan apakah sistem yang akan dibangun dapat menerima protoyping atau tidak. Sejumlah faktor perlu diperhatikan, diantaranya: area aplikasi, kompleksitas aplikasi, karakteristik pelanggan, dan karakteristik proyek. Beberapa kelebihan/manfaat yang bisa diambil bila kita menggunakan prototyping antara lain : 1. Adanya komunikasi yang intensif antara pengembang dan user 2. Membantu dalam analisis, karena kebutuhan user telah dipahami dengan baik oleh pengembang sehingga dapat meminimalkan salah persepsi antara kedua pihak. 3. Peran user meningkat, karena user dapat melakukan evaluasi dan masukan baru setiap saat. 4. Pengembangan lebih cepat, karena program bisa langsung dibuat dan user dapat melihat setiap tahap pembuatan program. 5. Mudah dalam implementasinya, karena user sudah sejak awal terlibat sehingga sudah akrab dan tidak merasa asing terhadap program.
Sedangkan kelemahan memakai prototype adalah : 1. User sibuk, karena user dan pengembang harus sama-sama memiliki komitmen untuk sering bertemu dan membahas kebutuhannya 2. User ingin program segera selesai sehingga pengembang sering mengabaikan dokumentasi 3. User berharap terlalu banyak, seringnya evaluasi dan komunikasi membuat user sering berubah fikiran dan tidak pasti akan kebutuhannya. Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.
Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suatu perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas. Seperti produk, proses juga memiliki atribut dan karakteristik seperti :
Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.
Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
Reliability, apakah proses didesain sedimikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.
Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses. Pemodelan dalam rekayasa perangkat lunak merupakan suatu hal yang dilakukan ditahap awal dan akan mempengaruhi pekerjaan-pekerjaan selanjutnya dalam rekayasa perangkat lunak tersebut.
Spesifikasi
Daftar Pustaka : http://blog.uin-malang.ac.id/ivageje/2013/10/18/konsep-dan-prinsip-analisis/ https://www.academia.edu/7953408/PROTOTYPING_DAN_PEMODELAN_PERANGKA T_LUNAK