Belajar Untuk Dunia Akherat

PROSES SOFTWARE ENGINEERING

I. Software Engineering

Software Engineering adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi, desain, implementasi sampai pemeliharaan setelah digunakan.

Software Engineering adalah suatu lapisan teknologi seperti ditunjukkan pada gambar 1. Beberapa pendekatan rancang-bangun atau rekayasa (termasuk software engineering) mengarah pada kwalitas. Total manajemen kwalitas dan filosofi yang serupa membantu perkembangan peningkatan kultur proses berkelanjutan, dan kultur ini pada akhirnya mengarah pada perkembangan peningkatan dengan pendekatan lebih menyeluruh untuk software engineering. Landasan yang mendukung software engineering adalah fokus pada mutu.

Gambar 1. Lapisan Software Engineering

IEEE [ IEE93] telah mengembangkan suatu definisi yang lebih menyeluruh yaitu:

Software Engineering adalah:

(1) Aplikasi yang pendekatannya sistematis, disiplin, terukur untuk pengembangan, operasi, dan pemeliharaan perangkat lunak; itu adalah, terapan dari rekayasa perangkat lunak.

(2) Studi pendekatan seperti pada (1)

· Pondasi untuk software engineering adalah lapisan proses. Proses Software Engineering adalah perekat yang memegang lapisan teknologi bersama-sama dan memungkinkan pengembangan tepat waktu dan masuk akal tentang perangkat lunak komputer. Proses menggambarkan suatu kerangka untuk satu set kunci area pemrosesan (Key Process Area / KPAS) bahwa harus dibentuk untuk penyerahan yang efektif dari teknologi Software Engineering. Area kunci pemrosesan membentuk basis bagi manajemen kendali proyek perangkat lunak dan menetapkan konteks di mana metoda teknis diterapkan, produk-produk kerja (model, dokumen, data, laporan, format, dll.) diproduksi, patok duga dibentuk, mutu dipastikan, dan perubahan diatur dengan baik.

· Metoda software engineering menyediakan teknis cara untuk membangun perangkat lunak. Metoda meliputi suatu larik yang luas tentang tugas yang meliputi analisa persyaratan, disain, konstruksi program, pengujian, dan dukungan. Metoda software engineering bersandar pada satu set prinsip dasar yang mengurus masing-masing area dari teknologi dan meliputi aktivitas pemodelan dan teknik deskriptif lain.

· Perkakas (Tools) software engineering menyediakan dukungan otomatis atau semi-otomatis untuk proses dan metoda. Kapan perkakas terintegrasi sedemikian sehingga informasi diciptakan oleh satu alat yang dapat digunakan oleh yang lain. Sistem untuk mendukung pengembangan software, disebut computer-aided software engineering,. CASE mengkombinasikan perangkat lunak, perangkat keras, dan database software engineering (suatu tempat penyimpanan berisi informasi yang penting tentang analisa, disain, konstruksi program, dan pengujian) untuk menciptakan suatu lingkungan software engineering dapat disamakan ke CAD/CAE (computer-aided design/engineering) untuk perangkat keras.

I. Hal-hal Umum Software Engineering

Rekayasa adalah analisa, desain, pembuatan, verifikasi dan manajemen teknis (atau sosial). Tanpa memandang entitas yang harus direkayasa, ada beberapa pertanyaan yang harus dijawab:

1) Masalah apa yang harus dicarikan solusinya ?

2) Apa saja karakteristik entitas yang digunakan untuk menyelesaikan persoalan tersebut.?

3) Bagaimana entitas (dan solusinya) dapat direalisasikan ?

4) Bagaimana entitas akan dibangun ?

5) Pendekatan apa yang akan digunakan untuk mencegah terjadinya kesalahan desain dan pembuatan entitas?

6) Bagaimana entitas akan didukung selama mungkin, pada saat ada permintaan koreksi, adaptasi dan pengembangan oleh user.

6)

Pekerjaan yang berhubungan dengan software engineering bisa dikategorikan ke dalam 3 fase umum tanpa memandang area aplikasi, ukuran proyek atau kompleksitas. Fase tersebut yaitu:

1) Definition Phase

2) Development Phase

3) Maintenance Phase

3)

1) Definition Phase

Selama fase ini, software developer berusaha untuk mengidentifikasi informasi apa saja yang harus diproses, apa saja fungsi dan kinerja yang digunakan, tingkah laku sistem yang diharapkan, apa saja interface yang harus dibuat, apa saja kendala desain yang ada, dan kriteria validasi yang diperlukan untuk mendefinisikan kesuksesan sistem.

