TEKNIK ITERATIF & REKURSIF

TEKNIK ITERATIF
Teknik Iteratif merupakan suatu teknik pembuatan algoritma dengan pemanggilan procedure beberapa kali atau hingga suatu kondisi tertentu terpenuhi
Contoh :
Teknik Iteratif pada algoritma untuk menghitung faktorial dari bilangan bulat positif n, adalah sebagai berikut :
Function FAK (n : integer) : integer
FAK=1
For i = 1 TO n
FAK = FAK * i
NEXT i
END FAK

Misal n = 5, maka : FAK = 1, kemudian
i
FAK
1
1 * 1 = 1
2
1 * 2 = 2
3
2 * 3 = 6
4
6 * 4 = 24
5
24 * 5 = 120

Contoh :
BARISAN BILANGAN FIBBONACI → 1, 1, 2, 3, 5, 8, 13, 21, . . .
Teknik Iteratif pada algoritma untuk menentukan suku ke-n dari barisan bilangan Fibbonaci, adalah sebagai berikut :
1. Set x, y, n, i, f : integer
2. x ← 1 ; y ← 1
3. If n 〉 2 then
begin
4. for i ← 3 to n do
begin
5. F ← x + y
6. x ← y
7. y ← F
end
else
8. F ← x
9. Write(F)
End
Gambaran jalannya proses algoritma tersebut adalah sebagai berikut :
Misal n = 5, maka :
x=1, y=1, kemudian
i
F
x
y
3
1 + 1 = 2
1
2
4
1 + 2 = 3
2
3
5
2 + 3 = 5
3
5

TEKNIK REKURSIF
Teknik Rekursif merupakan salah satu cara pembuatan algoritma dengan pemanggilan procedure atau function yang sama
Contoh :
Teknik Rekursif pada algoritma untuk menghitung faktorial dari bilangan bulat positif n, adalah sebagai berikut :
Function FAK (n : integer) : integer
1. If n := 0 then FAK := 1
2. Else FAK := n * FAK(n-1)
Gambaran jalannya proses algoritma tersebut adalah sebagai berikut :
Misal n = 5, maka :

Contoh :
BARISAN BILANGAN FIBBONACI → 1, 1, 2, 3, 5, 8, 13, 21, . . .
Teknik Rekursif pada algoritma untuk menentukan suku ke-n dari barisan bilangan Fibbonaci, adalah sebagai berikut :
Procedure F(n : integer) : integer
1. If n ≤ 2 then F(n) = 1
else F(n) = F(n-1) + F(n-2)
Endif
End
Gambaran jalannya proses algoritma tersebut adalah sebagai berikut :
Misal n = 5, maka :

Perbedaan Antara Teknik Iteratif dan Rekursif :
ITERATIF
Tidak ada variabel lokal baru
Ada variabel lokal baru

REKURSIF
Program tidak sederhana
Program menjadi lebih sederhana

PERMAINAN MENARA HANOI
Contoh paling umum dari penggunaan teknik rekursif adalah pada permainan menara Hanoi. Berdasarkan legenda, pertama kali dimainkan secara manual oleh seorang pendeta Budha di Hanoi, sehingga permainan ini disebut Menara Hanoi. Dalam permainan ini, akan dipindahkan sejumlah piringan yang tidak sama besarnya dari satu tonggak ke tonggak lainnya, dengan diperbolehkan menggunakan (melewati) sebuah tonggak bantuan. Aturan permainannya adalah semua piringan pada tonggak A akan dipindahkan ke tonggak C (dapat dengan melewati tonggak bantuan B), dengan ketentuan bahwa pemindahan piringan dilakukan satu per satu dan piringan yang lebih besar tidak boleh diletakan di atas piringan yang lebih kecil. Untuk jelasnya lihat gambar berikut : Menurut legenda tersebut dikatakan bahwa jika anda selesai memindahkan seluruh 64 piringan, pada saat itu juga dunia kiamat. Ini menurut legenda, yang mungkin juga benar. Secara umum, untuk menyelesaikan n buah piringan diperlukan pemindahan sebanyak 2n –1 kali. Bayangkan jika untuk setiap pemindahan memerlukan waktu 1 detik, maka berapa waktu yang diperlukan untuk menyelesaikan 64 buah piringan.

