Tugas Rekayasa Perangkat Lunak

dokumen-dokumen yang mirip
Ratna Wardani. Department of Electronic Engineering Yogyakarta State University

ANALISIS KEBUTUHAN PERANGKAT LUNAK

Dibuat Oleh : 1. Andrey ( )

Pemahaman (cont.) Analisis merupakan sebuah : Penemuan Perbaikan Pemodelan Spesifikasi (baru) Tim RPL 1

Teknik Informatika S1

MAKALAH REKAYASA PERANGKAT LUNAK ( PEMODELAN DATA )

12. KONSEP DAN PRINSIP ANALISIS

MAKALAH ANALISIS KEBUTUHAN PERANGKAT LUNAK. NAMA : RANI JUITA NIM : DOSEN : WACHYU HARI HAJI. S.Kom.MM

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

Kebutuhan Perangkat Lunak Dalam Pengembangan Sistem Informasi. Muhamad Alif, FT UTM 2012

Ratna Wardani. Department of Electronic Engineering Yogyakarta State University

IF2261 Software Analysis Part I

Nama : Rendi Setiawan Nim :

PENGEMBANGAN PERANGKAT LUNAK

Pendekatan-Pendekatan Pengembangan Sistem Hanif Al Fatta M.kom

Tugas Rekayasa Perangkat Lunak

SIKLUS REKAYASA PERANGKAT LUNAK (SDLC)

Judul. Deskripsi dan Spesifikasi Kebutuhan Sistem Berbasis Komputer. Oleh: Tim Dit. TIK UPI

REKAYASA PERANGKAT LUNAK

Jenis Metode Pengembangan Perangkat Lunak

REKAYASA PERANGKAT LUNAK

Pemodelan Industri Perangkat Lunak

Pendefinisian kebutuhan merupakan aktivitas yang sangat penting, karena sangat mempengaruhi sukses atau gagalnya pelaksanaan pengembangan perangkat

STMIK AMIKOM YOGYAKARTA

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

Hanif Fakhrurroja, MT

III. METODE KONVENS IONAL 11. REKAYASA SISTEM BERBASIS KOMPUTER

Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

Hanif Fakhrurroja, MT

BAB 1 PENDAHULUAN Latar Belakang

KAJIAN DAN SPESIFIKASI PERANGKAT LUNAK

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

Pertemuan 3 Metodologi Pengembangan Sistem Informasi

ANALISA & PERANCANGAN SISTEM

5. Aktivitas generic dalam semua proses perangkat lunak antara lain adalah : a. Spesifikasi dan pengembangan b. Validasi dan evolusi c.

Rekayasa Perangkat Lunak (Software Engineering)

Rekayasa Perangkat Lunak

Metodologi pengembangan sistem METODOLOGI PENGEMBANGAN SISTEM INFORMASI DIAN PALUPI RINI, M.KOM 1

Pemodelan Berorientasi Objek

BAB I PENDAHULUAN. Semakin berkembangnya teknologi saat ini, memacu Perusahaan PT. DASS

BAB III OBJEK DAN METODE PENELITIAN. untuk mendapatkan data-data yang berkaitan dengan objek penelitian tersebut.

1. Konsep dan Prinsip Analisa

STMIK AMIKOM YOGYAKARTA

PROSES DESAIN. 1. Metodologi Pengembangan Sistem

Modul Praktikum Analisis dan Perancangan Sistem Halaman 1 dari 58

Bab 4 Metodologi Pengembagan Sistem(Perangkat Lunak)

Rekayasa Perangkat Lunak

Metode-Metode Pengembangan Desain Aplikasi

BAB II LANDASAN TEORI

BAB II LANDASAN TEORI. pembelian dilakukan dengan mengubah bentuk barang. 2003). Menurut Soemarso S.R (1994) kegiatan pembelian dalam perusahaan

BAB I PENDAHULUAN. untuk bergerak secara dinamis untuk dapat memenangkan persaingan dan

BAB III ANALISIS DAN PERANCANGAN. struktur organisasi dan deskripsi pekerjaan dari FUTSAL99 Bandung.

Tujuan Perkuliahan. PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Agenda. Definisi Software (Perangkat Lunak) Lunak) 23/09/2010

Tugas Rekayasa Perangkat Lunak

