Rekayasa Perangkat Lunak

Slides:



Advertisements
Presentasi serupa
RAPID APLICATION DEVELOPMENT ( RAD )
Advertisements

PENGEMBANGAN PERANGKAT LUNAK
Pengembangan Sistem Informasi
Created By : Siti arofah, s.soS
MODEL PROSES PERANGKAT LUNAK SPIRAL MODEL & COMPONENT ASSEMBLY
Rapid software development
Proses Software Bab 2.
Software Process Model
Sasaran Menjelaskan apa yang dimaksud model proses
PROSES-PROSES PERANGKAT LUNAK
01 WINTER ANALISIS DAN DESAIND SISTEM Template RPL – P2.
PENGANTAR REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK (Software Engineering) Eka Ismantohadi
PENGANTAR REKAYASA PERANGKAT LUNAK I
Model Proses PL.
PERENCANAAN PROSES PERANGKAT LUNAK
Perancangan Perangkat Lunak
Methods for Software Engineering
PENGETAHUAN PERANGKAT LUNAK & REKAYASA PERANGKAT LUNAK
Nama : Shadrach Jabonir / Matthew Marcelinus / Leonardus Handoko / Hendry Sunardi / Carles/ OVERVIEW OF SOFTWARE PROCESS MODEL.
PERTEMUAN 7 PENGEMBANGAN SPK
REKAYASA PERANGKAT LUNAK
 Communication  Planning  Modeling  Contruction  Deployment.
Metodologi Pengembangan Sistem Informasi
Rekayasa Perangkat Lunak (Lanjut)
Rapid Application Development & Incremental Development
Rekayasa Perangkat Lunak
Metode rpl BY: Y. PALOPAK S.Si., MT..
PEMAHAMAN REKAYASA PERANGKAT LUNAK
PROSES-PROSES PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
PENGEMBANGAN PERANGKAT LUNAK.
SE2423 Rekayasa Perangkat Lunak
Pendhahuluan Software engineering BY: Y. PALOPAK S.Si., MT.
Rekayasa Perangkat Lunak Model Proses PL
System Development Life Cycle (SDLC)
Rekayasa perangkat lunak (rpl)
Pengenalan Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak
Pemeliharaan Perangkat Lunak
RPL.
Metode Rekayasa Perangkat Lunak
SISTEM INFORMASI PEMASARAN
Rekayasa Perangkat Lunak
REKAYASA PERANGKAT LUNAK
PROSES REKAYASA PERANGKAT LUNAK
RPL.
Prescriptive Process Models
Pengantar Teknologi Informasi (Teori)
Metodologi Pengembangan Sistem Informasi
METODE PENGEMBANGAN PERANGKAT LUNAK
PERTEMUAN 2 Proses Pengembangan Perangkat Lunak
KELOMPOK FARHATULLAILA ( )
Kelompok V FERDY WIDJAJA YOUNGKY DWI P
Metodologi Pengembangan Sistem Informasi
PENGEMBANGAN SPK.
REKAYASA PERANGKAT LUNAK
PENGEMBANGAN PERANGKAT LUNAK
Rekayasa Perangkat Lunak
ANALISIS DAN PEMODELAN
MODEL PROSES PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Pengembangan Sistem Informasi
SOFTWARE ENGGINERING Model Model Siklus Rekayasa Perangkat Lunak
Pengembangan Sistem Informasi
Metodologi Pengembangan Sistem Informasi
MODEL PROSES PERANGKAT LUNAK
Software Development Life Cycle (SDLC)
Kelompok 3 | Rekayasa Sistem Informasi : Ahmad Rifai Eplin Mimi Susanti [ ] Fitriya Dewi Damayanti [ ] Ulfa Yuliana [ ] Kelompok.
System Development Life Cycle
Transcript presentasi:

Rekayasa Perangkat Lunak Pertemuan 8 dan 9 Lukman Hakim

Tujuan Perkuliahan Untuk menjelaskan bagaimana pengembangan proses bertingkat ( incremental development ) memberikan hasil yang cepat dalam pembuatan perangkat lunak Membahas esensi dari metode agile development Menjelaskan prinsip dan praktek dari extreme programming menjelaskan peran prototype dalam proses software

Topik Keterkaiatan RPL dengan Ilmu lain Method Agile Method Prototipe

RPL dengan Ilmu lain bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif bidang ilmu ergonomika menyangkut hubungan ( interaksi) antar manusia dengan komponen-komponen lain dalam sistem komputer bidang ilmu rekayasa sistem meliputi teori sistem, analisis biaya-keuntungan, pemodelan, simulasi, proses, dan operasi bisnis