2) Development Phase

Selama fase ini, pengembang software berusaha untuk mendefinisikan bagaimana data disusun, bagaimana fungsi bisa diimplementasikan sesuai dengan arsitektur software, bagaimana prosedur detil untuk implemetasi , bagaimana karakter interface, bagaimana hasil desain bisa ditranslasikan ke bahasa pemrograman dan bagaimana cara pengujiannya.

3) Support Phase

Difokuskan pada perubahan sehubungan dengan adanya koreksi kesalahan, adaptasi dan pengembangan yang dikehendaki customer.

Ada 4 tipe perubahan:

1) Correction

Mengubah software untuk memperbaiki kesalahan-kesalahan yang ada.

2) Adaption

Modifikasi yang dilakukan terhadap software dikarenakan adanya perubahan lingkungan eksternal (misal: CPU, sistem operasi, aturan bisnis, karakter produk eksternal).

3) Enhancement

Pada saat software dipakai, user meminta tambahan-tambahan fungsi. Sehingga software dikembangkan dari kebutuhan semula.

4) Prevention

Sering disebut software re-engineering, harus dilakukan untuk memungkinkan software bisa sesuai dengan keinginan end user. Pada fase ini dilakukan perubahan-perubahan pada program komputer, sehingga program tersebut bisa dikoreksi, beradaptasi dan dikembangkan dengan mudah.

Tahapan dan langkah-langkah terkait yang diuraikan dalam hal-hal umum rekayasa perangkat lunak dilengkapi dengan sejumlah payung aktivitas. Aktivitas yang khas di kategori ini meliputi:

• Panduan dan kendali proyek Perangkat lunak

• Tinjauan ulang teknis formal

• Jaminan kwalitas perangkat lunak

• Manajemen konfigurasi perangkat lunak

• Persiapan dokumen dan produksi

• Manajemen Reusabilas

• Pengukuran

• Manajemen resiko

II. Proses Perangkat Lunak

Proses perangkat lunak dapat dicirikan seperti ditunjukkan dalam gambar 2. Suatu kerangka proses yang umum dibentuk dengan penjelasan sejumlah kecil aktivitas kerangka yang digunakan pada semua proyek perangkat lunak, dengan mengabaikan kompleksitas atau ukuran perangkat lunak.

Gambar 2. Proses Software

Keterangan Gambar:

Sebuah common process framework di bentuk dengan mendefinisikan sejumlah

· framework activities yang bisa diterapkan untuk semua proyek software, tanpa memandang ukuran dan kompleksitasnya.

· Task Sets, masing-masing berisi kumpulan pekerjaan rekayasa software, project milestone, product software dan deriverable, quality assurance point.

· Dengan adanya task set ini, memungkinkan aktifitas framework diadaptasikan dengan karakteristik proyek software dan kebutuhan tim pelaksana.

· Umbrella Activities seperti software quality assurance, manajemen konfigurasi software.

I. Model Proses Perangkat Lunak

Untuk memecahkan permasalahan aktual dalam standar industri, seorang ahli perangkat lunak atau tim ahli harus memasukkan strategi pengembangan yang meliputi proses, metoda, dan lapisan perkakas (tools). Strategi ini dikenal sebagai proses model atau paradigma rekayasa perangkat lunak.

Gambar 3a. Siklus tahapan penyelesaian masalah

Gambar 3b. Siklus tahapan di dalam tahapan penyelesaian masalah

Semua pengembangan software dapat dicirikan sebagai siklus penyelesaian masalah (Gambar 3a) di mana empat langkah yang tidak dapat dipisahkan: Status quo, Problem definition, Technical development, dan Solution integration. Status quo “menunjukkan keadaan sekarang”; Problem definition “mengidentifikasi masalah yang spesifik untuk dipecahkan”; Technical development “memecahkan masalah dengan mengaplikasikan beberapa teknologi”, dan Solution integration “menyampaikan hasil (seperti dokumen, program, data, fungsi bisnis yang baru, produksi baru) ke mereka yang meminta solusi dengan kwalitas paling baik.

