Model-Model Proses Siklus Rekayasa Perangkat Lunak (SDLC)

Model-Model Proses Siklus Rekayasa Perangkat Lunak (SDLC) - Model proses disebut juga dengan aliran kerja (workflow), yakni tata cara bagaimana elemen-elemen proses berhubungan satu dengan lainnya. Aliran kerja ini dapat juga disebut dengan siklus hidup (life-cycle) sistem yang dimulai dari sejak sistem diajukan untuk dibangun hingga saat ia ditarik dari peredaran.

Fungsi utama model proses pengembangan perangkat lunak adalah :

• menentukan tahap-tahap yang diperlukan untuk pengembangan perangkat lunak.
• menentukan urutan pelaksanaan dari tahap-tahap tersebut dalam rangka pengembangan perangkat lunak.
• menentukan kriteria transisi/perpindahan dari satu tahap ke tahap berikutnya.

Untuk menentukan mana model yang terbaik, kita harus tahu apa kelebihan dan kekurangan model-model proses tersebut. Akan tetapi, model proses biasanya bukan ditentukan mana yang terbaik atau tidak, tetapi ditentukan oleh karakteristik dari berbagai macam faktor, misalnya tim SE-nya, atau software-nya sendiri, waktu untuk melakukan SE, kebijakan-kebijakan dari perusahaan, dan sebagainya. Dengan menggunakan model proses yang terbaru pun, ketika diaplikasikan ke dalam perusahaan misalnya, tetapi kalau tim SE-nya tidak siap dengan kondisi yang mengharuskan menggunakan model proses tersebut, tentunya tidak mungkin bisa dilakukan. Kalaupun dipaksakan tentu saja hasilnya tidak akan maksimal. Akan tetapi di perusahaan lain, bisa jadi menerapkan model proses yang sama, tetapi hasilnya bagus, karena tim SE-nya siap atau scope softwarenya berbeda.

image source: www.newtutorialslab.com

baca juga: Siklus Hidup Pengembangan Perangkat Lunak Berturut (SDLC)

Model Waterfall

Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement. Secara umum tahapan pada model waterfall (menurut Ian Sommerville) dapat dilihat pada gambar berikut :

Gambar di atas adalah tahapan umum dari model proses ini menurut Ian Sommerville. Penjelasan dari tiap tahapan tersebut adalah :

1. Requirements analysis and definition: Di tahapan ini dilakukan Analisa kebutuhan 
2. System and software design: Pada tahapan ini, desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.
3. Implementation and unit testing: 
4. Desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.
5. Integration and system testing: Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).
6. Operation and maintenance: Mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya

Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:

1. System / Information Engineering and Modeling. Pemodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.

2. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

3. Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

4. Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

5. Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.

6. Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

KELEBIHAN WATERFALL :

• Model ini paling banyak digunakan karena pengaplikasian menggunakan model ini mudah
• Ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah.

Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.

KELEMAHAN WATERFALL :

• Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.
• Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.
• Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.

Berdasarkan kelebihan dan kekurangan tersebut, nantinya akan dikembangkan model-model yang lain, bahkan ada tahap evolusioner dari suatu model proses untuk mengatasi kelemahan-kelemahan tadi. Meskipun secara tahapan masih menggunakan standar tahapan waterfall model. Kesimpulannya adalah ketika suatu project skalanya sedang mengarah kecil bisa menggunakan model ini. Akan tetapi kalau sudah project besar, tampaknya kesulitan jika menggunakan model ini.

Model V

Teknik model V sering disebut sebagai pengembangan dari teknik 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. “V” untuk verifikasi dan validasi dan merupakan model standar yang banyak dipakai di negara-negara Eropa seperti standar untuk proyek pertahanan dan administrasi federal di Jerman.

Berikut penjelasan masing-masing tahap beserta tahap pengujiannya (diambil www.softwaretestingvideos.com) :

1. Requirement Analysis & Acceptance Testing
Tahap Requirement Analysis sama seperti yang terdapat dalam model waterfall. Keluaran dari tahap ini adalah dokumentasi kebutuhan pengguna.

Acceptance Testing merupakan tahap yang akan mengkaji apakah dokumentasi yang dihasilkan tersebut dapat diterima oleh para pengguna atau tidak.

