Rekayasa Perangkat Lunak II

BAB 2
PROSES

Di dalam konteks buku ini, kita mendefinisikan proses perangkat lunak sebagai sebuah kerangka kerja untuk tugas-tugas yang dibutuhkan untuk membangun perangkat lunak dengan kualitas yang tinggi. Perkembangan perangkat lunak juga meliputi teknologi yang mempopulasikan proses, metode teknis, serta alat-alat otomatis.

2.1 PENGEMBANGAN PERANGKAT LUNAK – SEBUAH LAPISAN TEKNOLOGI
Definisi yang diusulkan oleh Fritz Baeur [NAU69] pada konferensi seminar mengenai Rekayasa perangkat lunak adalah pengembangan dan penggunaan prinsip pengembangan suara untuk memperoleh perangkat lunak untuk memperoleh perangkat lunak secara ekonomis yang reliabel dan bekerja secara efisien pada mesin nyata.
IEEE [IEE93] telah mengembangkan beberapa definisi yang lebih komprehensif , yaitu sebagai berikut:
1. Rekayasa perangkat lunak adalah aplikasi dari sebuah pendekatan kuantifiabel, disiplin, dan sistematis kepada pengembangan, operasi dan pemeliharaan perangakat lunak; yaitu apliaksi dari perangkat lunak.
2. Studi pada pendekatan-pendekatan seperti pada pengertian (1).

Proses, Metode dan Alat Bantu
Proses-proses Rekayasa perangkat lunak adalah perangkat yang menjaga bentangan-bentangan teknologi secara bersama-sama dan memungkinkan perkembangan perangkat lunak komputer yang tepat waktu dan rasional. Proses-proses tersebut membatasi kerangka kerja untuk serangkaian area proses kunci (key process key/KPAs) [PAU93] yang harus dibangun demi keefektifan penyampaian teknologi pengembangan perangkat lunak.
Sistem untuk menopang perkembangan perangkat lunak yang disebut computer-aided Rekayasa perangkat lunak(CASE) terbangun. CASE menggabungkan perangkat lunak, perangkat keras, dan database perangkat lunak untuk menciptakan lingkungan rekayasa perangkat lunak yang analog dengan CAD/CAE (computer-aided design/engineering) untuk perangkat keras.

Pandangan Umum Tentang Rekayasa Perangkat Lunak
Rekayasa merupakan analisis, desain, konstruksi, verifikasi, dan manajemen kesatuan teknik atau sosial. Usaha yang berhubungan dengan Rekayasa perangkat lunak dapat dikategorikan ke dalam tiga fase umum tanpa mempedulikan area aplikasi, ukuran proyek, dan kompleksitasnya.
1. fase definisi (Definition fhase)
2. fase pengembangan (Development fhase)
3. fase pemeliharaan (Maintenance fhase)

PROSES PERANGKAT LUNAK
Pendekatan SEI (Rekayasa perangkat lunak Institute) memberikan sebuah pengukuran terhadap efektivitas global dari sebuah praktek perekayasaan perangkat lunak perusahaan dan membangun lima tingkat kematangan proses, yang didefinisikan dengan cara berikut:
Level 1 : Initial – Proses perangkat lunak yang ditandai sebagai ad ho, dan bahkan kadang-kadang bersifat kacau(chaotic).
Level 2 : Repeatable – Proses-proses manajemen proyek dasar dibangun untuk menelusuri masalah biaya, jadual dan fungsionalitas.
Level 3 : Defined – Proses perangkat lunak, baik untuk aktivitas manajemen atau perekayasaan didokumentasikan, distandarkan, dan diintegrasikan kedalam proses perangkat lunak organisasi besar.
Level 4 : Managed – Pengukuran detail terhadap proses perangkat lunak dan kualitas produksi yang dikumpulkan.
Level 5 : Optimizing – Pembatasan proses yang terus menerus dimungkinkan oleh umpan balik kuantitatif dari proses dan dari gagasan inofatif pengujian secara teknologi.

Lima tingkat yang didefinisikan oleh SEI ini disimpulkan dari sebuah konsekuensi respon evaluasi ke assessment questionnaire yang didasarkan pada CMM. Hasil dari kuesioner tersebut didestilasi menjadi sebuah tingkatan numerik tunggal yang memberikan identifikasi terhadap kematangan proses organisasi.

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 control serta penyampaian yang dibutuhkan.

MODEL SEKUENSIAL LINIER
Model Sekuensial linier mengusulkan sebuah pendekatan kepada perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan system pada seluruh analisis, design, kode, pengujian dan pemeliharaan.
Model sekuensial linier melingkupi aktivtas-aktivtas sebagai berikut:
- Rekayasa dan pemodelan system/indormasi
- Analisis kebutuhan perangkat lunak
- Desaign
- Generasi kode
- Pengujian
- Pemeliharaan
Model Sekuensial linier adalah paradigma rekayasa perangkat lunak yang paling luas di pakai dan paling tua.
Masalah-masalah yang kadang-kadang terjadi ketika model sekuensial linier diaplikasikan adalah :
- Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model.
- Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhanya secara eksplisit.
- Pelanggan harus bersifat sabar.
- Pengembang sering melakukan penundaan yang tidak perlu.

