Telah di Baca 3246 kali
Definisi Pengembangan Perangkat Lunak
Fritz Bauer memberikan definisi bahwa Rekayasa Perangkat Lunak merupakan pengembangan dan penggunaan prinsip pengembangan suara untuk memperoleh perangkat lunak secara ekonomis yang reliable dan bekerja secara efisien pada mesin nyata.
Sedangkan IEEE telah mengembangkan definisi yang lebih komperhensif yaitu bahwa rekayasa perangkat lunak :
1. Aplikasi dari sebuah pendekatan kuantitatif, disiplin, dan sistematis kepada pengembangan, operasi, dan pemeliharaan perangkat lunak yaitu : aplikasi dari Rekayasa Perangkat Lunak.
2. Studi tentang pendekatan – pendekatan seperti pada nomor 1.
Proses, Metode, dan Alat Bantu
Rekayasa perangkat lunak merupakan sebuah teknologi yang dibentangkan. Banyak pendekatan keteknikan yang harus berada pada sebuah komitmen dasar menuju kualitas. Batu landasan yang menopang rekayasa perangkat lunak merupakan fokus pada kualitas. Fondasi 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 seragkaian tugas yang luas yang menyangkut analisis kebutuhan, konstruksi program, desain, pengujian, dan pemeliharaan. Rekayasa perangkat lunak mengandalkan pada serangkaian prinsip dasar yang mengatur setiap area teknologi dan menyangkut aktivitas permodelan serta teknik – teknik deskriptif yang lain.
Tool – tool rekayasa perangkat lunak memberikan topangan yang otomatis maupun semi-otomatis pada proses – proses dan metode – metode yang ada. Ketika tool – tool diintegrasikan sehingga informasi yang diciptakan oleh satu tool bias digunakan oleh yang lain, system untuk menopang perkembangan perangkat lunak yang disebut computer-aided software engineering (CASE) terbangun. CASE menggabungkan perangkat lunak, perangkat keras, dan database rekayasa perangkat lunak untuk menciptakan lingkungan rekayasa perangkat lunak yang analog dangan CAD/CAE (Computer Aided Design/Engineering) untuk perangkat keras.
Pandangan Umum Tentang Rekayasa Perangkat Lunak
Usaha yang berhubungan dengan rekayasa perangkat lunak dapat dikategorikan ke dalam tiga fase umum dengan tanpa memperdulikan area aplikasi, ukuran proyek, atau kompleksitasnya. Masing – masing fase akan memberi tekanan pada pertanyaan – pertanyaan yang telah ditulis diatas.
Fase definisi (Definition Phase) berfokus pada apa, dimana pada definisi ini pengembang perangkat lunak harus mengidentifikasi informasi apa yang akan diproses, fungsi dan unjuk kerja apa yang dibutuhkan, tingkah laku system 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.
Fase pengembangan (Development Phase) berfokus pada how (bagaimana) yaitu dimana selama masa pengembangan perangkat lunak, teknisi harus mendefinisikan bagaimana dat dikonstruksikan, bagaimana fungsi – fungsi diimplementasikan, bagaimana interface ditandai, bagaimana rancangan akan diterjemahkan ke dalam bahasa pemrograman, serta bagaimana pengujian akan dilakukan.
Fase pemeliharaan (Maintenance Phase) berfokus pada perubahan, yang dihubungkan dengan koreksi kesalahan, penyesuaian yang dibutuhkan ketika lingkungan perangkat lunak berkembang, serta perubahan sehubungan dengan perkembangan yang disebabkan oleh perubahan kebutuhan pelanggan. Fase pemeliharaan mengaplikasikan lagi langkah – langkah pada fase definisi dan fase pengembangan, tetapi semuanya tetap tergantung pada konteks perangkat lunak yang ada.
Ada empat tipe perubahan yang terjadi selama masa fase pengembangan, yaitu:
a. Koreksi
b. Adaptasi
c. Perkembangan
d. Pencegahan
Model – Model Proses Perangkat Lunak
Untuk menyelesaikan masalah didalam suatu industri, rekayasa perangkat lunak atau tim perekayasa harus menggabungkan strategi pengembangan yang melingkupi lapisan proses, metode, dan alat – alat bantu serta fase – fase generik yang telah dijelaskan sebelumnya. Strategi ini sering diacukan sebagai model proses atau paradigma rekayasa 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.
Untuk contoh model2nya bisa dilihat di bawah ini
Model Sekuensial Linear (Water Fall)
Model sekuensial linier untuk software engineering, sering disebut juga dengan siklus kehidupan klasik atau model air terjun. Model ini mengusulkan sebuah pendekatan kepada perkembangan software yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah siklus rekysa konvensional, model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut :
1. Rekayasa dan permodelan sistem
Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, 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 system 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 yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah:
1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
2. Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.
3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.
4. Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier.
Model Prototipe
Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek – aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Perancangan kilat membawa kepada konstruksi sebuah prototipe. Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan software. 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.
Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan software. Bila prototipe yang sedang bekerja dibangun, pengembang harus mempergunakan fragmen – fragmen program yang ada atau mengaplikasikan alat –alat bantu (contohnya report generator, window manager, dll) yang memungkinkan program yang bekerja untuk dimunculkan secara cepat.
Prototipe bisa juga menjadi masalah karena alasan sebagai berikut:
1. Pelanggan melihat apa yang tampak sebagai versi software yang bekerja tanpa melihat bahwa prototipe itu dijalin bersama – sama “dengan permen karet dan baling wire”, tanpa melihat bahwa di dalam untuk membuatnya bekerja, kita belum menyantumkan kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk membuat prototipe menjadi sebuah produk yang bekerja yang lebih sering terjadi, sehingga manajemen pengembangan software menjadi penuh dengan belas kasihan.
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 dan dikenal; algoritma yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemonstrasikan kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan – pilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah sistem.
Meskipun berbagai masalah bisa terjadi, prototipe bisa menjadi paradigma yang efektif bagi Software Engineering. Kuncinya adalah mendefinisikan aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling tidak sebagian), dan software aktual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan.
Model Rapid Aplication Development
Rapid 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. Business 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?
2. Data modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase business 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.
3. 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 sebuah objek data.
4. Application 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.
5. 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.
Model Spiral
Model spiral (spiral model) adalah model proses software yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model ini berpotensi untuk pengembangan versi pertambahan software secara cepat. Di dalam model spiral, software dikembangkan di dalam suatu deretan pertambahan. Selama awal iterasi, rilis inkremental bisa merupakan sebuah model atau prototipe kertas. Selama iterasi berikutnya, sedikit demi sedikit dihasilkan versi sistem rekayasa yang lebih lengkap.
Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas, yaitu :
1. Komunikasi Pelanggan
Tugas – tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembangan dan pelanggan.
2. Perencanaan
Tugas – tugas yang dibutuhkan untuk mendefinisikan sumber – sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
3. Analisis Risiko
Tugas – tugas yang dibutuhkan untuk menaksir risiko – risiko, baik manajemen maupun teknis.
4. Perekayasaan
Tugas – tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
5. Konstruksi dan peluncuran
Tugas – trugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instal) dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).
6. Evaluasi pelanggan
Tugas – tugas yang dibutuhkan untuk memperoleh umpan balik dari pelnggan dengan didasarkan pada evaluasi representasi software, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan.
Kekurangan model spiral adalah sulitnya untuk meyakinkan konsumen (khusunya dalam situasi kontrak) bahwa pendekatan evolusioner bisa dikontrol. Model spiral memerlukan keahlian penaksiran risiko yang msuk akal , dan sangat bertumpu pada keakhlian ini untuk mencapai keberhasilan. Jika resiko mayor tidak ditemukan dan diatur, pasti akan terjadi masalah. Akhirnya model itu sendiri masih baru dan belum dipergunakan secara luas seperti paradigma sekuensial dan prototipe.
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 system berbasis computer dengan menggunakan notasi matematis yang tepat. Variasi didalam pendekatan ini, disebut juga clean-room rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak.
Bila metode formal dipakai selama masa pengembangan, metode itu memberika mekanisme untuk mengeliminasi banyak masalah yang sulit dipecahkan dengan menggunakan paradigma perangkat lunak yang lain. Ambiguitas, ketidaklengkapan, dan ketidak-konsistenan bisa ditemukan dan diperbaiki secara lebih mudah, tidak melalui kajian ad hoc tetapi melalui aplikasi analisis matematis. Jika metode formal dipakai selama masa perancangan, mereka berfungsi sebagai dasar verifikasi program sehingga memungkinkan perekayasa perangkat lunak untuk menemukan dan memperbaiki kesalahan yang mungkin saja tidak terdeteksi.
Meskipun belum menjadi pendekatan utama, model metode formal sudah menawarkan janji perangkat lunak yang bebas cacat/kesalahan, tetapi perhatian tentang kemampuan aplikasinya didalam 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.
Meskipun demikian, sepertinya metode formal ini akan memperoleh banyak penganut diantara pengembang perangkat lunak yang harus membangun perangkat lunak yang kritis untuk keselamatan (misalnya pengembang perangkat medis dan penerbangan pesawat), serta diantara pengembang yang harus menderita karena factor ekonomis yang harus dialami oeh perangkat lunak.
Produk dan Proses
Bila proses lemah maka tidak diragukan lagi hasilnya juga akan buruk. Tetapi ketergantungan yang obsessive pada proses juga berbahaya. Secara singkat Margaret David mengomentari dualitas hasil dan proses sebagai berikut :
Sekitar setiap sepuluh tahun lebih atau kurang dari lima, komunitas perangkat lunak kembali mendefinisikan “masalah” dengan menggeser fokusnya dari isu produk ke isu proses. Demikianlah, kita telah mempergunakan bahasa program terstruktur (produk) diikuti dengan metode analisis terstruktur (proses) diikuti dengan enkapsulasi data (produk) diikuti dengan penekanan pada rekayasa perangkat lunak Institute’s Software Development Capability Maturity Model (proses).
Sementara tendensi natural dari pendulum adalah kembali lagi ke titik tengah diantara dua titik ujung, focus komunitas perangkat lunak bergeser secara konstan karena gaya baru diaplikasikan ketika ayunan yang terdahulu gagal. Ayunan – ayunan tersebut menjadi pengganggu di antara mereka sendiri karena mereka meragukan pelaksana perangkat lunak rata – rata dengan mengubah secara radikal apa artinya melakukan pekerjaan. Belum lagi untuk melakukannya dengan baik. Ayunan itu juga akan memecahkan “masalah”, karena gagal selama produk dan proses diperlakukan seperti membentuk sebuah dikotomi dan bukan dualitas.
Semua kegiatan manusia bisa menjadi proses, tetapi masing – masing dari kita menarik diri dari kegiatan – kegiatan yang menghasilkan representasi atau contoh yang dapat dipergunakan atau dihargai oleh satu orang atau lebih tersebut, yaitu bahwa kita tidak merasa puas terhadap penggunaan kembali produk kita oleh kita sendiri atau orang lain.
Kerja masyarakat perangkat lunak akan berubah didalam tahun ini dan yang akan dating. Dualitas produk dan proses merupakan elemen penting didalam menjaga manusia – manusia kreatif agar terjalin sementara rekayasa pemrograman dan perangkat lunak diselesaikan.
Ringkasan
Rekayasa perangkat lunak adalah satu disiplin yang mengintegrasikan proses, metoda, dan perangkat (tools) untuk pengembangan dari perangkat lunak komputer. Sejumlah model proses berbeda untuk rekayasa perangkat lunak adalah mengusulkan, masing-masing memperlihatkan kekuatan dan kelemahan, tetapi semua mempunyai satu rangkaian umum buat bertahap sama. Prinsip, konsep, dan metoda yang memungkinkan kita untuk melakukan proses bahwa kita menyebut rekayasa perangkat lunak .
Referensi:
1. Ivan Sudirman, Perkembangan Software Komputer, 2003, http://www.ilmukomputer.com (12 juli 2003).
2. Pressman, Roger S, Software Engineering : A Practitioner’s Approach, McGraw-Hill Companies, Inc. 1997.
3. http://romisatriawahono.net/
4. http://university.romisatriawahono.net/
Telah di Baca 3246 kali