2. System Design & System Testing
Dalam tahap ini analis sistem mulai merancang sistem dengan mengacu pada dokumentasi kebutuhan pengguna yang sudah dibuat pada tahap sebelumnya. Keluaran dari tahap ini adalah spesifikasi software yang meliputi organisasi sistem secara umum, struktur data, dan yang lain. Selain itu tahap ini juga menghasilkan contoh tampilan window dan juga dokumentasi teknik yang lain seperti Entity Diagram dan Data Dictionary.

3. Architecture Design & Integration Testing
Sering juga disebut High Level Design. Dasar dari pemilihan arsitektur yang akan digunakan berdasar kepada beberapa hal seperti: pemakaian kembali tiap modul, ketergantungan tabel dalam basis data, hubungan antar interface, detail teknologi yang dipakai.

4. Module Design & Unit Testing
Sering juga disebut sebagai Low Level Design. Perancangan dipecah menjadi modul-modul yang lebih kecil. Setiap modul tersebut diberi penjelasan yang cukup untuk memudahkan programmer melakukan coding. Tahap ini menghasilkan spesifikasi program seperti: fungsi dan logika tiap modul, pesan kesalahan, proses input-output untuk tiap modul, dan lain-lain.

5. Coding
Dalam tahap ini dilakukan pemrograman terhadap setiap modul yang sudah dibentuk.

KELEBIHAN MODEL V :

• Merupakan model pengembangan terstruktur.
• Setiap fase dapat diimplementasikan dengan dokumentasi yang detail dari fase sebelumnya.
• Aktivitas pengujian dapat dimulai di awal proyek, sehingga mengurangi waktu proyek.

KELEMAHAN MODEL V :

• Dokumentasi harus cukup detail agar fase selanjutnya dapat berjalan dengan baik.

Model Prototyping

Prototype adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan.

Prototyping tepat digunakan saat tidak didapati kepastian dimana definisi user masih sangat bersifat umum serta tidak rinci sehingga pengembang tidak tahu pasti mengenai :

• pilihan algoritma yang akan dipakai
• lingkungan sistem yang akan dipakai serta 
• bentuk dan karakteristik antar muka pemakai.

Model prototype dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari perangkat lunak dan mengidentifikasi segala kebutuhan yang diketahui. Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak. Prototipe bisa menjadi paradigma yang efektif bagi rekayasa perangkat lunak. Kuncinya adalah mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan.

Model prototipe :

1. Evolutionary prototipe

Pada metode ini, prototype-nya tidak dibuang, melainkan digunakan sebagai dasar untuk iterasi perancangan selanjutnya. Dalam hal ini, sistem yang sesungguhnya dipandang sebagai evolusi dari versi awal yang terbatas menuju produk finalnya. Tujuan dari evolutionary prototyping adalah menyerahkan sistem yang dapat dipakai kepada end-user .Pembangunan sistem di mulai dari kebutuhan yang paling dipahami. Prototipe evolusioner , sistem dibangun dengan cara memulai dari versi initial sampai versi final.

Tahapan model evolutionary prototipe :

a. Mengidentifikasi kebutuhan pemakai. Analis sistem mewawancarai pemakai untuk mendapatkan gagasan dari apa yang diinginkan pemakai terhadap sistem

b. Mengembangkan prototipe. Analis sistem, mungkin bekerjasama dengan spesialis informasi lain, menggunakan satu atau lebih peralatan prototyping untuk mengembangkan sebuah prototipe.

c. Menentukan apakah prototipe dapat diterima (sudah sesuai). Analis mendidik pemakai dalam penggunaan prototipe dan memberikan kesempatan kepada pemakai untuk membiasakan diri dengan sistem. Pemakai memberikan masukan bagi analis apakah prototipe memuaskan/sudah sesuai. Jika ya, langkah d. Akan diambil; jika tidak prototipe direvisi dengan mengulangi langkah a., b., c. Dengan pengertian yang lebih baik mengenai kebutuhan pemakai.

d. Menggunakan prototipe. Prototipe ini menjadi sistem operasional.

2. Throw away prototipe

Prototype dibuat dan ditest. Pengalaman yang diperoleh dari pembuatan prototype tersebut digunakan untuk membuat produk akhir (final), sementara prototype tersebut dibuang (tak dipakai). Tujuan throw-away prototyping adalah memvalidasi dan menurunkan persyaratan sistem. Prototipe dapat di mulai dari kebutuhan yang paling tidak dipahami. Prototipe Throw-away mencakup pengembangan prototipe untuk memahami persyaratan sistem.

Kelebihan Prototyping :