MODEL PROTOTIPE
Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan perangkat lunak.
Tetapi prototyping bias juga menjadi masalah karena alasan-alasan sebagai berikut :
- Tidak mencantumkan kualitas perangkat lunak secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang.
- 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 mendemon-strasikan kemampuan.

MODEL RAD
Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan perangkat lunak sikuensial linear yang menekankan siklus perkembangan yang sangat pendek.
Pendekatan RAD meliputi fase-fase sebagai berikut[KER94]:
- Bussiness modeling. Aliran informasi di antara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan tertentu.
- Data modeling. Aliran informasi yang didefinisikan sebagai bagian dari fase business modeling disaring kedalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.
- Prosess modeling. Aliran informasi yang didefinisikan didalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis.
- Aplication generation. RAD mengasumsikan pemakaian teknik generasi ke empat.
- Testing and turnover. Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian.
Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan [BUT94]:
• Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
• RAD menuntut pengembang dan pelanggan memiliki komitmen didalam aktifitas rafid-fire yang diperlukan untuk melengkapi sebuah system, didalam kerangka waktu yang sangat diperpendek.

2.7 MODEL PROSES PERANGKAT LUNAK EVOLUSIONER
Model sekuential linier (subbab 2.4) dirancang bagi perkembangan garis lurus. Pada dasarnya pendekatan air terjun ini mengandalkan bahwa sebuah sistem lengkap akan disamapaikan setelah urutan linier tersebut dilengkapi.
Secara umum model itu tidak dirancang untuk menyampaikan sistem produksi. Sifat evolusioner perangkat lunak tidak dimasukkan di dalam satu paradigma rekayasa perangkat lunak klasik tersebut.
Model evolusioner adalah model iterative. Model itu ditandai dengan tingkah laku yang memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih lengkap sedikit demi sedikit.

2.7.1 Model Pertambahan
Model inkremental menggabungkan elemen – elemen model sekuential linier dengan filosofi prototipe iteratif. Harus dicatat bahwa aliran proses untuk bebagai pertambahan tersebut dapat menggabunggkan paradigma prototipe.
Pada saat model pertambahan dipergunakan , pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertamhan yang dipergunakan, tetapi beberapa muka tambahan tetap disampaikan. Sebagai hasil dari pemakaian dan/atau evaluasi, maka dikembangkan rencana bagi pertumbuhan selanjutnya. Rencana tersebut menekan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggandan penyampaian fitur serta fungsionalitas tambahan.

2.7.2 Model Spiral
Model Spiral (spiral model) yang pada awalnya diusulkan oleh Boehm [BOE88], adalah model proses perangakat lunak yang evolusioner yang merangakai sifat iteratif dari prototipe dengan cara control dan aspek sistematis dari model sekuensial linier.
Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas. Diantara tiga sampai enam wilayah tugas.
• Komunikasi pelanggan -- tugas–tugas yang dibutuhkan untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.
• Perencanaan -- tugas-tugas yang dibutuhkan untuk mendefinisikan sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
• Analisis risiko -- tugas-tugas yang dibutuhkan untuk menaksir risiko-risiko, baik manajemen maupun teknis.
• Perekayasaan -- tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.
• Konstruksi dan peluncuran -- tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasangg (install) dan memberikan pelayanan kepada pemakai.
• 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.

Sebuah proyek perkembangan konsep (concept development project) berawal dari inti spiral dan akan terus berlangsung sampai perkembangan konsep itu terlengkapi. Model spiral menggunakan prototipe sebagai mekaninsme pengurangan risiko.tetapi model spiral memungkinkan pengembang menggunakan pendekatan prototipe pad asetiap keadaan di dalam evolusi produk.

2.7.3 Model Rakitan Komponen
Model Rakitan komponen menggunakan beberapa karakteristik model spiral. Model ini bersifat evolusioner [NIE92], sehingga membutuhkan pendekatan iteratif untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan.
Model rakitan komponen membawa kepada penggunaan kembali perangkat lunak, dan kegunaan kembali tersebut memberi sejumlah keuntungan yang bias diukur pada perekayasa perangkat lunak. Berdasarkan studi reusabilitas ini, QSM Associates, Inc. melaporkan bahwa rakitan komponen telah memberi reduksi sebanyak 70% di dalam siklus waktu perkembangan, 84% pada biaya proyek, serta memberikan indeks produktivitas sebesar 26,2 [YOU94].

