MODEL-MODEL PROSES PERANGKAT LUNAK

Pada Rekayasa Perangkat Lunak banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC).

Setiap model yang dikembangkan mempunyai karakteristik sendiri-sendiri namun secara umum ada persamaan dari model-model ini yaitu:

1.    Kebutuhan terhadap defenisi masalah yang jelas.

2.    Tahapan-tahapan pengembangan yang teratur.

3.    Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan.

4.    Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak.

5.    Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis.

 A.WATERFALL MODEL/LINEAR SEQUENTIAL MODEL

Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Fase-fase dalam Waterfall Model menurut referensi Pressman:

1.    Requirements analysis and definition: Mengumpulkan kebutuhan secara lengkap kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.

2.    System and software design: Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.

3.    Implementation and unit testing: desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.

4.    Integration and system testing: Penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).

5.    Operation and maintenance: mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.

Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.

Masalah dengan waterfall :

1.    Perubahan sulit dilakukan karena sifatnya yang kaku.

2.   Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.

3.    Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek.

B. PROTOTYPE MODEL

          Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang secara langsung mendemontrasikan bagaimana sebuah perangkat lunak atau komponen-komponen perangkat lunak akan bekerja dalam lingkungannya sebelum tahapan konstruksi aktual dilakukan. Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detail input, proses atau detail output. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.

1.     pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detail kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan.

2.   perancangan: perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.

3.    Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan.

Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype, membantu mendapatkan kebutuhan detail lebih baik namun demikian prototype juga menimbulkan masalah:

1. dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.
2. developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

Kelemahan prototype model:

• Pelanggan dapat sering mengubah-ubah menambah-tambah spesifikasi kebutuhan karena menganggap aplikasi sudah 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 prototype model:

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

C. MODEL RAPID APLICATION DEVELOPMENT (RAD)

RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini. Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 70 sampai 90 hari.

Kelemahan dalam model ini:

1.    tidak cocok untuk proyek skala besar. Untuk pembuatan sistem perangkat lunak dengan skala besar makan RAD akan memerlukan sumber daya manusia yang cukup besar.

2.    proyek bisa gagal karena waktu yang disepakati tidak dipenuhi. Jika tidak ada persetujuan untuk pengembangan PL secara dengan cepat (Rapid) makan proyek dengan model ini akan gagal.

3.    sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini

4.    resiko teknis yang tinggi juga kurang cocok untuk model ini.

5.    Jika sistem PL yang akan dibuat tidak bisa dimodelkan (dibagi-bagi menjadi beberapa komponen) maka model RAD tidak dapat digunakan.

6.    Model RAD tidak cocok digunakan untuk sistem PL yang memiliki resiko teknis tinggi, misalnya menggunakan teknologi baru yng belum banyak dikenal.

Fase-fase di atas menggambarkan proses dalam model RAD. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan.

1. Business modelling: menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? kebutuhan dari system.
2. Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut.
3. Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untuk menjalankan fungsi-fungsi bisnis.
4. Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan.
5. Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji.

D. V MODEL

V model merupakan pengembangan dari model waterfall. V model merupakan kepanjangan dari Validasi/ Verivikasi Model. V model mendemonstrasikan hubungan antara proses pembangunan sistem (development activities) dan proses pengujian system (testing activities). Berbeda dengan pemodelan lainnya, dalam pemodelan v-model proses pengujian jauh lebih kompleks karena dibagi menjadi beberapa bagian yang lebih detail.

Dalam cabang kiri, miring ke bawah dari V mendefinisikan kebutuhan bisnis, parameter desain aplikasi dan proses desain. Pada titik dasar V, kode ditulis. Dalam cabang kanan, miring ke atas dari V, pengujian dan debugging dilakukan. Unit testing dilakukan pertama, diikuti oleh bottom-up pengujian integrasi. Titik ekstrim kanan atas dari V merupakan rilis produk dan dukungan yang berkelanjutan.

Proses pengembangan sistem meliputi requirement analysis, requirements specification, design specification, dan program specification. Sedangkan dalam proses pengujian meliputi acceptance testing, system testing, integration testing, dan units testing. Diantara develompment activities dan testing activities terdapat proses penulisan kode. Alur tahapan pada v-model:

V Model memiliki beberapa kelebihan. Kelebihan-kelebihan tersebut secara garis besar dapat dijelaskan seperti berikut:

• V Model sangat fleksibel. V Model mendukung penambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah untuk melakukan perbaikan 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 usang.
• V Model dikembangkan dan di-maintain oleh publik. User dari V Model berpartisipasi dalam change control board yang memproses semua change request terhadap V Model.

V Model juga memiliki beberapa kekurangan. Kekurangan-kekurangan tersebut yaitu:

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 activity dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam activity tersebut dan apa yang tidak.

E. EVOLUTIONARY SOFTWARE PROCESS MODELS

Evolutionary Software Process Models Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses. Dua model dalam evolutionary software process model adalah:

1.      INCREMENTAL