• Kesalahpahaman antara sistem developer dan sistem user dapat diidentifikasikan dan dibetulkan.
• Prototipe yang sedang bekerja mungkin sangat berguna dalam suatu pembuktian manajemen dimana suatu proyek adalah fleksibel sehingga menjamin kelangsungan dukungan.

Kelemahan Prototyping :

• Prototipe hanya bisa berhasil jika pemakai bersungguh-sungguh dalam menyediakan waktu dan pikiran untuk mengerjakan prototipe
• Kemungkinan dokumentasi terabaikan karena pengembangan lebih berkonsentrasi pada pengujian dan pembuatan prototipe
• Mengingat target waktu yang pendek, ada kemungkinan sistem yang dibuat tidak lengkap dan bahkan sistem kurang teruji
• Jika terlalu banyak proses pengulangan dalam membuat prototipe, ada kemungkinan pemakai menjadi jenuh dan memberikan reaksi yang negatif
• Apabila tidak terkelola dengan baik, maka prototipe menjadi tidak pernah berakhir. Hal ini disebabkan permintaan terhadap perubahan terlalu mudah untuk dipenuhi.

Model Spiral

Model ini ditemukan sekitar tahun 1988 oleh Barry Boehm. Spiral model adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan digabungkan dengan aspek sistematis yang dikembangkan dengan model waterfall.

Model ini juga mengkombinasikan top-down design dengan bottom-up design, dimana top-down design menetapkan sistem global terlebih dahulu, baru diteruskan dengan detail sistemnya, sedangkan bottom-up design berlaku sebaliknya. Top-down design biasanya diaplikasikan pada model waterfall dengan sequential-nya, sedangkan bottom-up design biasanya diaplikasikan pada model prototyping dengan feedback yang diperoleh.

Dari 2 kombinasi tersebut, yaitu kombinasi antara desain dan prototyping, serta top-down dan bottom-up, yang juga diaplikasikan pada model waterfall dan prototype, maka spiral model ini dapat dikatakan sebagai model proses hasil kombinasi dari kedua model tersebut. Oleh karena itu, model ini biasanya dipakai untuk pembuatan software dengan skala besar dan kompleks.

Spiral model dibagi menjadi beberapa framework aktivitas. Berikut adalah aktivitas-aktivitas yang dilakukan dalam spiral model:

1. Customer communication. Aktivitas yang dibutuhkan untuk membangun komunikasi yang efektif antara developer dengan user / customer terutama mengenai kebutuhan dari customer.
2. Planning. Aktivitas perencanaan ini dibutuhkan untuk menentukan sumberdaya, perkiraan waktu pengerjaan, dan informasi lainnya yang dibutuhkan untuk pengembangan software.
3. Risk Analysis. Aktivitas analisis resiko ini dijalankan untuk menganalisis baik resiko secara teknikal maupun secara manajerial. Tahap inilah yang mungkin tidak ada pada model proses yang juga menggunakan metode iterasi, tetapi hanya dilakukan pada spiral model.
4. Engineering. Aktivitas yang dibutuhkan untuk membangun 1 atau lebih representasi dari aplikasi secara teknikal.
5. Construction & Release. Aktivitas yang dibutuhkan untuk develop software, testing, instalasi dan penyediaan user / costumer support seperti training penggunaan software serta dokumentasi seperti buku manual penggunaan software.
6. Customer evaluation. Aktivitas yang dibutuhkan untuk mendapatkan feedback dari user / customer berdasarkan evaluasi mereka selama representasi software pada tahap engineering maupun pada implementasi selama instalasi software pada tahap construction and release.

Berikut adalah gambar dari spiral model secara umum :

Tidak seperti model-model konvesional dimana setelah SE selesai, maka model tersebut juga dianggap selesai. Akan tetapi hal ini tidak berlaku untuk spiral model, dimana model ini dapat digunakan kembali sepanjang umur dari software tersebut. Pada umumnya, spiral model digunakan untuk beberapa project seperti Concept Development Project (proyek pengembangan konsep), New Product Development Project (proyek pengembangan produk baru), Product Enhancement Project (proyek peningkatan produk), dan Product Maintenance Project (proyek pemeliharaan proyek). Keempat project tersebut berjalan berurutan mengitari sirkuit dari spiral. Sebagai contoh setelah suatu konsep dikembangkan dengan melalui aktivitas-aktivitas dari spiral model, maka dilanjutkan dengan proyek selanjutnya yaitu pengembangan produk baru, peningkatan produk, sampai pemeliharaan proyek. Semuanya melalui sirkuit-sirkuit dari spiral model.

