Minggu, 23 September 2018

MODEL PENGEMBANGAN REKAYASA PERANGKAT LUNAK TERBARU

1. Model Evolusi

Model evolusi adalah sebuah model yang berulang-ulang. Model ini memiliki karakteristik yang memungkinkan para programmer mengembangkan perangkat lunaknya menjadi semakin lengkap di tiap versinya. Model ini diterapkan karena persyaratan (requierement) sering berubah sehingga hasil akhir dari sebuah produk tidak akan realistis, dimana edisi komplit dari produk tersebut mustahil dikeluarkan dikarenakan deadline market yang begitu ketat. Oleh karena itu lebih baik mengeluarkan versi limited untuk memperkenalkannya terlebih dahulu dan programmer dapat membuat model dari sebuah design untuk mengakomodasikan produk, yang secara bertahap akan diselesaikan dari waktu ke waktu.
 
Kelebihan Model Evolusi :
  1. Meningkatkan kemampuan memimpin dan mengatur sesuatu dengan pengembangan diri.
  2. Menciptakan suasana yang sadar akan kualitas suatu produk.
  3. Fungsi inti dari quality control dalam perusahaan besar pada tingkat lokakarya.
  4. Meningkatkan kebersamaan untuk mencapai suatu hasil dan semangat kerja karyawan.
  5. Meningkatkan kualitas dengan biaya efektif.
  6. Membebaskan manajemen.
  7. pekerja Shop Floor adalah lokasi terbaik untuk mengidentifikasi masalah.

Kekurangan Model Evolusi :
  1. Intensitas pekerjaan meningkat karena masalah akan lebih banyak dari pada yang diperkirakan.
  2. Manajemen perlu berkomitmen untuk sistem yang berkualitas, jika sebuah solusi dari sebuah masalah tidak dapat diterapkan maka itu bisa membuat frustasi para pekerja.
  3. Dapat memiliki efek negatif pada hubungan industrial.
  4. Dapat fokus pada masalah duniawi.

2. Model Rapid Application Development (RAD)

     Rapid Aplication Development (RAD) adalah sebuah model proses perkembanganperangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek (kira-kira 60 sampai 90 hari). Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen.

rad
  • Kelebihan Model RAD :
  1. Lebih efektif dari Pengembangan Model waterfall/sequential linear dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan.
  2. Cocok untuk proyek yang memerlukan waktu yang singkat.
  3. Model RAD mengikuti tahap pengembangan sistem seperti pada umumnya, tetapi mempunyai kemampuan untuk menggunakan kembali komponen yang ada sehingga pengembang tidak perlu membuatnya dari awal lagi sehingga waktu pengembangan menjadi lebih singkat dan efisien.
  • Kekurangan Model RAD :
  1. Model RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.
  2. Tidak semua aplikasi sesuai untuk RAD, bila system tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat bermasalah.
  3. RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang tinggi.
  4. Membutuhkan Tenaga kerja yang banyak untuk menyelesaikan sebuah proyek dalam skala besar.
  5. Jika ada perubahan di tengah-tengah pengerjaan maka harus membuat kontrak baru antara pengembang dan pelanggan.
 3. Model V / V-Model.
Bisa dikatakan model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.
 


Kelebihan v model :
  1. V Model sangat fleksibel. V Model mendukung project tailoring dan penambahan dan pengurangan method dantool secara dinamik. Akibatnya sangat mudah untuk melakukan tailoring pada V Model agar sesuai dengan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool baru atau menghilangkan method dan tool yang dianggap sudah obsolete.
  2. V Model dikembangkan dan di-maintain oleh publik. Userdari V Model berpartisipasi dalam change control boardyang memproses semua change request terhadap V Model.
    Kekurangan v model :
  1. V Model adalah model yang project oriented sehingga hanya bisa digunakan sekali dalam suatu proyek.
  2. V Model terlalu fleksibel dalam arti ada beberapa activitydalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalamactivity tersebut dan apa yang tidak.

 4. Agile Modeling
Agile Modeling merupakan filosofi tentang bagaimana membangun model dengan beberapa diantaranya dilakukan dengan format yang terperinci sedangkan model lain beberapa ada yang dilakukan secara samar dan minimalis. Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessman, serta antara developer dan managernya. Ciri lain dari Agile Software Development adalah klien menjadi bagian dari tim pembangun software.
  •  Kelebihan dari Agile Modeling:
  1.   Meningkatkan kepuasan kepada klien
  2. Pembangunan sistem dibuat lebih cepat
  3. Mengurangi resiko kegagalan implementasi software dari segi non-teknis
  4. Jika pada saat pembangunan system terjadi kegagalan,kerugian dari segi materi relative kecil.
  • Kelemahan dari Agile Modeling:
Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

  5. Incremental Model
Incremental Model merupakan gabungan antara model linear sekuensial dan prototyping. Setiap linear sekuen menghasilkan produk yang deliveriables. Increment pertama merupakan produk inti yang mengandung persyaratan/kebutuhan dasar. Penambahan dilakukan pada increment-incremet berikutnya.
increment5

Keunggulan dari Incremental Model :
  1. Personil bekerja optimal
  2. Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. Contohnya pemasukan data karyawan
  3. Mengurangi trauma karena perubahan sistem.  Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian
  4. Memaksimalkan pengembalian modal investasi konsumen