Ciri-ciri incremental model adalah:

• 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.
• Kombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan.
• Element-elemen dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.
• Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detail. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan.
• Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
• Mampu mengakomodasi perubahan secara fleksibel.
• Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan 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.

2.      SPIRAL MODEL

            Ciri-ciri spiral model:

1. Mendefinisikan kebutuhan dengan sedetail mungkin.
2. Pembuatan desain untuk sistem yang baru.
3. Proses direpresentasikan dalam aktivitas berbentuk spiral.
4. Setiap perulangan (loop) dalam spiral merepresentasikan sebuah fase dalam proses.
5. Resiko selalu secara transparan dimonitor dan dipecahkan selama proses berlangsung.

Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :

1. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
2. Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap resiko dianalisis secara detail pada sektor ini. Langkah-langkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
3. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis.
4. Planning: Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak.

Pembagian sektor bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:

1. Customer communication: membangun komunikasi yang baik dengan pengguna/customer.
2. Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek.
3. Risk analysis: identifikasi resiko managemen dan teknis
4. Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype.
5. Construction and release: pembangunan, test, install dan support.
6. Customer evaluation: mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.

            Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.

E. RATIONAL UNIFIED PROCESS (RUP)

Unified Process (UP) atau Unified Software Development Process (USDP) adalah kerangka proses pengembangan yang bersifat Use Case Driven berpusat pada arsitektur perangkat lunak, iteratif dan tumbuh kembang. Kerangka pengembangan ini termasuk baru dalam metodologi pengembangan perangkat lunak.

Rational Unified Process menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML). Ada beberapa keuntungan dengan mengunakan RUP di antaranya:

1. Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
2. Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
3. Mendukung proses pengulangan dalam pengembangan software.
4. Memungkinkan adanya penambahan-penambahan pada proses.
5. Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang terjadi pada software selama proses pengembangannya.
6. Memungkinkan untuk menjalankan test case dengan menggunakan Rational Test.

Kekurangan Pengembangan Perangkat Lunak RUP: Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak yang berorientasi objek dengan berfokus pada UML (Unified Modeling Language).

Tahapan Unfied Process:

1) Inception. Tahapan ini merupakan tahapan paling awal dimana aktivitas penilaian terhadap sebuah proyek perangkat lunak dilakukan. Tujuannya adalah untuk mendapatkan kesepakatan dari stakeholder sehubungan dengan tujuan dan dana proyek.

2)  Elaboration. Tujuan dari tahapan ini adalah untuk mendapatkan gambaran umum kebutuhan, persyaratan dan fungsi-fungsi utama perangkat lunak. Hal ini penting untuk mengetahui secara lebih baik resiko-resiko proyek, baik meliputi resiko arsitektur perangkat lunak, perencanaan maupun implementasi. Pada tahap ini telah dimulai rancang bangun perangkat lunak secara iterative melalui aktivitas-aktivitas seperti business modelling, requirement, analysis dan design meskipun baru pada tahap awal.

3)  Construction. Tujuan dari tahapan ini adalah membangun perangkat lunak sampai dengan saat perangkat lunak tersebut siap digunakan. Titik berat tahapan ini pada penentuan tingkat prioritas kebutuhan/persyaratan, melengkapi spesifikasinya, analisis lebih dalam, desain solusi yang memenuhi kebutuhan & persyaratan, pengkodean dan pengujian perangkat lunak. Jika dimungkinkan versi awal dari perangkat lunak diuji cobakan untuk mendapatkan masukan dari user.

4)  Transition. Tahap ini difokuskan pada bagaimana menyampaikan perangkat lunak yang sudah jadi pada pengguna. Perangkat lunak akan secara resmi diuji baik oleh penguji (tester) yang kompeten maupun oleh pengguna. Beberapa aktivitas seperti pemindahan pusat data dan pelatihan pengguna dan staff pendukung harus dilakukan pada tahapan ini.

Dalam pengembangan perangkat lunak dengan menggunakan UP mensyaratkan penggunaan UML. Meskipun UP mensyaratkan penggunaan UML namun UML sendiri dapat digunakan pada berbagai metodologi yang lain. UML adalah bahasa pemodelan standard atau kumpulan teknik-teknik pemodelan untuk menspesifikasi, menvisualisasi dan mendokumentasikan hasil kerja dalam pengembangan perangkat lunak. UML lahir dari penggabungan beberapa bahasa pemodelan grafis berorientasi objek. Secara sederhana UML digunakan untuk menggambarkan sketsa sistem. Pengembang menggunakan UML untuk menyampaikan beberapa aspek dari sebuah perangkat lunak melalui notasi grafis. UML mendefenisikan notasi dan semantik. Notasi merupakan sekumpulan bentuk khusus yang memiliki makna tertentu untuk menggambarkan berbagai diagram piranti lunak. Semantic mendefenisikan bagaimana bentuk-bentuk tersebut dikombinasikan.


REFERENSI
Software Engineering, Roger S. Pressman, Ph.D.