Kelebihan Spiral

• Pengguna dan developer bisa memahami dengan baik software yang dibangun karena progress dapat diamati dengan baik.
  Model ini sangat baik digunakan untuk pengembangan sistem software dengan skala besar. Karena progress perkembangan dari SE dapat dipantau oleh kedua belah pihak baik developer maupun user / customer, sehingga mereka dapat mengerti dengan baik mengenai software ini begitu juga dengan resiko yang mungkin didapat pada setiap aktivitas yang dilakukan. 
• Estimasi menjadi lebih realistik seiring berjalannya proyek karena masalah ditemukan sesegera mungkin.
  Kelebihan model ini ada pada analisis resiko yang dilakukan, sehingga resiko tersebut dapat direduksi sebelum menjadi suatu masalah besar yang dapat menghambat SE. 
• Lebih mampu menangani perubahan yang sering terjadi pada software development.
  Dengan menggunakan prototype juga bisa menghindari terjadinya resiko yang muncul, tetapi kelebihan dari model ini yaitu dilakukannya proses prototyping untuk setiap tahap dari evolusi produk secara kontinu. Model ini melakukan tahap2 yang sudah sangat baik didefinisikan pada model waterfall dan ditambah dengan iterasi yang menyebabkan model ini lebih realistis untuk merefleksikan dunia nyata. 
• Software engineers bisa bekerja lebih cepat pada proyek.

Kelemahan Spiral

• Membutuhkan waktu yang lama dan dana yang besar.
• Membutuhkan planning jangka panjang yang baik agar program bisa selesai dengan baik.

Kekurangannya ada pada masalah pemikiran user / customer dimana mereka pada umumnya tidak yakin bahwa pendekatan evolusioner ini dapat terus dalam ambang kontrol yang bagus. Dibutuhkan kombinasi kemampuan manajerial dan teknis tersendiri untuk mengontrol model ini sehingga dengan sendirinya dapat meyakinkan user / customer tersebut. Mengenai analisis resiko yang terdapat pada model ini dibutuhkan kemampuan expert tersendiri agar tahap ini dapat berjalan dengan baik. Dibutuhkan kemampuan manajemen yang tinggi untuk melakukan perkiraan resiko, karena jika ada resiko yang luput untuk dievaluasi, dikhawatirkan dapat muncul di kemudian hari yang dapat menghambat proses SE.

Model Incremental

Model proses ini hampir sama dengan model proses Waterfall. Bedanya adalah model proses ini dilakukan secara bertahap dan tahap pengerjaan dilakukan permodul. Bisa dikatakan Incremental adalah bentuk pengulangan secara bertahap dari Waterfall. Model ini mengaplikasikan urutan-urutan linier secara bertingkat selaras dengan berjalannya waktu. Setiap urutan linier menghasilkan penambahan (increment) pada software yang dikirimkan. Proses model ini menfokuskan pada pengiriman produk operasional pada setiap penambahannya. Produk awal adalah versi rendah dari produk akhir namun telah mampu mengakomodir kebutuhan pengguna.

Apabila aliran proses dari Communication sampai Deployment telah selesai pada tahap pertama, maka dilanjutkan pada pengerjaan tahap kedua yang aliran prosesnya sama yaitu dari Communication sampai Deployment. Proses ini berlangsung berulang-ulang secara bertahap sampai tahap final. Tahap pertama adalah tahap yang penting karena tahap pertama merupakan tahap kunci dan produk perdana dalam pengembangan karena apabila produk pada tahap pertama gagal, maka tahap selanjutnya tidak akan berjalan. Tahap pertama sering disebut dengan Core Product.

Kelebihan Incremental

• penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dan dapat menurunkan biaya yang dikeluarkan untuk memperbaiki sistem.

Kelemahan Incremental

• Hanya akan berhasil jika tidak ada staffing untuk penerapan secara w menyeluruh
• Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut

Model RAD (Rapid Application Development)

Model proses ini merupakan pembangan dari model Incremental. Sama seperti Incremental tetapi waktu pengerjaan antara siklus pengembangannya berjalan secara singkat. Model RAD merupakan adaptasi High-speed dari model waterfall yang pengembangannya dilakukan dengan menggunakan pendekatan component-based. Maksud dari component-based pada RAD ini adalah agar proses pengerjaannya dapat dipercepat dengan cara membagi program menjadi bagian-bagian terkecil yang tiap bagian tersebut ada tim tersendiri yang bertanggung jawab.