Pengembangan Perangkat Lunak

Pengembangan Perangkat Lunak – Sebuah Lapisan Teknologi

Meskipun ratusan penulis telah mengembangkan definisi pengembangan perangkat lunak, definisi yang diusulkan oleh Fritz Bauer pada konferensi seminar masalah ini masih menjadi dasar dari diskusi :

Rekayasa perangkat lunak adalah pengembangan dan penggunaan prinsip pengembangan untuk memperoleh perangkat lunak secara ekonomis yang reliable dan bekerja secara efisien pada mesin nyata

Pada definisi tersebut Bauer memberi kita suatu dasar melalui berbagai pertanyaan seperti :

-          Bagaimana kita secara ekonomis membangun perangkat lunak sehingga dapat diandalkan reliable-nya?

-          Apakah yang dibutuhkan untuk menciptakan program komputer yang bekerja secara efisien pada lebih dari satu mesin riil yang berbeda?

IEEE telah mengembangkan definisi yang lebih komprehensif, yaitu sebagai berikut :

Rekayasa perangkat lunak : (1). Aplikasi dari sebuah pendekatan kuantifiabel, disiplin dan sistematis kepada pengembangan, operasi dan pemeliharaan perangkat lunak; yaitu aplikasi dari Rekayasa perangkat lunak. (2). Studi tentang pendekatan-pendekatan seperti pada (1).

2.1.1. Proses, Metode dan Alat Bantu

Rekayasa perangkat lunak merupakan sebuah teknologi yang dibentangkan (gambar 2.1). Banyak pendekatan keteknikan (termasuk rekayasa perangkat lunak) yang harus berada pada sebuah komitmen dasar menuju kualitas.

Tolls

Metode

Proses

Fokus kualitas

Gambar 2.1. Lapisan rekayasa Perangkat Lunak

Pondasi untuk rekayasa perangkat lunak merupakan bentangan proses. Proses-proses rekayasa perangkat lunak adalah perekat yang menjaga bentangan-bentangan teknologi secara bersama-sama dan memungkinkan perkembangan perangkat lunak komputer yang tepat waktu dan rasional.

Metode-metode rekayasa perangkat lunak memberikan teknik untuk membangun perangkat lunak. Metode-metode itu menyangkut serangkaian tugas yang luas yang menyangkut analisis kebutuhan, konstruksi program, desain, pengujian dan pemeliharaan.

Tool-tool rekayasa perangkat lunak memberikan topangan yang otomatis ataupun semi-otomatis pada proses-proses dan metode-metode yang ada.

2.1.2. Pandangan Umum Tentang Rekayasa Perangkat Lunak

Rekayasa merupakan analisis, desain, konstruksi, verifikasi dan manajemen kesatuan teknik (atau sosial). Tanpa mempedulikan kesatuan yang dikembangkan, pertanyaan-pertanyaan di bawah ini harus dimunculkan dan dijawab :

·         Masalah apakah yang akan dipecahkan?

·         Karakteristik kesatuan apakah yang dipakai untuk menyelesaikan masalah tersebut?

·         Bagaimanakah kesatuan (dan pemecahan tersebut) diadakan?

·         Bagaimanakah kesatuan tersebut dibangun?

·         Pendekatan apakah yang akan dipakai untuk menemukan kesalahan-kesalahan yang dibuat di dalam desain dan konstruksi dari kesatuan tersebut?

·         Bagaimanakah kesatuan tersebut ditopang selama proses adaptasi yang lama, pada saat koreksi, serta ketika perbaikan dibutuhkan oleh para pemakai kesatuan tersebut?

