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.