Untuk proses skala besar, RAD Model membutuhkan SDM yang memadai untuk membentuk tim-tim yang diperlukan agar tahap pengerjaan berjalan dengan cepat. RAD Model ini tidak cocok dipakai pada pengerjaan proyek yang memiliki tingkat resiko teknikal yang tinggi. Hal ini bisa terjadi pada saat aplikasi baru menggunakan teknologi baru atau pada saat software yang baru memerlukan derajat kebergantungan yang tinggi terhadap program komputer yang sudah ada. RAD juga memerlukan pengembang dan pelanggan yang komitmen terhadap aktifitas yang ketat sesuai dengan time frame yang diberikan.

Model RAD menekankan pada fase-fase berikut :

1. Business modeling. Pada tahap ini, aliran informasi (information flow) pada fungsi-fungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses bisnis, informasi apa yang hasilkan, siapa yang membuat informasi itu, kemana saja informasi mengalir, dan siapa yang mengolahnya.

2. Data modeling. Aliran informasi yang didefinisikan dari business modeling, disaring lagi agar bisa dijadikan bagian-bagian dari objek data yang dibutuhkan untuk mendukung bisnis tersebut. Karakteristik (atribut) setiap objek ditentukan beserta relasi antar objeknya.

3. Process modeling. Objek-objek data yang didefinisikan sebelumnya diubah agar bisa menghasilkan aliran informasi untuk diimplementasikan menjadi funsi bisnis. Pengolahan deskripsi dibuat untuk menambah, merubah, menghapus, atau mengambil kembali objek data.

4. Application generation. RAD bekerja dengan menggunakan fourth generation techniques (4GT). Sehingga pada tahap ini sangat jarang digunakan pemrograman konvensional menggunakan bahasa pemrograman generasi ketiga (third generation programming languages), tetapi lebih ditekankan pada reuse komponen-komponen (jika ada) atau membuat komponen baru (jika perlu). Dalam semua kasus, alat bantu untuk otomatisasi digunakan untuk memfasilitasi pembuatan perangkat lunak.

5. Testing and turnover. Karena menekankan pada penggunaan kembali komponen yang telah ada (reuse), sebagian komponen-komponen tersebut sudah diuji sebelumnya. Sehingga mengurangi waktu testing secara keseluruhan. Kecuali untuk komponen-komponen baru.

Kelebihan RAD :

• RAD memang lebih cepat dari Waterfall. jika kebutuhan dan batasan project sudah diketahui dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.

Kekurangan RAD :

• Tidak semua project bisa dipecah (dimodularisasi), sehingga belum tentu RAD dipakai pada semua proyek.
• Karena project dipecah menjadi beberapa bagian, maka dibutuhkan banyak orang untuk membentuk suatu tim yang mengerjakan tiap bagian tersebut.
• Membutuhkan komitmen antara pengembang dengan pelanggan.
• Karena dibuat dengan reuse komponen-komponen yang sudah ada, fasilitas-fasilitas pada tiap komponen belum tentu digunakan seluruhnya oleh program yang me-reuse-nya sehingga kualitas program bisa menurun.

Model CBSE (Component Based Software Engineering)

Model CBSE adalah proses yang menekankan perancangan dan pembangunan software dengan menggunakan komponen software yang sudah ada. Model ini bersifat iteratif atau berulang-ulang prosesnya. Tahapan CBSE terdiri dari dua bagian yang terjadi secara paralel yaitu :

1. Software engineering (component-based development)

Component based development sangat berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi objek, banyak class yang dibangun dan menjadi komponen dalam suatu software. Class-class tersebut bersifat reusable artinya bisa digunakan kembali. Penggunaan kembali komponen software yang sudah ada menguntungkan dari segi :

• Siklus waktu pengembangan software, karena mampu mengurangi waktu 70%
• Biaya produksi berkurang sampai 84% karena pembangunan komponen berkurang

Hal-hal yang dilakukan pada tahap software engineering (component-based development) adalah :

• Melakukan analisis terhadap domain model yang sudah ditetapkan
• Menentukan spesifikasi dan merancang berdasarkan model struktur dan spesifikasi sistem.
• Melakukan pembangunan software dengan menggunakan komponen-komponen yang sudah ditetapkan berdasarkan analisis dan rancangan yang dihasilkan sebelumnya hingga akhirnya menghasilkan software.