Fase definisi (Definition phase) berfokus pada “apa” (what); di mana, pada definisi ini pengembang perangkat lunak harus mengidentifikasi informasi apa yang akan diproses, fungsi dan unjuk kerja apa yang dibutuhkan, tingkah laku sistem seperti apa yang diharapkan, interface apa yang akan dibangun, batasan desain apa yang ada, dan kriteria validasi apa yang dibutuhkan untuk mendefinisikan sistem yang sukses. Kebutuhan (requirement) kunci dari sistem dan perangkat lunak yang didefinisikan.

Fase pengembangan (Development phase) berfokus pada how (bagaimana), yaitu di mana selama masa pengembangan perangkat lunak, teknisi harus mendefiniskan bagaimana data dikonstruksikan, bagaimana fungsi-fungsi diimplementasikan sebagai sebuah arsitektur perangkat lunak, bagaimana detail prosedur akan diimplementasikan, bagaimana interface ditandai (dikarakterisasi), bagaimana rancangan akan diterjemahkan ke dalam bahasa pemrograman (atau bahasa non prosedural), serta bagaimana pengujian akan dilakukan.

Fase pemeliharaan (Maintenance phase) berfokus pada perubahan (change), yang dihubungkan dengan  koreksi kesalahan, penyesuaian yang dibutuhkan ketika lingkungan perangkat lunak berkembang, serta perubahan sehubungan dengan perkembangan yang disebabkan oleh perubahan kebutuhan pelanggan.

Ada empat tipe perubahan yang terjadi selama masa fase pengembangan, yaitu Koreksi. Meskipun dengan jaminan kualitas yang terbaik, sepertinya pelanggan akan tetap menemukan cacat pada perangkat lunak. Pemeliharaan korektif (Corrective maintenance) mengubah perangkat lunak, membetulkan cacat atau kerusakan.

Adaptasi. Dari waktu ke waktu, lingkungan original (contohnya CPU, sistem operasi, aturan-aturan bisnis, karakteristik produk eksternal) di mana perangkat lunak dikembangkan akan terus berubah. Pemeliharaan adaptif (Adaptif maintenance) menghasilkan modifikasi kepada perangkat lunak untuk mengakomodasi perubahan pada kebutuhan fungsionalitas originalnya.

Perkembangan (Enhancement). Ketika perangkat lunak dipakai, pelanggan akan mengenali fungsi-fungsi tambahan yang memberi mereka keuntungan. Perfective maintenance memperluas perangkat lunak sehingga melampaui kebutuhan fungsi originalnya.

Pencegahan. Keadaan perangkat lunak semakin memburuk sehubungan dengan waktu, dan karena itu, preventive maintenance yang sering juga disebut Rekayasa perangkat lunak, harus dilakukan untuk memungkinkan perangkat lunak melayani kebutuhan para pemakainya. Pada dasarnya preventive maintenance melakukan perubahan pada program komputer sehingga bisa menjadi lebih mudah untuk dikoreksi, disesuaikan dan dikembangkan.

Fase dan langkah-langkah yang berhubungan, seperti yang digambarkan pada pandangan umum kita tentang Rekayasa perangkat lunak, harus diimbangi dengan sejumlah aktivitas pelindung (umbrella activities). Kegiatan-kegiatan khusus di dalam kategori ini menyangkut :

·         Kontrol dan pelacakan proyek perangkat lunak

·         Review teknis formal

·         Jaminan kualitas perangkat lunak

·         Manajemen konfigurasi perangkat lunak

·         Penghasilan dan penyiapan dokumen

·         Manajemen reusabilitas

·         Pengukuran

·         Manajemen resiko

2.2. 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.

Perkembangan perangkat lunak bisa dianggap sebagai lingkaran pemecahan masalah (Gambar 2.2.a) di mana terdapat empat keadaan berbeda, yaitu status quo, definisi masalah, perkembangan teknis memecahkan masalah di keseluruhan aplikasi dari banyak teknologi, dan integrasi pemecahan menyampaikan hasil (contohnya dokumen, program, data, fungsi bisnis baru, produk baru) kepada siapa yang membutuhkan pertama kali.

 

Pengembangan teknis

Status

quo

 

Penyatuan solusi

 

 

Gambar 2.2. Fase lingkaran pemecahan masalah