2.7.4 Model Perkembangan Konkruen
Model proses yang konkruen disajikan secara skematis sebagai sederetan aktivitas teknis mayor, tugas-tugas, dan keadaanya yang lain. Contohnya aktivitas rekayasa yang dibatasi untuk model spiral [Subbab 2.72] dipenuhi dengan melakukan tugas-tugas sebagai berikut: prototyping, dan atau pemodelan analisis, spesifikasi kebutuhan, dan rancangan. Model proses konkruen sering digunakan sebagai paradigma bagi pengembangan aplikasi klien/server. Sistem klien/server dirancang dari serangkaian komponen fungsional.

2.8 MODEL FORMAL
Model metode formal mencangkup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak computer. 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, [MIL87,DYE92] sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak.
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 format 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 makanisme komunikasi bagi pemakai yang secara teknik belum canggih.

2.9 TEKNIK GENERASI KEEMPAT
Bentuk “teknik generasi keempat” (4GT) mencangkup serangkaian batu perangkat lunak yang luas yang secara umum memiliki satu hal: masing-masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa karakteristik perangkat lunak pada suatau tingkat yang tinggi. 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 sitem tersebut, sekalipun 4GL akan digunakan.
Ada beberapa segi baik dari kedua sisi klaim di atas; dan mungkin untuk menyimpulkan keadaan sekarang dari pendekatan 4GT.
1. kegunaan 4GT telah disebarkan selama decade terakhir dan sekarang merupakan pendekatan yang masih berjalan teus 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 berkurang untuk 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 waktuyang subtansial yang dapat dicapai melalui eliminasi pengkodean.
Kesimpulannya, teknik generasi keempat telah menjadi sebuah bagian yang penting dari perkembangan perangkat lunak. Bila dirangkai dengan pendekatan rakitan komponen (Subbab 2.7.3), paradigma 4GT bias menjadi pendekatan yang dominan untuk pengembangan perangkat lunak.

2.10 TEKNOLOGI PROSES
Untuk melakukan model proses, telah dikembangkan alat-alat bantu teknologi proses untuk membantu organisasi perangkat lunak menganalisa proses mereka yang sedang berlangsung, mengordinasi tugas-tugas kerja, mengontrol dan memonitor kemajuan, serta mengatur kualitas teknis [BAN95]. Sekali sebuah proses yang bias 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. Alat-alat bantu teknologi proses juga dapat dipergunakan untuk mengkoordinasikan penggunaan alat-alat bantu perangkat lunak komputer bantuan yang sesuai untuk tugas-tugas kerja khusus.

2.11 PRODUKSI PROSES
Secara singkat, Margaret David [DAV95] mengomentari dualitas hasil dan proses sebagai berikut:
Sekitar setiap sepuluh tahun lebih atau kurang dari lima, komunitas perangkat lunak kembali mendefinisikan “masalah” dengan menggeser fokousnya dari isu proses. Demikianlah, kita telah mempergunakan bahasa program terstruktur diikuti dengan enkapsulasi data diikuti dengan penekanan pada Rekayasa perangkat lunak Institute’s Software Development Capability Maturity Model.

2.13 RANGKUMAN
Rekayasa perangkat lunak adalah sebuah disiplin yang mengintegrasikan proses, metode, dan alat-alat bantu bagi perkembangan proses perangkat lunak komputer. Sejumlah model proses yang berbeda untuk rekayasa perangkat lunak telah diusulkan, dan masing-masing mengungkapkan kelemahan dan kekuatan mereka, yang semuanya memiliki sederetan fase generic secara umum.

DAFTAR PUSTAKA
[NAU69] Naur, P., dan B. Randall (eds), Rekayasa perangkat lunak: A Report on a Confrence Sponsored by the NATO Science Committee, NATO, 1969.
[IEE93] IEEE Standards Collection: Rekayasa perangkat lunak, IEE Standard 610.12-1990, IEE, 1993.
[PAU93] Paulk, M. Et al., Capability Maturity Model for Software, Rekayasa perangkat lunak Institute, Carnegie Mellon University, Pittsburgh, PA, 1993.
[KER94] Kerr, J., and R. Hunter, Inside RAD, McGraw-Hill, 1994.
[BUT94] Butler, J., “Rapid Aplication Development in Action”, Managing System Development, Applied Computer Research, Vol. 14, No. 5, Mei 1994, h. 6-8.
[BAN95] Bandinelli, S. Et al., “Modelling and Improving an Industrial Software Process”, IEEE Tranx, Rekayasa perangkat lunak Vol. 21, No. 5, Mei 1995, h. 440-454.
[BOE88] Boehm, B., “A Spiral Model for Software Development and Enchancement”, Computer, Vol. 21, No. 5 Mei 1988, h. 61-72.
[DAV95] Davis, M.J.,”Process and Product: Dichotomy or Duality”., Rekayasa perangkat lunak Notes, ACM Press, Vol. 20, No. 2, April 1995, h. 17-18.
[MIL87] Mills, H.D., M. Dyer, dan M. Linger,”Cleanroom Rekayasa perangkat lunak”, IEE Software, September 1987, h. 19-25.
[NIE92] Nierstrasz, “Component-Oriented Software Development”, CACM, Vol. 35, No. 9, September 1992, h. 160-165.