Judul : Tahapan RPL
link : Tahapan RPL
Tahapan RPL
Seperti telah disebutkan, meskipun dalam pendekatan-nya berbeda-beda, namun model-model di atas (pada postingan: Model proses rpl) memiliki kesamaan, yaitu menggunakan pola tahapan: analysis – design – coding (construction) – testing – maintenance.
Analisis
Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi komponen-komponennya, dengan tujuan mempelajari seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk meraih tujuan mereka.Analisis, mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak. Karena, semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil analisis. Tahapan-tahapan dalam analisis rekayasa perangkat lunak secara ringkas dapat dilihat pada Gambar 2.7.
Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis, yaitu: pemodelan proses bisnis. Model proses adalah model yang memfokuskan pada seluruh proses di dalam sistem yang mentransformasikan data menjadi informasi (Harris, 2003). Model proses, juga menunjukkan aliran data yang masuk dan keluar pada suatu proses. Biasanya, model ini digambarkan dalam bentu Diagram Arus Data (Data Flow Diagram/DFD). DFD menyajikan gambaran apa yang manusia, proses, dan prosedur (sedang melakukan) untuk mentransformasi data menjadi informasi.
Umumnya ada empat notasi yang sering digunakan dalam DFD, (seperti tampak pada Gambar 2.8).
Dalam pembuatan DFD ada beberapa tahapan yang dilakukan secara berurutan. Gambar 2.9, menunjukkan urutan tahapan tersebut.
Context diagram adalah DFD ruang lingkup dari sistem yang menunjukkan batas-batas sistem, external entitiy yang berinteraksi dengan sistem, dan aliran data utama antara external entity dengan sistem. Context diagram menggambarkan keseluruhan sistem dalam suatu proses tunggal. Gambar 2.10 menunjukkan sebuah contoh context diagram.
Context diagram pada Gambar 2.10 tampak hanya ada satu proses tunggal yang me-representasikan sistem yang dimodelkan. Pada proses ini, diberi notasi angka 0 untuk menunjukkan ini adalah level paling abstrak dari sistem. Selain itu ada tiga external entity, yaitu: customer, kitchen, dan restaurant manager. Ketiganya dapat berperan sebagai sumber data (dalam contoh di atas adalah customer), atau sebagai penerima informasi (dalam contoh di atas customer, kitchen, dan restaurant manager). Data flow yang tampak pada gambar menunjukkan ada satu data flow yang masuk ke sistem, dan ada tiga data flow yang keluar dari sistem. Masing-masing data flow diberi label yang menunjukkan data apa yang sedang mengalir.
Setelah context diagram terbentuk dengan benar, maka langkah selanjutnya adalah merinci context diagram tersebut dalam DFD Level 0. DFD Level 0 adalah DFD yang me-representasikan proses-proses, data flow, dan data storage utama di dalam sistem. DFD Level 0 ini akan digunakan sebagai dasar untuk membangun DFD yang level dibawahnya (Level 1, 2, 3, .. dst), atau biasa disebut sebagai dekomposisi DFD. Gambar 3.10 merupakan DFD level 0 dari context-diagram pada gambar 2.11.
Pada gambar 2.11 tampak adanya pemecahan pada proses dari yang semula hanya satu menjadi empat. Masing-masing proses diberi nomor kode 1.0, 2.0, 3.0 dan 4.0. Jumlah external entity harus tetap, yaitu: 3. Demikian pula data flow yang keluar dan masuk (input dan output) ke dalam sistem harus sama dengan pada context diagram. Sedangkan data flow yang berada di dalam sistem (yang mengalir antar proses dan atau data storage) tergantung pada proses dan data storage yang terlibat. Ada dua data storage, yaitu: Goods Sold File dan Inventory File. Kedua data storage ini digunakan untuk menyimpan data dari suatu proses. Data ini juga akan dibaca/diakses oleh proses yang lain. Sebagai contoh, data storage Inventory File berisi data hasil proses 3.0 (Update Inventory File). Data ini akan digunakan proses 4.0 (Produce Management Reports) untuk membuat laporan yang akan disampaikan pada Restaurant Manager.
DFD level berikutnya yaitu: level 1, 2 dan seterusnya, diperlukan apabila level sebelumnya dirasa kurang detil. Sebagai contoh, apabila DFD level 0 (Gambar 14.12) dirasa belum cukup detil menunjukkan arus data yang mengalir, maka dapat dibuat detilnya pada DFD level 1. Bagian yang harus didetilkan biasanya adalah proses. Detil pada level berikutnya, mungkin pada semua proses atau hanya pada proses-proses tertentu saja. DFD pada level 0 maupun level di bawahnya, memiliki kesamaan aturan yang tersaji pada tabel berikut ini.
Disain
Disain perangkat lunak adalah tugas, tahapan, atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004).Disain perangkat lunak sering juga disebut sebagai physical design. Jika tahapan analisis sistem menekankan pada masalah bisnis (business rule), maka sebaliknya disain perangkat lunak fokus pada sisi teknis dan implementasi dari sebuah perangkat lunak (Whitten et al, 2004).
Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada stake-holder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi disain umum hanya berisi gambaran umum agar stake-holder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun. Biasanya, diagram USD tentang perangkat lunak yang baru adalah merupakan point penting dibagian ini. Spesifikasi disain rinci atau kadang disebut disain arsitektur rinci perangkat lunak, diperlukan untuk merancang sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly, dan memiliki dasar-dasar untuk pengembangan selanjutnya.
Desain arsitektur ini terdiri dari desain database, desain proses, desain user interface yang mencakup desain input, output form dan report, desain hardware, software, dan jaringan. Desain proses merupakan kelanjutan dari pemodelan proses yang dilakukan pada tahapan analisis.
Konstruksi
Konstruksi adalah tahapan menerjemahkan dari hasil disain logis dan fisik ke dalam kode-kode program computer.Pengujian
Pengujian sistem melibatkan semua kelompok pengguna yang telah direncanakan pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap perangkat lunak, akan berakhir ketika dirasa semua kelompok pengguna menyatakan bisa menerima perangkat lunak tersebut berdasarkan kriteria-kriteria yang telah ditetapkan.Perawatan dan konfigurasi
Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka tahapan baru menjadi muncul, yaitu: perawatan perangkat lunak. Ada beberapa tipe perawatan yang biasa dikenal dalam dunia perangkat lunak, (seperti terlihat pada diagram di Gambar 2.12).
- Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa dikenal sebagai bugs. Perawatan bisa dilakukan dengan memperbaiki kode program, menambah bagian yang dirasa perlu atau malah menghilangkan bagian-bagian tertentu.
- Tipe perawatan routine biasa juga disebut preventive maintenance yang dilakukan secara rutin untuk melihat kinerja perangkat lunak, (apakah ada atau tidak ada-nya kesalahan).
- Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari komponen-komponen yang terlibat dalam perangkat lunak tersebut. Sebagai contoh, yaitu: perubahan platform sistem operasi dari versi lama ke versi baru, menyebabkan perangkat lunak harus diupgrade.
| METODE REKAYASA PERANGKAT LUNAK |
| 1. Model Proses Teknik Perangkat Lunak 2. Tahapan Teknik Perangkat Lunak |
Demikianlah Artikel Tahapan RPL
Sekianlah artikel Tahapan RPL kali ini, mudah-mudahan bisa memberi manfaat untuk anda semua. baiklah, sampai jumpa di postingan artikel lainnya.
Anda sekarang membaca artikel Tahapan RPL dengan alamat link https://sebuahteknologi.blogspot.com/2015/03/tahapan-rpl.html