2.3. Model Sekuensial Linier

Gambar 2.3 menggambarkan sekuensial linier untuk rekayasa perangkat lunak, yang sering disebut juga dengan “siklus kehidupan klasik” atau “model air terjun”. Model sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Dimodelkan setelah siklus rekayasa konvensional, model sekuensial linier melingkupi aktivitas-aktivitas sbb :

      Pemodelan

    Sistem operasi

	Analisis

 

Gambar 2.3. Model Sekuensial Linear

Rekayasa dan pemodelan sistem/informasi. Karena perangkat lunak selalu merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak tersebut.

Analisis kebutuhan perangkat lunak. Proses pengumpulan kebutuhan diintensifkan 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 ke dalam 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 secara mekanis.

Pengujian. Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, 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.

Pemeliharaan. Perangkat lunak akan mengalami perubahan setelah disampaikan kepada pelanggan. Perubahan akan terjadi karena kesalahan-kesalahan ditentukan, karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-perubahan di dalam lingkungan eksternalnya, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan perangkat lunak mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi

Model sekuensial linier adalah paradigma rekayasa perangkat lunak yang paling luas dipakai dan paling tua. Masalah-masalah yang kadang-kadang terjadi ketika model sekuensial linier diaplikasikan adalah :

1.    Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model ini. Meskipun model linier bisa mengakomodasi iterasi, model itu melakukannya dengan cara tidak langsung.

2.    Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit.

3.    Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu tidak akan diperoleh sampai akhir waktu proyek dilalui.

4.    Pengembang sering melakukan penundaan yang tidak perlu. Bradac mendapatkan bahwa pada model ini banyak anggota tim proyek haus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan.

 Masing-masing dari masalah tersebut bersifat riil. Tetapi paradigma siklus kehidupan klasik memiliki tempat yang terbatas namun penting di dalam kerja rekayasa [erangkat lunak. Paradigma itu memberikan template di mana metode analisis, desain, pengkodean, pengujian dan pemeliharaan bisa dilakukan. Siklus kehidupan klasik tetap menjadi model bagi rekayasa perangkat lunak yang paling luas dipakai.

2.4. Model Prototipe

Sering seorang pelanggan mendefinisikan serangkaian sasaran umum bagi perangkat lunak, tetapi tidak melakukan mengidentifikasi kebutuhan output, pemrosesan, ataupun input detail. Pada kasus lain pengembang mungkin tidak memiliki kepastian terhadap efisiensi algoritma, kemampuan penyesuaian dari sebuah sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dengan mesin. Dalam hal ini serta pada banyak situasi yang lain, protyping paradigma mungkin menawarkanpendekatan yang terbaik.

Prototyping paradigma (gambar 2.4) dimulai dengan pengumpulan kebutuhan. Kemudian dilanjutkan dengan mengidentifikasi kebutuhan yang diketahui, dan area garis besar di mana definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek-aspek perangkat lunak tersebut yang akan nampak bagi pelanggan/pemakai. Prototipe tsb dievaluasi oleh pelanggan dan dipakai untuk menyaring kebutuhan pengembangan perangkat lunak. Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.

Uji Pelanggan Mengendalikan Market

MembangunMemperbaiki Market

Mendengarkan Pelanggan

Gambar 2.4. Prototipe Paradigma

Para pemakai merasa enak dengan sistem aktual, sedangkan pengembang bisa membangunnya dengan segera. Tetapi prototyping bisa juga menjadi masalah karena alasan-alasan sbb :

1.    Pelanggan melihat apa yang tampak sebagai versi perangkat lunak yang bekerja tanpa melihat bahwa prototipe itu dijalin bersama-sama, tanpa melihat bahwa kita belum mencantumkan kualitas perangkat lunak secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang.

2.    Pengembang sering membuat kompromi-kompromi implementasi untuk membuat prototipe bekerja dengan cepat.

Meskipun berbagai masalah bisa terjadi, 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.

2.5. Model RAD

Rapid Aplication Development (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase-fase sbb :

Bussiness modeling. Aliran informasi diantara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut :

Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkannya?  Ke mana informasi itu pergi? Siapa yang memprosesnya?

                                                                    Tim # 3

                                               

                                        Tim # 2

        Tim # 1

 

           60 – 90 hari

Gambar 2.5. Model RAD

Data modeling. Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.

Proses modeling. Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali  objek data.

Aplication generation. RAD mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD telah banyak memproses kerja untuk memakai lagi komponen program yang ada atau menciptakan komponen yang bisa dipakai lagi.

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.

Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan :

-          Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik

-          RAD menuntut pengembang dab pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada dari tiap konstituen, proyek RAD akan gagal.

2.6. Model Proses Perangkat Lunak  Evolusioner

Model evolusioner adalah model iteratif. Model itu ditandai dengan tingkah laku yang memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih lengkap sedikit demi sedikit.

2.6.1. Model Pertambahan

Model inkremental menggabungkan elemen-elemen model sekuensial linier dengan filosofi prototipe iteratif. Seperti diperlihatkan pada gambar 2.7.

Pada saat model pertambahan dipergunakan, pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertambahan yang dipergunakan, tetapi beberapa muka tambahan tetap tidak disampaikan. Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian lebih detail). Sebagai hasil dari pemakaian dan/atau evaluasi, maka dikembangkan rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsionalitas tambahan. Proses ini diulang mengikuti penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap.

Model proses pertambahan tersebut, seperti model prototipe dan pendekatan-pendekatan evolusioner yang lain, bersifat iteratif. Tetapi tidak seperti model prototipe, model pertambahan berfokus pada penyampaian produk operasional dalam setiap pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.

2.6.2. Model Spiral

Model spiral yang pada awalnya diusulkan oleh Boehm adalah model proses perangkat lunak yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model itu berpotensi untuk pengambangan versi pertambahan perangkat lunak secara cepat.

Model spiral dibagi menjadi sejumlah aktivitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas. Gambar 2.8. menggambarkan model spiral yang berisi enam wilayah tugas :

-          Komunikasi pelanggan – tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembang dan pelanggan

-          Perencanaan – tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.

-          Analisis risiko – tugas-tugas yang dibutuhkan untuk menaksir risiko-risiko, baik manajemen maupun teknis.

-          Perekayasa – tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut

-          Konstruksi dan peluncuran – tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (install) dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).

