RPL PART II

MODEL PROSES PERANGKAT LUNAK

Proses rekayasa perangkat lunak : Serangkaian kegiatan dan hasil yang berhubungan dengannya, yang menuju pada dihasilkannya produk perangkat lunak.

Kegiatan-kegiatan mendasar yg umum bagi semua proses Perangkat Lunak :
1. Spesifikikasi Perangkat Lunak Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan (Perancangan dan Implementasi) Perangkat Lunak Perangkat lunak yang memenuhi spesifikasi harus di produksi
3. Validasi Perangkat Lunak à Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.

Berikut ini adalah contoh model proses pengembangan perangkat lunak : 

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 memenuhi 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 (reuse).Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.

Dalam gambar diatas, proses berada ditengah-tengah sebuah segitiga yang menghubungkan tiga faktor yang sangat besar pengaruhnya terhadap kualitas perangkat lunak dan untuk kerja organisasional. Ketrampilan dan motivasi yang diperlihatkan manusia merupakan satu-satunya faktor yang paling berpengaruh pada kualitas dan untuk kerja tim. Teknologi yang menghuni proses juga berpengaruh. Segitiga proses yang berada dalam lingkaran yang menggambarkan kondisi lingkungan yang menyangkut lingkungan pengembangan, kondisi bisnis dan karakteristik pelanggan.

Mengukur realibilitas proyek perangkat lunak secara tidak langsung yaitu mengambl serangkaian metrik berdasarkan keluaran yang diambil oleh proses. Kelauaran menyangkut pengukuran kesalahan yang ditemukan sebelum pelepasan perangkat lunak, cacat yang disampaikan dan dilaprokan oleh pemakai akhir, produk kerja yang dikirim, usaha manusia yang dilakukan, waktu kalender yang digunakan, konfirmasi jadwal, serta pengukuran yang lain.

Waterfall/Linear Sequential Model
Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Berikut ini ada dua gambaran dari waterfall model. Sekalipun keduanya menggunakan nama-nama fase yang berbeda, namun sama dalam intinya.
Fase-fase dalam Waterfall Model menurut referensi Pressman:

Fase-fase dalam Waterfall Model menurut referensi Pressman:


Fase-fase dalam Waterfall Model menurut referensi Sommerville:


Dimodelkan setelah siklus rekysa konvensional, model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut:
1. Rekayasa dan pemodelan sistem/informasi
Karena sistem merupakan bagian dari sebuah sistem yang lebihbesar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
2. Analisis kebutuhan Software
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.
3. Desain
Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.
4. Generasi Kode
Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
5. Pengujian
Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan
Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yang dilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.

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 Model


KETERANGAN GAMBAR SEBAGAI BERIKUT :

• Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan.
• Element-element 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 detil. 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.

Ada pula masalah-masalah tentang Incremental Model daiantaranya adalah :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.

Contoh Gambar Spiral Model :


Proses digambarkan sebagai spiral. 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 :

• 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.
• Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
• 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, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.
• Planning: Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.

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

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

Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. 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.