BAB II
PEMODELAN PROSES PERANGKAT LUNAK A. Pendahuluan
Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini
akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.
Rekayasa perangkat lunak adalah sebuah disiplin yang mengintegrasikan proses,metode,dan alat-alat bantu bagi perkembangan proses perangkat lunak komputer.
Proses perangkat lunak telah menjadi perhatian yang serius selama dekade terakhir.Tetapi apakah sebenarnya proses perangkat lunak itu?Di dalam pembahasan ini,kita mendefinisikan proses perangkat lunak sebagai sebuah kerangka kerja untuk tugas-tugas yang dibutuhkan untuk membangun perangkat lunak dengan kualitas yang tinggi.Proses perangkat lunak menentukan pendekatan yang digunakan ketika perangkat
lunak dikembangkan,tetapi pengembangan perangkat lunak juga meliputi teknologi yang
mempopulasikan proses,metode teknis,serta alat-alat otomatis.
Lebih penting lagi ,pengembangan perangkat lunak dilakukan oleh orang-orang terpelajar yang kreatif yang bekerja di dalam sebuah proses perangkat lunak yang dewasa & terbatas.
Ratusan penulis telah mengembangkan definisi pengembangan perangkat lunak secara personal, namun definisi yang diusulkan oleh Fritz Bauer [NAU69] pada konferensi seminar masalah ini masih menjadi dasar dari diskusi:
[Rekayasa Perangkat Lunak adalah] Pengembangan dan penggunaan prinsip pengembangan suara untuk memperoleh perangkat lunak secara ekonomis yang reliabel dan bekerja secara efisien pada mesin nyata.
B. Proses Perangkat Lunak
Sebuah kerangka kerja proses umum dibangun dengan mendefinisikan sejumlah kecil aktivitas kerangka kerja yang bisa diaplikasikan ke semua proyek perangkat
lunak,tanpa melihat ukuran atau kompleksitasnya.Sejumlah task set-tiap koleksi rekayasa
perangkat lunak mengerjaka tugas-tugas,tonggak proyek,hasil usaha perangkat lunak dan bisa dipesan,serta titik jaminan kualitas memungkinkan aktivitas kerangka kerja disesuaikan dengan karakteristik proyek perangkat lunak dan kebutuhan tim proyek. Akhirnya,aktivitas pelindung seperti jaminan kualitas perangkat lunak,manajemen konfigurasi perangkat lunak lampiran model.Aktivitas pelindung tidak tergantung pada satupun aktivitas kerangka kerja dan terjadi pada seluruh proses.
Pendekatan SEI memberikan sebuah pengukuran terhadap efektivitas global dari sebuah praktek perekayasaan perangkat lunak perusahaan dan membangun lima tingkat kematangan proses,yang didefinisikan dengan cara berikur ini:
Level 1. Initial-Proses perangkat lunak yang ditandai sebagai ad hoc ,dan bahkan kadang-kadang bersifat kacau(chaotic).
Level 2. Repeatable Proses Perangkat Lunak. Proses-proses manajemen proyek dasa dibangun untuk menelusuri masalah biaya,jadual,dan fungsionalitas.Disiplin pross yang perlu ada untuk mengulangi sukses-sukses proyek yang terdahulu dengan penerapan yang sama.
Level 3. Defined-Proses perangkat lunak, untuk aktivitas manajemen atau perekayasaan didokumentasikan, distandarkan, dan diintegrasikan ke dalam proses perangkat lunak morganisasi besar.Semua proyek menggunakan versi proses organisasi yang didokumentasikan dan disahkan untuk pengembangan dan pemeliharaan perangkat lunak.Tingkat ini menyangkut semua ciri yang didefinisika pada tingkat 3.
Level 4. Managed Proses perangkat lunak. Pengukuran detail terhadap proses perangkat lunak dan kualitas produksi dikumpulkan.Produk dan proses perangkat lunak dipahami secara kuantitatif dan dikontrol dengan menggunakan pengukuran secara detail.Tingkat ini ntermasuk semua karakteristik yang didefinisikan pada tingkat 3.
Level 5. Optimzing perangkat lunak. Pertambahan proses yang terus menerus dimungkinkan oleh umpan balik kuantitatif dari proses dan dari gagasan inovatif pengujian serta teknologi.Tingkat ini termasuk semua ciri yang didefinisikan pada tingkat 4.
Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.
Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas.
Seperti produk, proses juga memiliki atribut dan karakteristik seperti :
Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.
Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.
C. Model-Model Proses Perangkat Lunak
Model proses untuk rekayasa perangkat lunak dipilih berdasarkan sifat aplikasi dan proyeknya,metode dan alat-alat bantu yang akan dipakai dan kontrol serta penyampaian yang dibutuhkan.
C.1. Model Sekuensial Linier
Menggambarkan sekuensial linier untuk rekayasa perangkat lunak yang sering
disebut juga dengan “siklus kehidupan klasik”atau”model air terjun”
Gambar Fase Lingkaran pemecahan masalah[RAC95] Definisi
masalah
Definisi masalah
Penyatuan solusi
Penyatuan solusi
Pengembang an teknis
Pengembang an teknis
Status quo
Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analis,desain,kode,pengujian,model sekuensial linier melingkupi aktivitas-aktivitas sebagai berikut:
Rekayasa dan pemodelan sistem/informasi.Karena perangkat lunak selalu merupakan bagian dari sebuah sistem(bisbis)yang lebih besar,kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari klebutuhan ke perangkat lunak tersebut.Pandangan sistem ini penting ketika perangkat lunak harus berhubungan dengan elemen-elemen yang lain seperti perangkat lunak,manusia,dan database.Rekayasa dan analisis sistem menyangkut pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
Anlisis kebutuhan perangkat lunak.Proses pengumpulan kebutuhan diinfestasikan dan difokuskan,khususnya pada perangkat lunak.Untuk memahami sifat program yang dibangun,perekayasa perangkat lunak(analis)harus memahami domain informasi,tingkah laku,unjuk kerja,dan antar muka(interface)yang diperlukan.Kebutuhan baik untuk sistem maupun perangkat lunak didokumentasikan dan dilihat lagi dengan pelanggan.
Desain.Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda;struktur data,arsitektur perangkat lunak,representasi interface,dan detail(algoritma)prosedural.Proses desain menerjemahkan syarat/kebutuhan kedalam sebuah representasi perangkat lunak yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode.Sebagaimana persyaratan,desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak.
Generasi kode.Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca.Langkah pembuatan kode melakukan tugas ini.Jika desain dilakukan dengan cara yang lengkap,pembuatan kode dapat diselesaikan dengan mekanis.
Pengujian.Sekali kode dibuat,pengujian program dimulai.Proses pengujian berfokus pada logika internal perangkat lunak,memastikan bahwa semua pernyataan telah diuji,dan pada eksternal fungsional—yaitu mengarahkan pengujian untuk menemukan kesalahan-kesalahan dan memastikan bahwainput yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.
Pemeliharaan.Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan(perkecualian yang mungkin adalah perangkat lunak yang
desain
desain kodekode testes
GambarModel sekuensial linier analisis
direkatkan).Perubahan akan terjadi karena kesalahan-kesalahan ditentukan,karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan di dalam lingkungan eksternalnya.
Contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru.
C. 2. Model Prototipe
Prototyping paradigma dimulai dengan pengumpulan kebutuhan.
Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk
mengidentifikasi kebutuhan perangkat lunak.
Bila prototipe sedang bekerja atau dibangun,pengembang harus mempergunakan
fragmen-fragmen yang ada atau mengaplikasikan alat-alat bantu
Contohnya:report generator,window manager,dll yang memungkinkan program
yang bekerja untuk dimunculkan cecara cepat.
Prototipe bisa berfungsi sebagai “sistem pertama”
Prototipe bisa juga menjadi masalah karena alasan-alasan sebagai berikut:
1. Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa melihat bahwa prototipe itu dijalankan bersama-sama tanpa melihat bahwa didalam permintaan untuk membjuatnya bekerja.
2. Pengembang sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat.Sistem operasi atau bahasa pemrograman yang tidak sesuai bisa dipakai secara sederhana karena mungkin diperoleh da dikenal .
Prototyping dipakai bila ditemui kondisi • Definisi user bersifat umum
• user tidak tahu pasti apa yang diinginkan • definisi user bersifat tidak rinci
• user tidak tahu pasti apa & bagaimana bentuk – masukan
– proses – keluaran
• pengembang merasa tidak tahu pasti tentang – pilihan algoritma yang akan dipakai
– bagaimana lingkungan sistem yang akan dikembangkan – bentuk, sifat & karakteristik antar-muka pemakai
• Terdapat ketidak pastian dipihak user yaitu tentang apa diinginkan
• Terdapat ketidak pastian dipihak pengembang yaitu tentangapa yang harus dilakukan
Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “system fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira dalam waktu 60 – 90 hari).
Pendekatan RAD melingkupi fase – fase sebagai berikut :
Bussines modeling.
Aliran informasi diantara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkan? Kemana informasi itu pergi? Siapa yang memprosesnya?
Data modeling.
Aliran informasi yang didefinisikan sebagai bagian dari fase Bussines modeling disaring kedalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisakan .
Process modeling.
Aliran informasi yang didefinisikan didalam fase data modeling ditrnsformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.
Aplication generation.
RAD mengasumsikan pemakaian teknik generasi ke-empat (dalam pembahasan selanjutnya). Selain menghasilkan perangkat lunak dengan menggunakan bahasa pemrograman generasi ke-tiga yang konvensional, RAD lebih banyak memproses kerja untuk memakai lagi komponen program yang ada (pada saat memunkinkan) atau menciptakan komponen yang biasa dipakai lagi (bila perlu). Pada semua kasus, alat – alat Bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
Testing and turnover.
Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian . Tetapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.
Berikut kekurangan yang dimiliki RAD:
Bagi proyek yang besar tapi berskala, RAD memerlukan SDM yang memadai, untuk
menciptakan jumlah tim RAD yang baik.
RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktifitas
rapid-fire yang diperlukan untuk melengkapi sebuah system, didalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada dari tiap konstituen, proyek RAD akan gagal.
Tidak semua aplikasi sesuai untuk RAD. Bila system tidak dapat dimodulasikan
Gambar Model RAD
Dari gambar diatas, secara jelas batasan waktu yang dibebankan pada sebuah proyek RAD memerlukan “ruang lingkup yang bias diskala”. Jika sebuah aplikasi bisnis dapat dimodulkan dengan cara tertentu sehingga memungkinkan setiap fungsi mayor untuk dilengkapi dalam waktu kurang dari 3 bulan (dengan menggunakan pendekatan yang digambarkan diatas),maka aplikasi itu merupakan kandidat bagi RAD. Masing – masing fungsi mayor bias dibicarakan oleh suatu tim RAD yang terpisah, dan kemudian diintegrasikan untuk membentuk suatu keadaan.
C. 4. Model Proses Perangkat Lunak Evolusioner
Model evolusioner adalah model interatif. Model itu ditandai dengan tingkah laku yang memungkinkan perekayasa perangkat lunak yang lebih lengkap sedikit demi sedikit.
C.5. Model Pertambahan
Pemodelan bisnis
Pemodelan bisnis
Pemodelan bisnis
Pemodelan bisnis
Pemodelan bisnis
Pemodelan bisnis
Pemodelan bisnis Pemodelan
bisnis
Pemodelan bisnis
Pemodelan bisnis Pemodelan bisnis
Pemodelan bisnis Pemodelan bisnis Pemodelan bisnis Pemodelan bisnis
Tim # 1
Tim # 3
Tim # 2
Model Inkremential menggabungkan elemen-elemen model sekuensial linier (diaplikasikan secara berulang) dengan filosofi iteratif. Seperti diperlihatkan dibawah, model pertambahan memakai urutan linier yang membingungkan, seiring dengan laju waktu kalender. Setiap urutan linier menghasilkan pertambahan, perangkat lunak “yang biasa disampaikan”. Pada saat model pertambahan dipergunakan, pertambahan pertama sering merupakan produk inti (care product), yaitu sebuah model pertambahan yang biasa dipergunakan, tetapi beberapa muka tambahan (beberapa diketahui dan beberapa tidak) tetap tidak disampaikan. Rencana pertambahan selanjutnya menekan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsionalitas tambahan. Proses ini diulangi mengikuti penyampaian setiap pertambahan sampai menghasilkan produk yang lengkap.
Perkembangan pertambahan,khususnya berguna pada saat staffing tidak dapat dilakukan dengan menggunakan implementasi lengkap oleh batas waktu bisnis yang sudah disepakati oleh batas waktu tersebut. Jika produk ini diterima maka staff tambahan dapat ditambahkan untuk mengimplementasikan pertambahan selanjutnya. Sebagai tambahan, system mayor yang sedang dalam masa perkembangan serta waktu penyampaian belum pasti, mungkin membutuhkan keberadaan perangkat keras yang baru. Dapat juga membuat rencana tertentu untuk menghindari pemakaian perangkat lunak ini, sehingga memungkinkan fungsionalitas partai disampaikan kepada pemakai tanpa harus banyak tertunda.
Model Inkramental
C.6. Model Spiral
Model spiral yang pada awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak yang evolusioner yang merngkai sifat iterative dari prototype dengan cara control dan aspek sistematisdari model sekuensial linier. Dalam model spiral, perangkat lunak dikembangkan dalam suatu penambahan.
Inkrement 2
Rekayasa system informasi
analisi s
tes kode
desain
analisi s
tes kode
desain
analisi
s desain kode tes
analisi s
tes kode
desain Inkrement 1
Pengiriman increment ke - 1
Inkrement 3
Inkrement 4
Pengiriman increment ke - 1 Pengiriman
increment ke - 1
Pengiriman increment ke - 1
Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah luas, diantara tiga sampai enam wilayah luas :
Komunikasi pelanggan : tugas – tugas yang dibutuhkan untuk membangun komunikas yang efektif diantara pengembangan dan pelanggan.
Perencanaan : tugas – tugas yang dibutuhkan untuk mendefinisikan sumber daya,
ketepatan waktu, dll.
Analisis resiko : tugas yang dibutuhkan untuk menaksir resiko2, baik manajemen
maupun teknis.
Perekayasaan : tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
Konstruksi dan peluncuran : tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (install), dan memberi pelayanan kepada pemakai.
Evaluasi pelanggan : tugas yang dibutuhkan untuk memperoleh umpan balik dari
pelanggan.
Model spiral menjadi sebuah pendekatan yang realistis bagiperkembangan system dan perangkat lunak skala besar.karena perangkat lunak terus bekerja selama proses bergerak, pengembangan dan pemakai memahami dam bereaksi lebih baik terhadap resiko terhadap setiap evolusi. Tetapi model spiral bukanlah sebuah obat yang mujarab ,karena mode spiral membutuhkan keahlian penaksiran resiko yang masuk akal dan sangat bertumpu untuk mencapai keberhasilan.
C.7. Model Rakitan Komponen
Model rakitan komponen menggabungkan karakteristik model spiral. Model ini bersifat evolusioner sehingga membutuhkan pendekatan iterative untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan (biasa disebut “kelas”). Kelas2 yang diciptakan dalam proyek perangkat lunak disimpan didalam pustaka kelas atau tempat penyimpanan. Model rakitan komponen membawa kepada pengguna kembali perangkat lunak, dan kegunaan kembali tersebut memberi sejumlah keuntungan yang bias diukur pada rekayasa perangkat lunak.
C.8. Model Perkembangan Konkuren
Elemen model proses konkuren
C. 9. Model Formal
Metode formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak computer. Metode ini mmemungkinkan perekayasa untuk mengkhususkan, mengembangkan, dan memverifikasi system berbasis computer dengan menggunakan system matematis yang tepat. Variasi dalam pendekatan ini disebut juga clean-room rekayasa perangkat lunak..
Meskipun belum menjadi pendekatan utama, metode ini sudah dapat menjanjikan perangkat lunak yang bebas dari cacat / kesalahan, tetapi perhatian tentang kemampuan aplikasinya sudah mulai disuarakan :
1. Pengembangan model format banyak memakan waktu dan mahal. 2. Perlu latihan yang ekstensif.
3. Sulit untuk menggunakan model2 sebagai sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih.
Meskipun demikian , sepertinya metode ini akan banyak penganutnya diantara pengembangan perangkat lunak yang harus membangun perangkat lunak yang kritis untuk keselamatan (misal perangkat medis, dan penerbangan pesawat), serta diantara pengembangan yang harus menderita karena factor ekonomis yang harus dialami oleh perangkat lunak.
Sedang dalam pengembangan
Tidak ada
Menunggu perubahan Sedang dalam
pemeriksaan
Sedang dalam revisi
baseline
dikerjakan
C.10. Teknik Generasi Keempat
Bentuk ini mencakup serangkaian Bantu perangkat lunak yang luas yang secara umum memiliki satu hal; masing – masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa karakteristik perangkat lunak pada suatu tingkat yang tinggi. Alat – alat Bantu tersebut yang kemudian secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasa.
Seperti semua paradigma rekayasa perangkat lunak yang lain, model ini juga memiliki keuntungan dan kerugian. Orang sepaham mempermasalahkan penghematan waktu, serta produktivitas yang dikembangkan secara baik oleh perekayasa perangkat lunak. Kelompok yang berlawanan mempermasalahkan alat Bantu yang tidak lebih mudah digunakan dari bahasa pemrograman, serta kemampuan pemeliharaan perangkat lunak yang dikembangkan masih mengandung pertanyaan.
Ada beberapa sisi baik dari kedua sisi permasalahan diatas :
1. kegunaan metode ini telah disebarkan selama dekade terakhir dan sekarang merupakan pendekatan yang masih berjalan terus bagi area aplikasi yang berbeda. 2. data yang dikumpulkan perusahaan – yang menggunakan metode ini
menunjukkan bahwa waktu yang dibutuhkan untuk menghasilkan perangkat lunak sangat berkurang untuk aplikasi kecil dan menengah, serta jumlah desain analisis bagi aplikasi kecil juga berkurang.
3. tetapi kegunaannya untuk pengembangan perangkat lunak yang besar membutuhkan analisis, desain dan pengujian yang sangat banyak(aktivitas RPL) untuk memperoleh penghematam waktu.
Kesimpulannya, teknik ini telah menjadi bagian yang penting dari perkembangan perangkat lunak. Bila dirangkai dengan pendekatan rakitan komponen, paradigma metode ini dapat menjadi pendekatan yang dominant untuk pengembangan perangkat lunak.