-          Evaluasi pelanggan – tugas-tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan.

Ketika proses evolusioner ini mulai, tim rekayasa perangkat lunak bergerak searah jarum mengelilingi spiral tersebut dengan dimulai intinya. Lintasan pertama putaran spiral menghasilkan perkembangan dari spesifikasi produk; putaran spiral selanjutnya mungkin dipakai untuk mengembangkan sebuah prototipe, dan secara progresif mengembangkan versi perangkat lunak yang lebih canggih.

Tidak seperti model proses klasik yang berakhir pada saat perangkat lunak sudah disampaikan, model spiral bisa disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.

Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan sistem dan perangkat lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak, pengembang dan pemakai memahami dan bereaksi lebih baik terhadap risiko dari setiap tingkat evolusioner. Model spiral menggunakan prototipe sebagai mekanisme pengurangan risiko.

2.6.3. Model Rakitan Komponen

Model rakitan komponen menggabungkan beberapa karakteristik model spiral. Model ini bersifat evolusioner, sehingga membutuhkan pendekatan iteratif untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan (kadang-kadang disebut “kelas”).

Aktivitas perangkat lunak dimulai dengan identifikasi calon kelas. Hal ini dipenuhi dengan mengamati data yang akan dimanipulasi oleh aplikasi dan algoritma-algoritma yang akan diaplikasikan untuk melakukan manipulasi. Data dan algoritma yang berhubungan dikemas ke dalam sebuah kelas.