Perkembangan RPL Tahun Kejadian 1940an Komputer pertama yang membolehkan pengguna menulis kode program langsung 1950an Generasi awal interpreter dan bahasa macro Generasi pertama compiler 1960an Generasi kedua compiler Komputer mainframe mulai dikomersialkan Pengembangan perangkat lunak pesanan Konsep Software Engineering mulai digunakan 1970an Perangkat pengembang perangkat lunak Perangkat minicomputer komersial 1980an Perangkat Komputer Personal (PC) komersial Peningkatan permintaan perangkat lunak 1990an Pemrograman berorientasi obyek (OOP) Agile Process dan Extreme Programming Peningkatan drastis kapasitas memori Peningkatan penggunaan internet 2000an Platform interpreter modern (Java, .Net, PHP, dll) Outsourcing

Model Pengembangan RPL Waterfall Incremental Prototyping Model Spiral Model Rational Unified Process (RUP) Extreme Programming (XP)

Model Rapid Aplication Development (RAD) Adalah model proses pengembangan perangkat lunak yang bersifat inkremental terutama untuk waktu pengerjaan yang pendek. Model RAD adalah adaptasi dari waterfall model versi kecepatan tinggi. Cat: Model RAD membagi tim pengembangan menjadi beberapa tim untuk mengerjakan beberapa komponen masing-masing tim pengerjaan dapat dilakukan secara pararel.

Ilustrasi Model RAD

Defenisi Pemodelan Bisnis yaitu pemodelan yang dilakukan untuk memodelkan fungsi bisnis untuk mengetahui informasi apa yang terkait proses bisnis, informasi apa saja yang harus dibuat, siapa yang membuat informasi itu, proses apa saja yang terkait informasi itu. Pemodelan data yaitu memodelkan data apa saja yang dibutuhkan berdasarkan pemodelan bisnis dan mendenisikan atribut-atributnya beserta relasinya dengan data-data yang lain. Pemodelan proses yaitu mengimplementasikan fungsi bisnis yang sudah didefinisikan terkait dengan pendefenisi an data. Pembuatan aplikasi yaitu mengimplementasikan pemodelan proses dan data menjadi program

Kelemahan RAD Untuk pembuatan sistem perangkat lunak dengan skala besar makan RAD akan memerlukan sumber daya manusia yang cukup besar. Jika tidak ada persetujuan untuk pengembangan PL secara dengan cepat(Rapid) makan proyek dengan model ini akan gagal. Jika sistem PL yang akan dibuat tidak bisa dimodeulkan (dibagi-bagi menjadi beberapa komponen) maka model RAD tidak dapat digunakan. Model RAD tidak cocok digunakan untuk sistem PL yang memiliki resiko teknis tinggi, mis menggunakan teknologi baru yng belum banyak dikenal.

Kriteria Proyek RAD Anggota tim sudah berpengalaman mengembangkan PL yang sejenis. Pengembangan sudah memiliki komponen-komponen sistem yg bisa digunakan kembali dalam proyek tersebut.

Pengembangan Model RAD Agile Software (Pengembangan Perangkat Lunak “Tangkas”) dimana interaksi antar anggota tim dan pelanggan dianggap sebagai hal yang penting lebih dari perangkat ataupun proses pengembangan PL. Hal ini ditujukan agar pengembangan bersifat sangat tangkas dalam menengani perubahan yang terjadi. Contoh pengembangan perangkat lunak “Tangkas” adalah scrum dan pemrograman ekstrim.

Pengembangan Scrum (semua Tim) Semua tim terlibat didalam prioyek secara overlapping (tumpang tindih) sesuai dengan kebutuhan sumber daya pada proyek agar dapat meningkatkan kecepatan pengembangan dan fleksibilitas. Peran tim sudah ditentukan

Extreme Programming Mengizinkan tim pengembangan untuk berkomunikasi langsung dengan pelanggan (customer) atau user maupun sesama pembuat program. Ciri khas model ini adalah komunikasi yang dilakukan setiap hari atau setiap ditemukan hal-hal yang kurang jelas. Model sangat mengandalkan adanya umpan balik sehingga dibutuhkan anggota-anggota tim yang berkualitas.

Extreme Programming

Keunggulan Extreme Programming Menjalin komunikasi yang baik dengan klien. (Planning Phase) 2. Menurunkan biaya pengembangan (Implementation Phase) 3. Meningkatkan komunikasi dan sifat saling menghargai antar developer. (Implementation Phase) 4. XP merupkan metodologi yang semi formal. (Planning Phase) 5. Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima, atau dengan kata lain fleksibel. (Maintenance Phase)

kelemahan Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga). XP juga memiliki keunggulan yang sekaligus menjadi kelemahannya, yaitu XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user. http://www.agilemodeling.com/artifacts/userStory.htm

Model Iteratif Pertemuan 9