2. Domain engineering

Hal-hal yang dilakukan pada tahapan domain engineering:

• Menciptakan model domain bagi aplikasi yang akan digunakan untuk menganalisis kebutuhan pengguna.
• Identifikasi, pembangunan, pengelompokan dan pengalokasikan komponen-komponen software supaya bisa digunakan pada sistem yang ada dan yang akan datang.

Model Rational Unified Process (RUP)

Rational Unified Process (RUP) merupakan suatu pendekatan disiplin dalam mengerjakan tugas dan tanggung jawab melalui berbagai best practise di dalam suatu organisasi pengembangan pengembangan perangkat lunak. Tujuan dari RUP adalah untuk memastikan dihasilkannya produk perangkat lunak dengan kualitas yang tinggi (minim error dan berjalan sesuai yang diharapkan), serta memenuhi semua kebutuhan stakeholder dengan biaya dan waktu yang sudah diprediksikan. menunjukkan secara keseluruhan kerangka kerja (framework) yang dimiliki RUP

RUP menggunakan konsep object oriented dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan unified model language (UML). UML adalah bahasa standar untuk penulisan blueprint perangkat lunak. Model ini membagi suatu sistem aplikasi menjadi beberapa komponen sistem dan memungkinkan para developer aplikasi untuk menerapkan metoda iterative (analisis, disain, implementasi dan pengujian) pada tiap komponen. dapat dilihat bahwa RUP memiliki dua dimensi, yaitu:

1. Dimensi horisontal mewakili aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major milestone yang menandakan akhir fase dan awal dari fase selanjutnya. Setiap fase dapat terdiri dari satu atau beberapa iterasi.

2. Dimensi vertikal mewakili aspek-aspek statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is doing what, how and when.

Tahapan pengembangan perangkat lunak dalam RUP terbagi menjadi 4 fase, sebagai berikut :

1. Inception

merupakan tahap untuk mengidentifikasi sistem yang akan dikembangkan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup analisis sistem eksisting, perumusan sistem target, penentuan arsitektur global target, identifikasi kebutuhan, perumusan persyaratan (fungsional, performansi, keamanan, GUI, dll.), perumusan kebutuhan pengujian (level unit, integrasi, sistem, performansi, fungsionalitas, keamanan, dll.), pemodelan diagram UML (diagram use case dan activity), dan pembuatan dokumentasi.

2. Elaboration

merupakan tahap untuk melakukan disain secara lengkap berdasarkan hasil analisis di tahap inception. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pembuatan disain arsitektur subsistem (architecture pattern), disain komponen sistem, disain format data (protokol komunikasi), disain database, disain antarmuka/tampilan, disain peta aliran tampilan, penentuan design pattern yang digunakan, pemodelan diagram UML (diagram sequence, class, component, deployment, dll.), dan pembuatan dokumentasi.

3. Construction

merupakan tahap untuk mengimplementasikan hasil disain dan melakukan pengujian hasil implementasi. Pada tahap awal construction, ada baiknya dilakukan pemeriksaan ulang hasil analisis dan disain, terutama disain pada domain perilaku (diagram sequence) dan domain struktural (diagram class, component, deployment). Apabila disain yang dibuat telah sesuai dengan analisis sistem, maka implementasi dengan bahasa pemrogramanan tertentu dapat dilakukan. Aktivitas yang dilakukan pada tahap ini antara lain mencakup pengujian hasil analisis dan disain (misal menggunakan Class Responsibility Collaborator untuk kasus pemrograman berorientasi obyek), pendataan kebutuhan implementasi lengkap (berpedoman pada identifikasi kebutuhan di tahap analisis), penentuan coding pattern yang digunakan, pembuatan program, pengujian, optimasi program, pendataan berbagai kemungkinan pengembangan / perbaikan lebih lanjut, dan pembuatan dokumentasi.

4. Transition

merupakan tahap untuk menyerahkan sistem aplikasi ke konsumen (roll-out), yang umumnya mencakup pelaksanaan pelatihan kepada pengguna dan testing beta aplikasi terhadap ekspetasi pengguna.

Sekian artikel tentang Model-Model Proses Siklus Rekayasa Perangkat Lunak (SDLC). Semoga bermanfaat.

Daftar Pustaka

• Software Engineering, Ian Sommerville
• Software Engineering, Roger S.Pressman