Kelas-kelas (disebut komponen di dalam gambar 2.10). yang diciptakan di dalam proyek perangkat lunak disimpan di dalam class library atau tempat penyimpanan. Sekali kelas-kelas kandidat diidentifikasi, perpustakaan-perpustakaan kelas diamati untuk menentukan apakah kelas-kelas itu ada. Bila ada kelas itu kemudian diekstraksi dari pustaka dan digunakan lagi. Jika sebuah kelas kandidat tidak ada di dalam pustaka, dia direkayasa dengan menggunakan metode berorientasi objek. Iterasi aplikasi pertama yang akan dibangun kemudian dikomposisi dengan mempergunakan kelas yang diekstraksi dari perpustakaan dan kelas-kelas baru lain yang dibangun untuk memenuhi kebutuhan-kebutuhan unik dari aplikasi. Kemudian aliran proses kembali ke spiral dan akan masuk lagi ke iterasi rakitan komponen selama subsekuen melewati aktivitas perekayasaan.

Model rakitan komponen membawa kepada penggunaan kembali perangkat lunak, dan kegunaan kembali tersebut memberi sejumlah keuntungan yang bisa diukur pada perekayasa perangkat lunak.

2.6.4. Model perkembangan Konkuren

Model proses konkuren sering digunakan sebagai paradigma bagi pengembangan aplikasi klien/server. Sistem klien/server dirancang dari serangkaian komponen fungsional. Bila diaplikasikan kepada klien/server, model proses konkuren akan mendefinisikan aktivitas di dalam dua dimensi : dimensi sistem, dan dimensi komponen. Isu tingkat sistem ditujudengan menggunakan tiga aktivitas : desain, assembly, dan pemakaian. Dimensi komponen dituju dengan dua aktivitas : desain dan rea-lisasi. Konkuren dicapai dengan dua cara :

(1) aktivitas sistem dan komponen yang berlangsung secara simultan dan dapat dimodelkan dengan menggunakan pendekatan orientasi keadaan yang digambarkan di atas;

(2) aplikasi klien/server khusus diimplementasikan dengan banyak komponen di mana masing-masing bisa dirancang dan direalisasikan secara konkuren.

Kenyataannya model proses konkuren bisa diaplikasikan ke dalam semua tipe perkembangan perangkat lunak, dan memberikan gambaran akurat mengenai keadaan tertentu dari sebuah proyek.

2.7. Model Formal

Model metode formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak komputer. Metode formal memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi sistem berbasis komputer dengan menggunakan notasi matematis yang tepat. Variasi di dalam pendekatan ini, disebut juga clean-room Rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak.

Meskipun belum menjadi pendekatan utama, model metode formal sudah menawarkan janji perangkat lunak yang bebas cacat/kesalahan; tetapi perhatian tentang kemampuan aplikasinya di dalam lingkungan bisnis sudah mulai disuarakan :

1.    Pengembangan model formal banyak memakan waktu dan mahal

2.    Karena beberapa pengembang perangkat lunak perlu mempunyai latar belakang yang diperlukan untuk mengaplikasikan metode formal, maka diperlukan pelatihan yang ekstensif.

3.    Sulit untuk menggunakan model-model sebagai sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih.

2.8.      Teknik Generasi Keempat

Bentuk “teknik generasi keempat” (4GT) 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.

Sekarang ini lingkungan perkembangan perangkat lunak yang mendukung paradigma 4GT menyangkut beberapa atau semua alat bantu berikut ini : bahasa nonprosedural untuk query database, generate laporan, manipulasi data, interaksi layar dan definisi, dan penghasil kode; kemampuan grafis tingkat tinggi; dan kemampuan spreadsheet. Pada dasarnya dulu alat-alat bantu yang ditulis di atas bisa diperoleh hanya untuk domain aplikasi tertentu saja, tetapi sekarang lingkungan 4GT telah diperluas untuk menjangkau sebagian besar kategori aplikasi perangkat lunak.