ANALISIS KEBUTUHAN PERANGKAT LUNAK

Siklus, Metode dan Teknik Pengembangan Sistem

MAKALAH REKAYASA PERANGKAT LUNAK ( PEMODELAN PERANGKAT LUNAK DALAM ANALISIS )

SPESIFIKASI PERANGKAT LUNAK

COMPUTER SYSTEM ENGINEERING

3.1 PENGERTIAN PROTOTYPING MODEL

MODEL PENGEMBANGAN SISTEM

SISTEM INFORMASI AKUNTANSI

PERENCANAAN PROYEK PERANGKAT LUNAK

BAB III KONSEP DAN PRINSIP ANALISIS

Tugas Rekayasa Perangkat Lunak

BAB III OBJEK DAN METODE PENELITIAN. Dalam analisis sistem ini akan diuraikan sejarah singkat dari Apotek 55 yang

BAB III LANDASAN TEORI

MAKALAH DESAIN PERANGKAT LUNAK. NAMA : RANI JUITA NIM : DOSEN : WACHYU HARI HAJI. S.Kom.MM

BAB III METODE PENELITIAN. penelitian. Perancangan tingkat usability. Analisis. Identifikasi Pola Interaksi

chapter 7 Integrating quality activities in the project life cycle Empat model proses pengembangan perangkat lunak akan dibahas dalam bagian ini:

Pertemuan 3. Manajemen Proyek Perangkat Lunak. Proses Dalam Manajemen PL

GARIS-GARIS BESAR PROGRAM PENGAJARAN (GBPP)

BAB I PENDAHULUAN. hal proses pengolahan data, baik itu data siswa, guru, administrasi sekolah maupun data


ANALISIS, DESAIN DAN IMPLEMENTASI SISTEM INFORMASI

BAB 1 PENDAHULUAN Latar Belakang

Untuk menggambarkan kegiatan rekayasa persyaratan pokok dan hubungan mereka. Untuk memperkenalkan teknik untuk elisitasi persyaratan dan analisis.

Perbedaan pengembangan software dengan pengembangan sistem informasi

BAB1. PENDAHULUAN Siklus hidup sistem (SLC) SDLC Systems Development Life Cycle Siklus Hidup Pengembangan Sistem Systems Life Cycle

SIKLUS HIDUP PERANGKAT LUNAK

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

Rekayasa Perangkat Lunak (Software Engineering)

3/17/16 Testing dan Audit Perangkat Lunak - Universitas Mercu Buana Yogyakarta

MAKALAH REKAYASA PERANGKAT LUNAK ( SIKLUS HIDUP PERANGKAT LUNAK )

PENJAMINAN KUALITAS SOFTWARE pada SIKLUS HIDUP PENGEMBANGAN PERANGKAT LUNAK PROTOTYPING

BAB II LANDASAN TEORI. aplikasi sesuai dengan tujuan penelitian yang diharapkan. Aplikasi Penilaian Kinerja Karyawan ini antara lain sebagai berikut.

BAB III METODOLOGI PENELITIAN. Desain penelitian disusun berdasarkan tahapan sebagai berikut:

BAB 3 PENGUJIAN DALAM SIKLUS PENGEMBANGAN

Arsitektur Sistem Informasi. Tantri Hidayati Sinaga, M.Kom.

STRUKTUR DAN FUNGSI PENGOLAHAN DATA

Review Rekayasa Perangkat Lunak. Nisa ul Hafidhoh

Rekayasa Perangkat Lunak (Software Engineering)

BAB III METODOLOGI PENELITIAN. dalam pengumpulan data atau informasi guna memecahkan permasalahan dan

Manajemen Proyek Minggu 2

REKAYASA PERANGKAT LUNAK I

Perencanaan Proyek PL. A. Sidiq P. Prodi Teknik Informatika & Prodi Sistem Informasi Fakultas Teknologi Informasi Universitas Mercu Buana Yogyakarta

SATUAN ACARA PERKULIAHAN MATA KULIAH REKAYASA PERANGKAT LUNAK KODE/SKS : TI11. C342 / 2 SKS

SOFTWARE PROCESS MODEL

REKAYASA PERANGKAT LUNAK I

PENDAHULUAN REKAYASA PERANGKAT LUNAK. By PresenterMedia.com

Transkripsi:

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