Model Iteratif Mengombinasikan proses-proses pada model air terjun dan iteratif pada model prototipe. Model inkremental akan menghasilkan versi-versi perangkat lunak yang sudah mengalami penambahan fungsi untuk setiap pertambahannya(inkremen/increment)

Model Iteratif

Incremental (Defenisi) Pengembangan dibagi menjadi bagian2 yang dapat berkembang secara bertambah (increments) Setiap bagian harus memenuhi fungsi-fungsi yang diperlukan Kebutuhan pengguna diprioritaskan dan prioritas tertinggi didahulukan dalam pengembangan Begitu dimulai, kebutuhan yang telah tertangani akan dibekukan sehingga memberikan tempat bagi kebutuhan lain untuk dapat berevolusi

Kelebihan dan Kekurangan Kebutuhan pengguna / customer dipenuhi pada setiap bagian yang selesai terlebih dahulu Bagian yang selesai terlebih dahulu menjadi prototipe Resiko rendah Bagian yang punya prioritas tertinggi dapat dites secara intensive Permasalahan Batasan proses tidak jelas Sistem kurang terstruktur Kemampuan aplikasi Untuk sistem dengan interaksi skala kecil dan medium Untuk antarmuka user Untuk sistem dengan masa penggunaan pendek

Prototipe Model

Prototipe Membuat sebuah contoh prototipe untuk menunjukkan kebutuhan dan desain ke pemakai Harus ada versi yang dapat dijalankan sebagai prototipe sebelum sistem dikembangkan (bisa berupa contoh sistem lain) Harus ada implementasi sistem yang dikembangkan sebelum dibuat sebuah sistem final

Mock-up Sesuatu yang digunakan sebagai model desain yang digunakan untuk mengajar, demontrasi, evaluasi desain, promosi, atau keperluan lain.

Kelemahan Prototipe Pelanggan dapat sering mengubah-ubah menambah-tambah spesifikasi kebutuhan karena menganggap aplikasi seudah dengan cepat dikembangkan, karena adanya iterasi ini dapat menyebabkan pengembangan banyak mengalah dengan pelanggan. Pengembangan lebih sering mengambil kompromi dengan pelanggan untuk mendapatkan prototipe dengan waktu yang cepat sehingga pengembangan lebih sering melakukan segala cara(tanpa idealis) guna menghasilkan prototipe untuk didemonstrasikan. Hal ini dapat menyebakan kualitas PL kurang baik. Model prototipe kurang cocok untuk aplikasi dengan skala besar

Keuntungan Cocok digunakan untuk menjabarkan kebutuhan pelanggan secara lebih detail karena pelanggan sering kali kesulitan menyampaikan kebutuhannya secara detail tanpa melihat gambaran yang jelas. Kegunaan sistem yang lebih baik Kesesuaian sistem yang lebih dekat dengan kebutuhan user. Kualitas desain yang lebih baik Keterpeliharaan yang lebih baik Usaha pengembangan yang lebih ringan

Model Spiral

Model Spiral Mendefinisikan kebutuhan dengan sedetail mungkin Pembuatan desain untuk sistem yang baru Proses direpresentasikan dalam aktivitas berbentuk spiral Setiap perulangan (loop) dalam spiral merepresentasikan sebuah fase dalam proses Fase-fase tidak fix (spesikasi -design loop) dipilih sesuai dengan yang diperlukan Resiko selalu secara transparan dimonitor dan dipecahkan selama proses berlangsung

Model Spiral

Interface Generation Banyak aplikasi yang berdasarkan seputar form yang kompleks, dan mengembangkan form tersebut secara manual sangat memakan waktu. Environment RAD menyediakan dukungan untuk men-generate interface seperti: Bentuk interaktif pembuatan form dengan menggunakan teknik drag and drop Hubungan antar form dimana urutan dari tampilan form dapat dispesifikasikan. Verifikasi form

Visual Programming Bahasa pemrograman yang digunakan untuk mengembangkan prototipe dengan mengembangkan antarmuka ( VB ) Banyak library component yang digunakan untuk mendukung sistem

Visual programming with reuse

Permasalahan pada Visual Development Sulit untuk berkoordinasi dengan team Ketergantungan dengan software dapat menimbulkan kesulitan untuk melakukan maintenance

Soal Latihan Apa resiko yang dihadapi jika pengembangan aplikasi (RPL) tidak mengikuti tahapan-tahapan SDLC Mengapa waterfall model sebagai SDLC yang paling sederhana dan hanya cocok digunakan untuk aplikasi sekala kecil. Mengapa ketika menerapkan metode prototipe, pada tahap awal harus benar-benar diperjelas batasan-batasan/ruang lingkup/spesifikasi perangkat lunak secara umum. Mengapa metode RAD bisa memberikan hasil yang lebih cepat dibandingkan metode waterfall?