Untuk aplikasi yang kecil, mungkin untuk bergerak secara langsung dari langkah pengumpulan kebutuhan ke implementasi, digunakan bahasa generasi keempat nonprosedural (fourth generation language/4GL). Tetapi untuk usaha yang lebih besar, diperlukan pengembangan strategi desain bagi sistem tersebut, sekalipun sebuah 4GL akan digunakan. Pemakaian 4GL tanpa desain (untuk proyek besar) akan menyebabkan terjadinya kesulitan-kesulitan yang sama (kualitas yang buruk, kemampuan pemeliharaan yang buruk, penerimaan pelanggan yang buruk) yang telah kita alami pada saat mengembangkan perangkat lunak dengan menggunakan pendekatan ad hoc.

Untuk menyimpulkan keadaan sekarang dari pendekatan 4GT :

1.     Kegunaan 4GT telah disebarkan selama dekade terakhir dan sekarang merupakan pendekatan yang masih berjalan terus bagi berbagai area aplikasi yang berbeda-beda.

2.     Data yang dikumpulkan dari perusahaan-perusahaan yang menggunakan 4GT menunjukkan bahwa waktu yang dibutuhkan untuk menghasilkan perangkat lunak sangat berkuranguntuk aplikasi kecil dan menengah, serta jumlah desain dan analisis bagi aplikasi kecil juga berkurang.

3.     tetapi kegunaan 4GT untuk pengembangan perangkat lunak yang besar membutuhkan analisis, desain dan pengujian yang sangat banyak untuk memperoleh penghematan waktu uang substansial yang dapat dicapai melalui eliminasi pengkodean.

Teknik generasi keempat telah menjadi sebuah bagian yang penting dari perkembangan perangkat lunak. Bila dirangkai dengan pendekatan rakitan komponen, paradigma 4GT bisa menjadi pendekatan yang dominan untuk pengembangan perangkat lunak.

2.9.      Teknologi Proses

Model proses yang telah didiskusikan pada bagian terdahulu harus disesuaikan dahulu sebelum digunakan oleh tim proyek perangkat lunak. Untuk melakukannya telah dikembangkan alat-alat bantu teknologi proses untuk membantu organisasi perangkat lunak menganalisa proses mereka yang sedang berlangsung, mengorganisasi tugas-tugas kerja, mengontrol dan memonitor kemajuan, serta mengatur kualitas teknis.

Sekali sebuah proses yang bisa diterima diciptakan, alat-alat bantu teknologi proses yang lain dapat dipergunakan untuk mengalokasi, memonitor, dan bahkan mengontrol semua tugas rekayasa perangkat lunak yang didefinisikan sebagai bagian dari model proses.

Model dan Proses Rekayasa Perangkat Lunak

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. Namun 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.

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.

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. Biaya yang beragam tergantung pada tipe sistem yang akan dikembangkan dan kebutuhan sistem seperti unjuk kerja dan kehandalan sistem. Distribusi biaya bergantung pada model pengembangan yang digunakan.

Proses memiliki atribut dan karakteristik sbb :

§ Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.

• Visibility, yaitu apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas.
• Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
• Acceptability, yaitu apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
• Reliability, yaitu apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
• Robustness, yaitu dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
• Maintainability, yaitu dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
• Rapidity, yaitu bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

Model-model proses

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.

Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.
Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.
Selain itu, saat ini juga ada model-model proses hasil pengembangan seperti Agile modelling, XP (Xtreeme Programming), RUP, dan MSF.

a. 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 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.

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. 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:
1. Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan.
2. 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.
3. 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.
4. Model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup.
5. Mampu mengakomodasi perubahan secara fleksibel.
6. 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

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 :

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 detil pada sektor ini. Langkahlangkah 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, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.
4. 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.

c. Transformasi formal

Metode ini berbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda untuk suatu program yang dapat dieksekusi. Trasformasi menyatakan spesifikasi program Menggunakan pendekatan ‘Cleanroom’ untuk pengembangan PL.

Metode ini mempunyai keterbatasan dalam pemakaiannya. Keunggulannya adalah mengurangi jumlah kesalahan pada sistem sehingga penggunaan utamanya adalah pada sistem yang kritis. Hal ini menjadi efektif dari segi biaya.

Pemakaian model pengembangan formal memerlukan tingkat kerahasian sebelum digunakan.
Permasalahan dalam model pengembangan metode formal:

