Proses-proses Perangkat Lunak Materi 2 Rekayasa Perangkat Lunak Ir. S. Waniwatining astuti, m.t.i

Tujuan Memahami konsep proses perangkat lunak dan model proses perangkat lunak Memahami berbagai model proses dan kapan model-model tersebut digunakan Mengerti secara garis besar, tentang model proses untuk rekayasa persyaratan perangkat lunak,pengembangan, pengujian, dan evolusi perangkat lunak Mengetahui teknologi CASE sebagai penunjang proses perangkat lunak.

Kegiatan-kegiatan mendasar yang umum bagi semua proses perangkat lunak : Penspesifikasian perangkat lunak Fungsi dan batasan operasinya harus didefinisikan. Perancangan dan implementasi perangkat lunak Perangkat lunak yang memenuhi persyaratan harus dibuat. Pemvalidasian perangkat lunak Harus dilakukan validasi untuk menjamin bahwa perangkat lunak bekerja sesuai apa yang diinginkan pelanggan. Pengevolusian perangkat lunak Perangkat lunak harus dapat berkembang untuk menghadapi kebutuhan pelanggan yang berubah.

I. Model proses Perangkat Lunak Model proses perangkat lunak merupakan representasi abstrak dari proses perangkat lunak Setiap model proses merepresentasikan proses dari sudut pandang tertentu sehingga hanya memberikan informasi parsial mengenai proses tersebut. Proses-proses yang berbeda digunakan untuk mengembangkan bagian yang berbeda pada sistem

1. Model Air Terjun (waterfall) Model ini mengambil kegiatan proses dasar seperti spesifikasi, pengembangan, validasi dan evolusi, dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian, dan seterusnya.

Model Waterfall atau Software Lifecycle Definisi persyaratan Perancangan sistem dan perangkat lunak Implementasi dan pengujian sistem Integrasi dan pengujian sistem Operasi dan pemeliharaan

Fase berikutnya tidak boleh dimulai sebelum fase sebelumnya selesai. Hasil dari setiap fase merupakan satu atau lebih dokumen yang disetujui. Fase berikutnya tidak boleh dimulai sebelum fase sebelumnya selesai. Masalah dengan model waterfall ini adalah terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel. Komitmen harus dilakukan pada tahap awal proses, dan akan sulit untuk menanggapi perubahan persyaratan pelanggan. Model waterfall harus digunakan hanya ketika persyaratan dipahami dengan baik.

2. Pengembangan Evolusioner Terdapat 2 jenis pengembangan evolusioner : Pengembangan Eksploratori Tujuan proses ini adalah bekerja dengan pelanggan untuk menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Pengembangan dimulai dengan bagian-bagian sistem yang dipahami. Sistem berubah dengan adanya tambahan fitur-fitur baru sesuai usulan pelanggan.

B. Prototipe yang dapat dibuang (throw – away) Tujuan pengembangan evolusioner adalah untuk memahami persyaratan pelanggan dan dengan demikian mengembangkan definisi persyaratan yang lebih baik untuk sistem. Prototipe berkonsentrasi pada eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik Pendekatan evolusioner seringkali lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang memenuhi kebutuhan langsung pelanggan.

Model Pengembangan Evolusioner Kegiatan –kegiatan Yang bersamaan Spesifikasi Versi Awal Penjelasan Garis Besar Pengembangan Versi Menengah Validasi Versi Akhir

Keunggulan dan masalah Spesifikasi dapat dikembangkan secara inkremental User mendapat pemahaman yang lebih baik dari masalah mereka , dan sistem perangkat lunak dapat merefleksikannya. Masalah Proses tidak bisa dilihat Sistem seringkali memiliki struktur yang buruk Kemungkinan diperlukan alat bantu dan teknik khusus

3. Pengembangan Sistem Formal Pengembangan sistem formal merupakan pendekatan terhadap pengembangan perangkat lunak yang memiliki kesamaan dengan model waterfall, tetapi proses pengembangannya didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalanakan. Definisi persyaratan Spesifikasi formal Transformasi formal Integrasi dan pengujian sistem

Perbedaan dengan model waterfall Spesifikasi persyaratan perangkat lunak diperbaiki menjadi spesifikasi formal yang rinci yang dinyatakan dalam motasi matematis. Proses pengembangan perancangan, implementasi dan pengujian unit digantikan oleh proses pengembangan transformasional dimana spesifikasi formal diperbaiki melalui serangkaian transformasi menjadi program.

4. Pengembangan berorientasi pemakaian ulang Perancangan sistem dengan pemakaian ulang Spesifikasi persyaratan Analisis komponen Modifikasi persyaratan Pengembangan dan iterasi Validasi sistem

Perbedaan tahap dengan model lain : Analisis komponen Jika diketahui spesifikasi persyaratan, komponen-komponen untuk implementasi spesifikasi tersebut akan dicari. Modifikasi persyaratan Pada tahap ini, persyaratan dianalisis dengan menggunakan informasi mengenai komponen yang telah didapat. Persyaratan kemudian dimodifikasi untuk merefleksikan komponen yang tersedia. Perancangan sistem dengan pemakaian ulang Kerangka kerja sistem dirancang, atau kerangka kerja yang telah ada dipakai ulang Pengembangan dan iterasi Perangkat lunak yang tidak dapat dibeli akan dikembangkan.