Kekurangan dari Incremental Model :
  1. Cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding)
  2. Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment
  3. Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung.




https://www.programming.smktarunabhakti.net/blog/2016/06/23/pemodelan-perangkat-lunak/

Senin, 10 September 2018

 
Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

IEEE Computer Society mendefinisikan rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.
rekayasa perangkat lunak adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan menggunakan prinsip reakayasa untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna.

Istilah software engineering, pertama kali digunakan pada akhir tahun 1950-an dan sekitar awal 1960-an. Pada tahun 1968, NATO menyelenggarakan konferensi tentang software engineering di Jerman dan kemudian dilanjutkan pada tahun 1969. Meski penggunaan kata software engineering masukan konferensi tersebut menimbulkan debat tajam tentang aspek engineering dari pengembangan perangkat lunak, banyak pihak yang menganggap konferensi tersebutlah yang menjadi awal tumbuhnya profesi rekayasa perangkat lunak
 
Sofware Engineering adalah orang yang mampu memilih alat bantu dalam perencanaan dan penerapan perangkat lunak, memiliki teknik menilai kualitas perangkat lunak yang dihasilkan, mampu mengkoordinasi, mengontrol dan mengatur pelaksanaan pekerjaan pembuatan perangkat lunak.

Ada Tahapan untuk seorang engineering yaitu:
  1. 1.      Metode
  • Metode yang digunakan untuk membuat atau mengembangkan perangkat lunak, mencakup :
  • Perencanaan proyek dan perkiraan.
  • Analisis keperluan sistim dan perangkat lunak.
  • Perancangan struktur data.
  • Arsitektur program.
  • Prosedur algoritma.
  • Coding.
  • Testing (Uji coba).
  • Pemeliharaan.
  1. 2.      Alat Bantu
Digunakan untuk mendukung pelaksanaaan pengembangan atau pembuatan perangkat lunak, berupa alat bantu manual dan alat bantu otomatis.
  1. 3.       Prosedur
Mendefinisikan urutan pengerjaan dari metoda dan alat yang digunakan dalam pemecahan atau pembuatan perangkat lunak.

TUJUAN
  •  Salah satu tujuan dari rekayasa perangkat lunak adalah menghasilkan perangkat lunak yang berkualitas dan sesuai dengan kebutuhan pengguna.

Adapun tujuan rekayasa perangkat lunak (RPL) yaitu :
- Mengenal masalah yang berkaitan dengan pembangunan software.
- Memahami kebutuhan perlunya pendekatan yang terstruktur untuk membangun software.
- Mampu mengambil kesimpulan tentang definisi software engineering.

Rekayasa Perangkat Lunak (RPL) di katakan berhasil yaitu :
- Systemnya lengkap dan dapat di kembangkan lagi.
- Selesai pada waktu dan jadwal yang telah ditentukan.
- Tidak memakan anggaran yang meningkat.
- Dapat digunakan dengan mudah.

Ada beberapa rekayasa perangkat lunak (RPL) di katakan gagal yaitu sebagi berikut :
- Diakhiri karena kontrak.
- Systemnya lengkap, tetapi memakan anggaran yang meningkat.
- Systemnya lengkap, tetapi melewati jadwal atau waktu yang telah di tentukan.
- Systemnya lengkap, tetapi tidak efisien.
- Systemnya lengkap, tetapi tidak bisa di kembangkan.

Pentingnya kebutuhan rekayasa perangkat lunak
    * Pengumpulan kebutuhan (requirement gathering)  merupakan kegiatan bukanlah pekerjaan  yang mudah.
   * Berbagai studi menyimpulkan bahwa kesalahan (error) yang ditemukan pada fasa pencarian kebutuhan memberikan kontribusi sebesar 40 – 50 % terhadap adanya cacat (defect) pada produk perangkat lunak.
* Spesifikasi kebutuhan yang lemah, kurangnya masukan dari pengguna, dan kelemahan dalam mengelola kebutuhan pengguna merupakan beberapa alasan mengapa cacat produk tersebut terjadi.
* Menemukan kebutuhan yang tepat bukan sebuah pekerjaan yang mudah. Seperti yang dinyatakan Steve McConnell, “The most difficult part of requirements gathering is not documenting what the users ‘want’; it is the effort of helping users figure out what they ‘need’ that can be successfully provided ….”. 


What makes software special :
- Difficult for the client to determine a full needs.
- Difficult for builders to truly understand client needs.
- Software is so easy to change.

- Difficult to test the software carefully and thoroughly.

Untuk merancang sebuah RPL atau SE kita membutuhkan sebuah pengalaman,pikiran,dan imajinasi.  - Kita harus memiliki pengalaman untuk merancang sebuah RPL atau SE  tidak sembarangan untuk membangun RPL yang baik.
- Tidak hanya pengalaman saja untuk merancang sebuah RPL atau SE kita juga harus memiliki pikiran apa yang ingin di buat apa di RPL tersebut.
- Dan kita juga harus mempunyai imajinasi untuk menggabungkan pengalaman dan pikiran kita, lalu kita bisa merancang sebuah RPL atau SE tersebut sesuai pengalaman, pikiran dan imajinasi.

Kata Kunci untuk RPL atau SE yaitu 3M : Merancang, Membangun, dan Merawat.



Sumber :