• Memerlukan keahlian khusus dan pelatihan untuk mengaplikasikannya
• Sulit menentukan beberapa aspek dari suatu sistem seperti
user interface

c. Pengembangan Menggunakan Konsep Re-use (Penggunaan Ulang)
Metode ini didasarkan pada sistem yang telah tergabung dari sejumlah komponen yang ada atau sistem COTS (Commercial-off-the-shelf)

Langkah-langkah proses:

• Analisis komponen

• Kebutuhan perubahan

• System design dengan penggunaan ulang

• Pengembangan dan Development dan penggabungan

Pendekatan ini menjadi penting tetapi tetap saja mempunyai keterbatasan dalam penggunaannya

MODEL RAPID APLICATION DEVELOPMENT

Rapin Aplication Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut :

1. Bussiness modeling

Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

1. Data modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing–masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.

1. Prosess modelling

Aliran informasi yang didefinisikan di dalam fase data modeling
ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.

1. Aplication generation

RAD mengasumsikan pemakaian teknik generasi ke empat. Selain
menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

1. 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 di uji dan semua interface harus dilatih secara penuh.

Kekurangan model RAD adalah :

1. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
2. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

Prototyping Model

 

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.

Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut:

• Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan.
• Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
• 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 detil 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.

Component-based Development Model

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. Model ini bersifat iteratif atau berulang-ulang prosesnya.

Secara umum proses yang terjadi dalam model ini adalah:

1. Identifikasi class-class yang akan digunakan kembali dengan menguji class tersebut dengan data yang akan dimanipulasi dengan aplikasi/software dan algoritma yang baru
2. Class yang dibuat pada proyek sebelumnya disimpan dalam class library, sehingga bisa langsung diambil dari library yang sudah ada. Jika ternyata ada kebutuhan class baru, maka class baru dibuat dengan metode berorientasi objek.
3. Bangun software dengan class-class yang sudah ditentukan atau class baru yang dibuat, integrasikan.

Penggunaan kembali komponen software yang sudah ada menguntungkan dari segi:

a Siklus waktu pengembangan software, karena mampu mengurangi waktu 70%

b Biaya produksi berkurang sampai 84% arena pembangunan komponen berkurang

Pembangunan software dengan menggunakan komponen yang sudah tersedia dapat menggunakan komponen COTS (Commercial off-the-shelf) – yang bisa didapatkan dengan membeli atau komponen yang sudah dibangun sebelumnya secara internal. Component-Based Software Engineering (CBSE) adalah proses yang menekankan perancangan dan pembangunan software dengan menggunakan komponen software yang sudah ada. CBSE terdiri dari dua bagian yang terjadi secara paralel yaitu software engineering (component-based development) dan domain engineering seperti yang digambarkan pada Gambar 2:

1. 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.
2. Software engineering (component-based development) melakukan analisis terhadap domain model yang sudah ditetapkan kemudian menentukan spesifikasi dan merancang berdasarkan model struktur dan spesifikasi sistem, kemudian melakukan pembangunan software dengan menggunakan komponen-komponen yang sudah ditetapkan berdasarkan analisis dan rancangan yang dihasilkan sebelumnya hingga akhirnya menghasilkan software.

Extreme Programming (XP) Model

Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah model proses yang terbaru dalam dunia rekayasa perangkat lunak dan mencoba menjawab kesulitan dalam pengembangan software yang rumit dan sulit dalam implementasi.
Menurut Kent Beck XP adalah : “A lightweight, efficient, low-risk, flexible,predictable, scientific and fun way to develop software”. Suatu model yang menekankan pada:

- keterlibatan user secara langsung

- pengujian

- pay-as-you-go design

Adapun empat nilai penting dari XP

1. Communication/Komunikasi : komunikasi antara developer dan klien sering menjadi masalah. Karena itu komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas jugadiperhitungkan.
2. Simplicity/ sederhana: Menekankan pada kesederhanaan dalam pengkodean: “What is the simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
3. Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.