II. Iterasi Proses Pekerjaan perancangan dan implementasi sistem harus dilakukan ulang untuk implementasi persyaratan yang diubah. Untuk mendukung pendekatan yang berbeda terhadap pengembangan dan telah secara eksplisit dirancang untuk mendukung iterasi proses. Model-model tersebut adalah : Pengembangan inkremental, dimana spesifikasi, perancangan dan implementasi perangkat lunak dibagi menjadi serangkaian inkremen yang dikembangkan secara bergantian. Pengembangan spiral, dimana pengembangan sistem seolah beralur membentuk spiral keluar dari garis awal sampai sistem pengembangan akhir.

Model pengambangan inkremental Definisikan persyaratan garis besar Terapkan persyaratan ke inkremen Rancang arsitektur sistem Kembangkan pembagian sistem Validasi inkremen Integrasikan inkremen Validasi sistem Sistem akhir Sistem tidak lengkap

Keuntungan proses pengembangan inkremental Pelanggan tidak perlu menunggu sampe seluruh sistem dikirimkan untuk mengambil keuntungan dari sistem tersebut. Inkremen yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan. Pelanggan dapat memakai inkremen yang pertama sebagai bentuk prototipe dan mendapat pengalaman yang dapat menginformasikan persyaratan untuk inkremen sistem berikutnya. Risiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah dapat ditemukan pada beberapa inkremen, bisa saja beberapa inkremen diserahkan dengan sukses kepada pelanggan. Karena layanan dengan prioritas tertinggi diserahkan pertama dan inkremen berikutnya diintegrasikan, maka layanan sistem yang paling penting mengalami pengujian yang paling ketat.

Masalah yang ditemukan : Inkremen harus relatif kecil ( < 20.000 baris code) dan setiap inkremen harus menyediakan sebagian dari fungsionalitas sistem. Akan terjadi kesulitan untuk memetakan persyaratan pelanggan pada inkremen dengan ukuran yang benar. Sebagian sistem membutuhkan serangkaian fasilitas dasar yang dipakai oleh inkremen lain pada sistem. Persyaratan tidak didefinisikan dengan rinci sampai sebuah inkremen akan diimplementasikan, sangatlah sulit untuk mengidentifikasi fasilitas umum yang dibutuhkan semua inkremen.

2. Pengembangan Spiral Setiap untai pada spiral merepresentasikan fase proses perangkat lunak. Untai paling dalam berkenaan dengan kelayakan sistem, untai berikutnya dengan definisi persyaratan sistem, dan untai berikutnya lagi dengan perancangan sistem, demikian seterusnya.

Setiap untai pada spiral dibagi menjadi 4 sektor : Penentuan tujuan tujuan yang spesifik untuk fase proyek didefinisikan. Batasan proyek Identifikasi produk Rencana manajemen secara rinci Identifikasi risiko proyek Strategi alternatif berdasarkan identifikasi risiko proyek.

2. Penilaian dan pengurangan Risiko Untuk setiap risiko proyek yang diidentifikasi, dilakukan analisis yang rinci. Dilakukan langkah-langkah yang rinci untuk mengurangi risiko tersebut. Sebagai contoh, jika ada risiko bahwa persyaratan tidak sesuai, mungkin diperlukan pengembangan sistem prototipe.

3. Pengembangan dan Validasi setelah evaluasi risiko, model pengembangan untuk sistem kemudian dipilih. 4. Perencanaan proyek ditinjau dan selanjutnya dibuat keputusan apakah akan diteruskan dengan untai spiral berikutnya. Jika diputuskan untuk terus, maka dibuat rencana untuk fase proyek berikutnya.

3. Spesifikasi Perangkat Lunak (rekayasa persyaratan) Bertujuan untuk menetapkan layanan apa yang dituntut dari sistem dan batasan pada operasi dan pengembangan sistem. Spesifikasi perangkat lunak merupakan tahap yang sangat kritis dari proses perangkat lunak karena kesalahan pada tahap ini pada akhirnya menimbulkan masalah lain pada perancangan dan implementasi sistem.

Model proses spesifikasi perangkat lunak Studi Kelayakan Elisitasi dan analisis persyaratan Spesifikasi persyaratan Laporan kelayakan Model sistem Validasi persyaratan Persyaratan user dan sistem Dokumen persyaratan

4 fase utama proses rekayasa persyaratan STUDI KELAYAKAN dibuat perkiraan mengenai apakah user yg diidentifikasi puas menggunakan perangkat lunak dan teknologi perangkat keras yang dipakai pada saat ini. hasil studi kelayakan harus menginformasikan keputusan apakah kita akan terus dengan analisis yang lebih rinci, atau tidak. Studi kelayakan seharusnya murah dan cepat,

2. Elisitasi dan analisis persyaratan merupakan proses penurunan persyaratan sistem melalui observasi sistem yang ada, diskusi dengan user yang akan memakai dan yang mengadakan, analisis pekerjaan, dll hasil fase ini akan membantu analis memahami sistem yang akan dispesifikasi.

3. SPESIFIKASI PERSYARATAN kegiatan menerjemahkan informasi yang dikumpulkan pada kegiatan analis menjadi dokumen yang mendefinisikan serangkaian persyaratan. dua jenis persyaratan bisa dicakup pada dokumen ini, yaitu : persyaratan user merupakan pernyataan abstrak persyaratan sistem untuk pelanggan dan end user sistem. Persyaratan sistem merupakan deskripsi yang lebih rinci mengenai fungsionalitas yang akan diberikan.

4. VALIDASI PERSYARATAN Kegiatan ini memeriksa apakah persyaratan dapat direalisasikan, konsisten dan lengkap. Pada proses ini, kesalahan pada dokumen persyaratan pada akhirnya akan ditemukan. Kesalahan kemudian akan dimodifikasi untuk menyelesaikan masalahnya.