Siklus pemecahan masalah ini berlaku bagi pekerjaan rekayasa perangkat lunak pada beberapa tingkat perbedaan dari pemecahan. Siklus dapat digunakan di tingkat makro ketika aplikasi keseluruhan dipertimbangkan, pada tingkat menengah ketika komponen program sedang direkayasa, dan bahkan pada tingkat baris kode. Oleh karena itu, penyajian fractal dapat digunakan untuk menyediakan suatu pandangan ideal dari proses. Pada Gambar 3b, masing-masing langkah pada siklus pemecahan masalah berisi siklus pemecahan masalah yang sama, yang berisi siklus pemecahan masalah ( ini berlanjut pada beberapa batas yang masuk akal; untuk perangkat lunak, baris kode).

I. Linear Sequential Model / Waterfall Model

Model ini adalah model klasik yang bersifat sistematis, berurutan dalam membangun software. Berikut ini gambaran dari Linear Sequential Model / waterfall model.

Gambar 4. The linear sequential model

1. Software Requirements analysis: Mengumpulkan kebutuhan secara lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun. Fase ini harus dikerjakan secara lengkap untuk bisa menghasilkan desain yang lengkap.

2. Design: Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap.

3. Code generation: desain program diterjemahkan ke dalam kode-kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji baik secara unit.

4. Testing: penyatuan unit-unit program kemudian diuji secara keseluruhan (system testing).

5. Support: mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.

Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.

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

Gambar 5. The prototyping paradigm

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.

I. RAD (Rapid Application Development)

RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini.

Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.

Kelemahan dalam model ini:

1. tidak cocok untuk proyek skala besar

2. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

3. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini

4. resiko teknis yang tinggi juga kurang cocok untuk model ini

Fase-fase di atas menggambarkan proses dalam model RAD. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan.

1. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? _ kebutuhan dari system

2. Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut _ analisis kebutuhan dan data

3. Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis.

4. Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan.

5. Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji.

I. Evolutionary Software Process Models

Bersifat iterative / 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 (Original: Mills)

Gambar 7. The incremental model

1. kombinasikan element-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

1. Spiral Model

Model spiral, mula-mula diusulkan oleh Boehm, adalah suatu model proses perangkat lunak evolusiner yang bersifat iteratip berpasangan dari prototip dengan aspek yang sistematis dan terkendali dari linear sequential model.

Gambar 8. A typical 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.

1. Customer communication: membangun komunikasi yang baik dengan pengguna/customer.

2. Planning: mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek

3. Risk analysis: identifikasi resiko managemen dan teknis

4. Engineering: pembangunan contoh-contoh aplikasi, misalnya prototype

5. Construction and release : pembangunan, test, install dan support.

6. 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 perangkat lunak 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.

I. Concurrent Development Model

Concurrent development model, kadang-kadang disebut concurrent engineering. Concurrent process model dapat digambarkan secara skematik sebagai rangkaian dari kegiatan teknis utama, tugas, dan hubungan antar bagian.

Gambar 8: One element of the concurrent process model

Gambar 8 menunjukkan skematik dari satu aktivitas dengan concurrent process model. Aktivitas—Analisa— mungkin pada tiap orang mencatat bagian-bagian di setiap waktu. Dengan cara yang sama, aktivitas yang lain ( seperti, disain atau komunikasi pelanggan) dapat digambarkan dengan cara yang sama.

Concurrent process model sering digunakan sebagai paradigma untuk pengembangan aplikasi client/server. Sistem client/server terdiri atas satu set komponen yang fungsional. Ketika diaplikasikan untuk client/server, Concurrent process model menggambarkan aktivitas di dua dimensi: dimensi sistem dan dimensi komponen. Dimensi Sistem ditujukan menggunaan tiga aktivitas: disain (design), perakitan (assembly), dan penggunaan (use). Dimensi komponen ditujukan dengan dua aktivitas: disain (design) dan realisasi. Concurrency dicapai dalam jalan dua arah: (1) sistem dan komponen aktivitas terjadi secara simultan dan dapat diperagakan menggunakan pendekatan yang berorientasi status sebelumnya; (2) kekhasan aplikasi client/server adalah diterapkan dengan banyak komponen, masing-masing dapat dirancang dan direalisir secara bersamaan.

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

Gambar 9. Component based development

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:

1. siklus waktu pengembangan software, karena mampu mengurangi waktu 70%

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

I. Kesimpulan

Tentu saja untuk suatu proyek pembuatan software, pemilihan model sangat tergantung dari karakteristik proyek itu sendiri. Belum tentu satu jenis model cocok digunakan, ada kalanya harus menggunakan lebih dari satu model. Hal ini tentunya untuk mendapatkan hasil yang baik.

Daftar Pustaka

Pressman, Roger.S. "Software Engineering : A Practioner's Approach." 5th . McGrawHill. 1982.