metode pengembangan rpl dan dfd
TRANSCRIPT
Rekayasa Perangkat Lunak
October 21
2014 Ayu Nurahmala (1331140007) MI2C
METODE dan DFD
1. Pemodelan system RPL dan metode-metodenya. Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan
awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.
Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model
umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:
Pendekatan Waterfall
Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam
proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji
coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan
dilanjutkan pada langkah berikutnya.
Pengembangan secara evolusioner
Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal
dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang meme nuhi
kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan
kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan
maintable.
Transformasi formal
Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan
transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program.
Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang
dikembangkan sesuai dengan spesifikasi.
Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan
kembali.
Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan
sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner,
saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan
menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian. Metode
penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika
Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse
masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.
Metode-metode pengembangan Rekayasa Perangkat Lunak
Waterfall Model / Linear Sequential Model
Waterfall model adalah model yang melakukan pendekatan pada perkembangan perangkat lunak secara seistematik dan sekuensial. Yang artinya kegiatan pada model ini dilakukan secara terurut berdasarkan panduan proses mulai dari komunikasi kepada client atau pelanggan sampai dengan aktifitas sampai pengorderan setelah masalah dipahami secara lengkap dan berjalan stabil sampai
selesai.
Ada 2 fase-fase dalam Waterfall model :
1. Menurut referensi Pressman
2. Menurut referensi Sommerville
Kedua fase-fase menggunakan nama yang berbeda pada tiap fasenya, tetapi pada dasarnya inti dari kedua fase-fase tersebut adalah sama. Tahapan-tahapan yang yang sering dijumpai adalah menurut
refrensi dari Sommerville karena lebih terperinci perbedaan pada tiap fasenya.
a. Requirements definition b. System and software design c. Implementation and unit testing d. Integration and system testing
e. Operation and maintenance
Kekurangan Waterfall model
Waterfall model bersifat kaku sehingga sulit untuk melakukan perubahan pada sistem perangkat
lunak.
Pemakaian Waterfall model
Waterfall model digunakan untuk pembuatan sistem perangkat lunak yang berukuran besardan
pembuatannya secara terpisah.
Incremental Proses Model
Dalam model Incremental ini proses pengerjaan perangkat lunak akan dilakukan perbagian sehingga bagian selanjutnya akan dikerjakan setelah bagian awal telah selesai dan selanjutnya sampai menghasilkan perangkat lunak yang lengkap dengan semua fungsi yang diperlukan dan pengerjaan perangkat lunak berakhir. Sebelum pengerjaan perangkat lunak akan dilakukan perancangan arsitektur
software sebagai kerangka dalam pengerjaan perbagian.
Tahapan dari Incremental Model :
Requirement -> penentuan kebutuhan perangkat lunak yang akan dibangun. Specification -> spesifikasi bagian dari perangkat lunak.
Architecture Design -> pembuatan perancangan perangkat lunak (dasar dari kerangka kerja)
Kelebihan incremental model
1. Resiko yang rendah pada pengembangan sistem.
2. Mengutamakan fungsi-fungsi pada sistem perangkat lunak sehingga kemudahan pemakaian
sistem yang paling di utamakan.
3. Tahap awal adalan dasar dari pembuatan tahap berikutnya (dikerjakan secara terurut)
The RAD model
RAD (Rapid Application Development) adalah model proses yang juga termasuk dalam Incremental Proses Model karena pembangunan dari sistem perangkat lunak dikerjakan dengan tahapan yang terurut mulai dari dasar (awal) sampai tahap paling tinggi (proses akhir pembuatan), tetapi perbedaan nya model ini dibagi menjadi beberapa modul dan dikerjakan secara besama-sama dan
sesuai dengan waktu yang ditentukan.
Kelebihan RAD model :
• Pengerjaan sistem yang cepat (60 -90 hari)
• RAD dapat menggunakan kembali komponen yang ada (reusable object) sehingga
pengembang pengembang tidak perlu membuat dari awal lagi.
• Proses pengiriman menjadi lebih mudah karena proses pembuatan berupa potongan-
potongan script
Kekurangan RAD model :
• Tidak tepat untuk sistem yang berukuran besar.
• Pembuatan sistem bisa gagal jika waktu kesepakatan tidak terpenuhi (terlalu cepat atau
permintaan agar diselesaikan lebih cepat dari perjanjian).
• Mempunyai banyak resiko karena dikerjakan dalam modul yang berbeda dan dalam
waktu yang hampir bersamaan dan pada tempat yang belum tentu sama.
Evolutionary Software Process Models A. Protoyping Model
Prototyping Model adalah model yang dapat diterapkan pada model apapun. Model ini tidak memerlukan data yang lengkapdari sisiclient dan banyaknya keraguan dari pembuat software karena kondisi yang belum diketahui (seberapa besar software, bagaimana system
penerapannya).
Model ini tepat digunakan jika pihak client menginginkan prototype dari software dalam waktu yang singkat. Dan prototype inilah yang akan menjadi acuan dari client untuk
memberikan data kebutuhan yang lebih lengkap pada pembuat software (developer).
Kekurangan dalam model prototype :
1. Pada prototype tentu saja banyak kebutuhan yang tidak di tampilkan seluruhnya karena data yang dikumpulkan hanya sebagian.
2. Prototypeyang di setujui oleh client harus dikembangkan oleh developer tanpa ada data tambahan dari client dan software dari prototype harus memiliki fungsi yang lengkap.
3. Banyak ketidak sesuaian pada bentuk prototype.
Model ini memerlukan kesepakatan antara client dan developer bahwa prototype hanyamenjadi
model dasa dari pembangunan software.
B. Spiral Model Spiral model adalah model proses yang pendekatannya bersifat realistis pada software besar
karena proses dari awal sampai proses pengiriman dan perbaikan dapat dipahami dengan baik oleh client dan developer.
Model ini mempunyai rangkaian kerja yang iterasi (peningkatan pada model) awal yang
berbentuk prototype dan kemudian iterasi selanjutnya akan menjadi perkembangan dari model sebelumnya. Model ini dapat terus digunakan meskipun software sudah dikirimkan karena
proses (siklus) dapat berputar lagi jika ada perubahan pada software sampai tidak ada
permintaan perubahan pada software oleh client.
Ada 6 pembagian proses pembuatan pada spiral model :
1. Komunikasi Pelanggan
2. Perencanaan
3.Analisis resiko
4.Perekayasaan
5.Konstruksi dan Peluncuran
6.Evaluasi Client
Kelebihan model Spiral :
Setiap tahap pengerjaan dibuat prototyping sehingga kekurangan dan apa yang diharapkan oleh client dapat diperjelas dan juga dapat menjadi acuan untuk client dalam mencari kekurangan kebutuhan.
Kekurangan model Spiral :
Banyak konsumen (Client) tidak percaya bahwa pendekatan secara evolusioner dapat dikontrol oleh kedua pihak.
Model spiral mempunyai resiko yang harus dipertimbangkan ulang oleh konsumen dan developer.
C. Concurrent Development Model
Pada model ini aktifitas kerja dilakukan secara bersamaan, setiap proses kerja memiliki beberapa triger(pemicu) kerja dari aktifitas. Pemicu dapat berasal dari awal proses kerja maupun dari pemicu yang lain karena setiap trigrer akan sling berhubungan.
Misalnya proses Desain akan berubah atau berhenti sementara karena ada perubahan
permintaan kebutuhan dari konsumen(client).
Kekurangan dari model ini:
Berhentinya suatu kegiatan karena kegiatan yang lain tentunya akan menyebabkan pengunduran waktu dari target yang ditentukan, yang artinya akan semakin banyak waktu yang ditunda untuk pengerjaan. Lebih lama proses pembuatan terhenti akan lebih banyak
timbul masalah saat mulainya proses pembuatan setelah terhenti
2. Data flow diagram (DFD) a. Definisi
Data Flow Diagram atau sering disingkat DFD adalah perangkat-perangkat analisis dan
perancangan yang terstruktur sehingga memungkinkan peng-analis sistem memahami sistem dan
subsistem secara visual sebagai suatu rangkaian aliran data yang saling berkaitan.
b. Arti symbol-simbolnya
Keterangan :
Entitas biasanya diberi nama dengan kata benda.
Aliran data merupakan perpindahan data dari satu titik ke titik yang lain (penggambarannya
dengan cara kepala tanda panah mengarah ke tujuan datanya.
Proses biasanya selalu menunjukkan suatu perubahan data dan terjadinya proses transformasi
data.
Penyimpanan Data (data store) diberi nama dengan kata benda, sesuai dengan data yang
disimpan didalamnya.
c. Contoh Kasus STUDI KASUS : RANCANGAN SISTEM PENJUALAN PADA BUTIK RAJA BUSANA
Prosedur penjualan yang sedang berlangsung di butik ini adalah :
1. Konsumen datang memesan barang 2. Dari proses tersebut kemudian dicatat dalam faktur rangkap 2 3. Selanjutnya faktur yang berwarna merah diserahkan ke konsumen, sedangkan faktur yang
berwarna putih disimpan untuk kemudian dicatat di data konsumen, data barang dan data transaksi.
4. Setelah itu dibuat laporan penjualan untuk diserahkan ke pemilik.
PEMBAHASAN : Diagram Konteks Sistem Penjualan Butik Raja Busana
Diagram Zero
KESALAHAN :
a. Bila anda tak pernah melakukan kesalahan, ada baiknya anda melihat lagi langkah anda.
Jangan2 anda tak melangkah setapak pun.
b. Kesalahan memang tak mengenakan, namun seorang optimis lebih banyak belajar dari
kesalahan daripada keberhasilan.
c. Kesalahan menuntun anda untuk mempelajari kembali sesuatu yang terjadi. Bukan Cuma
itu, kesalahan memimpin anda untuk mengambil tindakan yang lebih baik.
d. Kesalahan adalah kawan baik yang mengatakan secara samar apa yang harus anda kerjakan.
e. Lihatlah kesalahan apa adanya, jauhkan prasangka, kesedihan dan ratapan bila kesalahan
menimpa anda.
f. Karena dibalik kesalahan tersimpan kesempatan yang tersembunyi