Oleh : Heri Juhari
Membangun software komputer adalah suatu proses pembelajaran iteratif, dan hasilnya adalah apa yang Baetjer sebut software capital, yang merupakan koleksi dari knowledge, disaring, dan diorganisasi sebagai proses yang dijalankan.
Apakah proses itu?
Saat membuat suatu produk atau sistem, hal yang paling penting untuk menjalankan suatu rangkaian dari langkah-langkah yang dapat diprediksi—suatu peta yang dapat membantu membentuk produk secara tepat waktu, hasil yang berkwalitas tinggi. Peta yang dimaksud disebut proses software.
Siapa yang mengerjakannya?
Software engineer dan managernya mengadaptasi proses menjadi kebutuhan dan mengikutinya. Dan juga, orang yang mempunyai permintaan software yang menjalankan tugas dari proses software.
Mengapa proses penting?
Karena proses menyajikan stabilitas, mengontrol, dan meng-organisasi suatu aktifitas yang ada yang jika dilakukan tanpa control akan menjadi kacau.
Apa langkah-langkahnya?
Pada level detail, proses yang diadopsi tergantung pada software dibangun. Langkah-langkah suatu proses bisa berbeda-beda sesuai dengan peruntukan software itu sendiri, misalnya langkah proses untuk suatu sistem aircraft avionics akan berbeda dengan proses pembuatansuatu Situs web.
Apa pekerjaan produk?
Dari sudut pandang software engineer, pekerjaan produk adalah program, dokumen, dan menghasilkan data sebagai konsekuensi dari aktivitas software engineering yang didefinisikan oleh proses.
Bagaimana cara memastikan bahwa kita sudah melakukannya dengan benar?
Banyak software melakukan mekanisme penilaian yang memungkinkan organisasi menentukan kematangan proses software. Bagaimanapun kwalitas, ketepatan waktu, dan kelangsungan hidup jangka panjang dari produk yang dibangun merupakan indikator terbaik dari keampuhan proses yang dipakai.
Tetapi apa sebenarnya proses software dari suatu sudut pandang teknis?
Dalam konteks tulisan ini, didefinisikan bahwa suatu proses software sebagai suatu kerangka tugas yang diperlukan untuk membangun software yang berkwalitas. Apakah proses sama dengan software engineering? Jawabnya bisa ya dan tidak. Proses software mendefinisikan suatu pendekatan yang diambil sebagai software yang direkayasa. Tetapi software engineering juga meliputi teknologi dengan populasi proses – metoda teknis dan tools otomatis.
Hal yang lebih penting adalah software engineering dilaksanakan oleh kreatif, orang yang ker-knowledge yang bekerja dalam suatu definisi dan kematangan proses software sesuai dengan produk yang dibangunnya dan permintaan pasar. Tujuan tulisan ini adalah sebagai sarana survey dari keadaan sebenarnya tentang proses software dan petunjuk diskusi yang lebih rinci dari topik tentang manajemen dan teknis yang dipresentasikan kemudian.
2.1 SOFTWARE ENGINEERING: SUATU LAYER TECHNOLOGY
Banyak author yang telah mengembangkan definisi tersendiri dari software engineering, tetapi definisi yang diajukan Fritz Bauer [NAU69] pada konferensi yang mungkin berkembang pada subjek yang masih bertindak sebagai bahan diskusi:
[Software engineering adalah] penetapan dan penggunaan prinsip-prinsip engineering untuk memperoleh nilai secara ekonomis dari software yang reliable dan bekerja secara efisien pada mesin riil.
Hampir setiap pembaca akan tertarik untuk menambah definisi sekecil apapun yang menyangkut aspek teknis dari kwalitas software; tidak secara langsung menunjuk pada kebutuhan akan kepuasan pelanggan atau penyerahan produk secara tepat waktu; hal itu menghilangkan pentingnya ukuran dan metric dan tidak menetapkan dan menggunakan prinsip-prinsip engineering untuk memperoleh software secara ekonomis yang menyatakan pentingnya suatu proses yang matang. Tetapi definisi Bauer menggarisbawahi. Apakah yang dikatakan prinsip engineering dapat diaplikasikan untuk pengembangan software komputer? Bagaimana caranya kita membangun software secara ekonomis tetapi reliable? Apa yang diperlukan untuk menciptakan program komputer yang bekerja secara efisien tidak hanya satu tetapi di banyak mesin riil yang berbeda? Ini adalah pertanyaan yang merupakan tantangan bagi para software engineer.
IEEE [IEE93] telah mengembangkan suatu definisi yang lebih universal pada keadaan :
Software Engineering, adalah :
(1) Aplikasi yang pendekatannya secara semantik, disiplin, yang dapat dihitung untuk pengembangan, operasional, dan pemeliharaan software; seperti, aplikasi dari engineering software.
(2) Studi dari pendekatan pada poin (1).
2.1.1 Proses, Metoda, dan Tools
Software engineering adalah suatu layer teknologi. Mengacu Gambar 2.1, beberapa pendekatan engineering (termasuk software engineering) harus berlandasakan pada komitmen organisasi tentang mutu. Manajemen mutu total dan filosofi yang sama akan membantu pengembangan suatu proses yang kontinu untuk perbaikan kultur, dan selanjunya kultur inia akan membawa pengembangan ke arah peningkatan pendekatan yang lebih mapan dari software engineering. Landasan yang mendukung software engineering adalah fokus pada mutu.
Gambar 2.1 Software Engineering Layers
Dasar software engineering adalah layer proses. Proses software engineering merupakan pemersatu layer-layer dalam teknologi dan memungkinkan mengembangkan software computer secara rasional dan tepat waktu. Proses menggambarkan suatu kerangka kerja dari key process areas (KPAs) [PAU93] yang harus dibentuk untuk penyelesaian teknologi software engineering yang efektif. Area pemrosesan kunci merupakan bentuk dasar bagi manajemen kontrol proyek software dan menentukan konteks dari metoda teknis yang diterapkan, pekerjaan produk (model, dokumen, data, laporan, form, dll.) yang dihasilkan, milestones yang dibentuk, kepastian mutu, dan perubahan secara baik dan teratur.
Metoda software engineering menyediakan cara-cara teknis – bagaimana membangun software. Metoda tersebut meliputi rangkaian tugas yang besar – termasuk analisis kebutuhan, desain, membuat program, uji coba, dan support. Metoda software engineering berlandaskan pada prinsip-prinsip dasar pengelolaan masing-masing area teknologi dan termasuk aktifitas modeling dan teknik deskripsi lainnya.
Tools software engineering adalah bagian yang men-support secara otomatis mau pun semi otomatis untuk proses dan metoda. Jika tools diintegrasikan sehingga informasi yang dibuat dengan menggunakan tools lain maka sistem yang men-support pengembangan software tersebut biasa disebut computer-aided software engineering (CASE). CASE merupakan gabungan antara software, hardware, dan database software engineering (sebagai tempat penyimpanan informasi penting tentang analisa, desain, construction program, dan testing) untuk membentuk analogi software engineering environment pada CAD/CAE (computer aided design/engineering) untuk hardware.
2.1.2 Pandangan Umum pada Software Engineering
Engineering adalah analisa, desain, konstruksi, verifikasi, dan manajemen teknis (atau sosial) entitas. Dengan mengabaikan entitas untuk di-engineer maka ada beberapa pertanyaan sbb:
· Apa masalah yang akan dipecahkan?
· Apa karakteristik dari entitas yang digunakan untuk memecahkan masalah?
· Bagaimana entitas (dan solusi) yang akan direalisasikan?
· Bagaimana entitas yang dikonstruksi?
· Pendekatan apa yang akan dipakai untuk error yang tidak di-cover pada pembuatan desain dan construction dari entitas?
· Bagaimana entitas akan di-support sampai jangka panjang, saat koreksi, adaptasi, dan peningkatan sesuai diminta oleh user dari entity.
Pada bagian ini hanya akan dibahas pada entitas tunggal, yaitu software komputer. Software engineer harus mendefinisikan suatu proses software engineering. Tetapi dalam hal ini, hanya karakteristik proses software yang sifatnya umum yang akan dibicarakan, sedangkan karakteristik yang lebih spesifik dari model proses akan dibahas kemudian.
Pekerjaan yang berhubungan dengan software engineering dapat digolongkan menjadi tiga tahapan umum, dengan mengabaikan area aplikasi, ukuran proyek, dan kompleksitasnya. Masing-masing tahapan ditujukan pertanya di atas.
Tahapan definisi fokus pada pertanyaan apa. Jadi selama definisi, software engineer berusaha mengidentifikasi informasi apa yang akan diproses, fungsi dan kinerja apa yang diinginkan, perilaku sistem apa yang dapat diharapkan, apakah interface menjadi mapan, apakah ada kendala saat mendesain, dan apa kriteria validasi yang diperlukan untuk mendefinisikan sistem agar menjadi sukses. Kunci requirements dari sistem dan software perlu diidentifikasi. Meskipun metoda yang diterapkan selama tahap definisi akan berubah-ubah tergantung dari paradigma (atau kombinasi paradigma) software engineering yang diterapkan, tiga tugas utama yang terjadi dalam form adalah engineering sistem atau informasi, perencanaan proyek software , dan analisa requirement.
Tahap development fokus pada bagaimana. Selama pengembangan, software engineering berusaha mendefinisikan bagaimana supaya data bisa tersusun, bagaimana fungsi diimplementasikan dalam arsitektur software, bagaimana rincian prosedural yang diimplementasikan, bagaimana interface yang menjadi karakteristik, bagaimana desain akan diterjemahkan ke dalam bahasa pemrograman (atau bahasa nonprosedural), dan bagaimana testing akan dilaksanakan. Metoda yang diterapkan selama tahap pengembangan akan berubah, tetapi tiga tugas teknis yang spesifik terdiri: desain software, code generation, dan software testing.
Tahap support focus pada perubahan yang berhubungan dengan koreksi kesalahan, adaptasi yang diperlukan sampai tahap software environment, dan melakukan perubahan sampai ditemukan kesesuaian dengan apa yang dibutuhkan customer. Tahap support menggunakan langkah-langkah yang terjadi pada tahap definisi dan pengembangan hanya saja dalam konteks dari software yang telah ada. Empat jenis perubahan yang ditemui selama tahap support adalah:
Koreksi. Merupakan aktifitas untuk menjamin mutu dari software, ada kemungkinan customer menemukan error yang tidak dapat ditangani. Maka perlu perawatan korektif untuk mengoreksi kerusakan software.
Adaptasi. Dengan berjalannya waktu environment yang ada (seperti, CPU, sistem operasi, kebijakan bisnis, karakteristik produk eksternal) bisa mengakibatkan software yang dikembangkan berubah. Pemeliharaan untuk menyesuaikan akan mengakibatkan modifikasi software untuk mengakomodasi perubahan environment eksternal.
Enhancement. Software yang digunakan oleh customer/user akan memerlukan fungsi tambahan untuk meningkatkan kegunaannya. Penanganan pemeliharaan bisa saja meluas sampai di luar software yang requirement fungsional didefinisikan.
Pencegahan. Fungsi software bisa menurun karena terjadi berubah, oleh karena itu diperlukan pemeliharaan pencegahan, sering disebut software reengineering. Hal ini harus dilakukan untuk menjaga agar software tetap memenuhi kebutuhan end user. Pada dasarnya, pemeliharaan pencegahan membuat perubahan pada program komputer sehingga dapat lebih mudah dikoreksi, disesuaikan, dan ditingkatkan.
Aktifitas support masih terus berlanjut, dimana user masih perlu terus disupport. Asistensi teknis secara in-house, help desk via telepon, dan dukungan situs web terhadap aplikasi spesifik yang diimplementasikan meruapakan bagian dari tahapan support.
Pertumbuhan populasi program legacy memaksa banyak perusahaan untuk melakukan strategi software reengineering. Secara umum software reengineering sering dipertimbangkan sebagai bagian dari business process reengineering.
Tahapan dan hubungan langkah-langkah yang telah diuraikan secara umum tentang software engineering dilengkapi oleh sejumlah aktifitas, seperti:
- Tracking dan kontrol projek software
- Review technical secara formal
- Jaminan kwalitas software
- Manajemen konfigurasi software
- Persiapan dokumentasi dan produksi
- Manajemen daur ulang
- Ukuran
- Manajemen risiko
2.2 PROSES SOFTWARE
Secara umum proses software dapat digambarkan seperti pada Gambar 2.2. Framework proses secara umum disusun oleh sekumpulan aktivitas framework yang lebih kecil yang digunakan untuk semua projek software, tanpa meninjau ukuran atau kompleksitasnya. Setiap aktivitas framework terdiri dari sejumlah tugas dari software engineering yang mempunyai batasan sesuai milestone proyek, produk pekerjaan, dan jaminan mutu – memungkinkan aktivitas framework diadaptasi untuk karakteristik dari proyek softawre dan requirement tim proyek. Maka aktifitas perlindungan – seperti jaminan kualitas software, manajemen konfigurasi software, dan ukran-overlay model proses. Aktivitas pelindung tidak terikat pada tiap framework aktifitas dan terjadi dalam keseluruhan proses.
Gambar 2.2. Proses Software
Beberapa tahun terakhir, telah ditentukan titik berat dari kemapanan proses. Institut Software Engineering (Software Engineering Institute,SEI) telah mengembangkan model yang berlaku secara umum dari kumpulan kemampuan software engineering yang harus disajikan sebagai jangkauan organisasi dari tingkat yang berbeda dari kemapanan proses. Untuk menentukan keadaan kemapanan proses organisasi yang ada, SEI menggunakan suatu penilaian yang hasilnya lima poin tingkat skema. Tingkat skema yang menentukan keberhasilan dengan suatu kemampuan model mapan (Capability Maturity Model, CMM) [PAU93] yang mendefinisikan aktifitas kunci yang diperlukan pada tingkat yang berbeda dari kemapanan proses. Pendekatan SEI menyediakan suatu ukuran dari efektifitas yang sifatnya global dari praktisi perusahaan software engineering dan menetapkan lima tingkat kemapanan proses yang didefinisikan sbb:
Tingkat 1: Inisial. Proses software ditandai sebagai sesuatu yang khusus dengan suatu maksud tetapi adakalanya hasilnya menjadi kacau. Sedikit; beberapa proses didefinisikan dan sukses tergantung dari usaha individu.
Tingkat 2: Pengulanagn. Dasar proses manajemen proyek yang mapan untuk menghitung biaya, penjadwalan, dan fungsi. Disiplin proses yang perlu ialah penempatan pengulangan kesuksesan lebih awal dari proyek dengan aplikasi yang sama.
Tingkat 3: Definisi. Proses softaware baik untuk aktifitas manajemen maupun engineer perlu didokumentasikan, distandardisasi, dan terintegrasi dalam suatu organisasi yang besar dari proses software. Semua proyek menggunakan suatu dokumentasi dan proses organisasi yang disetujui untuk pengembangan dan support software. Tingkat ini termasuk semua karakteristik yang didefinisikan untuk tingkat 2.
Tingkat 4: Pengelolaan. Memerinci ukuran proses software dan kwalitas produk yang dikumpulkan. Baik proses software maupun produk secara kwantitatif dipahami dan dikendalikan menggunakan rincian ukuran. Tingkat ini termasuk semua karakteristik yang didefinisikan untuk tingkat 3.
Tingkat 5: Optimasi. Perbaikan proses yang kontinu dimungkinkan oleh umpan balik yang kwantitatif dari proses dan uji inovatif ide dan teknologi. Tingkat ini termasuk semua karakteristik yang didefinisikan untuk tingkata 4.
Lima tingkatan yang didefinisikan SEI berasal dari suatu konsekuensi dari evaluasi respon yang diperoleh dari questioner penilaian SEI yang didasarkan pada CMM. Hasil questioner disaring menurut tingkat angka yang memberikan indikasi dari proses organisasi yang mapan.
SEI berhubungan area proses kunci (KPA) dengan masing-masing tingkat kemapanan. KPA menjelaskan fungsi software engineering (missal: perencanaan projek software, manajemen requirement) yang harus ada untuk memenuhi praktek yang baik pada tingkat tertentu. Masing-Masing KPA digambarkan dengan mengidentifikasi ciri-ciri sbb.:
· Sasaran — seluruh sasaran yang KPA harus mencapai.
· Komitmen — requirement (yang dibebankan pada organisasi) yang harus mencapai sasaran atau menyediakan bukti dari tujuan untuk mematuhi sasaran.
· Kemampuan — berbagai hal yan harus ditempatkan (secara organisasi dan teknis) yang memungkinkan organisasi mencapai komitmen.
· Actifitas — tugas spesifik yang diperlukan untuk mencapai fungsi KPA.
· Metoda untuk memonitor implementasi — cara yang dipakai memonito aktifitas seperti yang ditempatkan didalamnya.
· Metoda untuk verifikasi implementasi — cara praktis yang untuk membuktikan KPA.
Delapan Belas KPA (menjelaskan karakteristik masing-masing) digambarkan dengan model kemapanan dan pemetaan dalam tingkat yang berbeda dari kemapanan proses. Berdasarkan KPA harus dicapai masing-masing proses kemapanan tongkat:
Kematangan proses tingkat 2
• Manajemen konfigurasi software
• Jaminan kualitas software
• Manajemen subkontran software
• Penelusuran dan peninjauan proyek software
• Perencanaan proyek software
• Manajemen requirement
Kematangan proses tingkat 3
• Review rujukan
• Koordinasi antar group
• Enginnering produk software
• Manajemen software terintegrasi
• Training program
• Definisi organisasi proses
• Fokus organization proses
Kematangan process tingkat 4
• Manajemen kwalitas software
• Manajemen kwantitatif proses
Kematangan process tingkat 5
• Manajemen perubahan proses
• Manajemen perubahan teknologi
• Pencegahan defect
Setiap KPA didefinisikan oleh satu set kunci praktis yang berperan untuk mencapai sasaran. Kunci praktis merupakan kebijakan, prosedur, dan aktifitas yang terjadi sebelum KPA secara penuh dimulai. SEI mendefiniskan indikator kunci sebagai kunci praktis atau komponen dari kunci praktis yang menawarkan pengertian yang lebih mendalam apakah sasaran dari suatu area pemrosesan kunci telah dicapai.” Pertanyaan penilaian dirancang untuk memeriksa untuk keberadaan (atau kekurangan) dari suatu indikator utama.
2.3 SOFTWARE PROCESS MODELS
Model proses software masih terus diteliti, tapi sampai saat ini ada banyak model umum atau paradigma yang berbeda dari pengembangan software, antara lain:
1. Pendekatan Waterfall
Merupakan rangkaian aktivitas proses disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain software, uji coba dst. Setelah setiap langkah didefinisikan sampai diselesaikan, dan pengembangan dilanjutkan ke langkah berikutnya.
2. Pengembangan secara evolusioner
Pendekatan ini dilakukan dengan menyisipkan antar aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dikembangkan dengan cepat untuk customer, dimana sistem yang diproduksi diharapkan bisa memenuhi kebutuhan customer. Sistem yang disampaikan tersebut, mungkin perlu diimplementasikan ulang dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable.
3. Transformasi formal
Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program tertentu. Transformasi ini berisfat correctness preserving yang berarti bahwa tingkat kesesuaian program yang dikembangkan disbanding dengan spesifikasinya hampir dipastikan sama.
4. Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali (reuse).
Teknik ini memanfaatkan bagian-bagian sistem sudah tersedia yang kemudian digabungkan. Proses pengembangan sistem ini lebih fokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.
Dalam pengembangan system, dua pendekatan yang pertama yaitu waterfall dan pengembangan evolusioner, saat ini paling sering digunakan. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi masih teruss diteliti.
Metode reuse umumnya dipakai di jepang, Eropa dan Amerika Utara. Bagaimanapun juga reuse masih terus diteliti, jadi sulitlah dikatakan keefektifannya. Selain itu, saat ini juga diperkenalakn model-model proses hasil pengembangan seperti Agile modelling, XP (Xtreeme Programming), RUP, dan MSF.
a. Waterfall/Linear Sequential Model
Model ini mrupakan model klasik yang bersifat sistematis, berurutan dalam membangun software. Ada dua gambaran tentang waterfall model, dimana nama fase-fasenya berbeda, tetapi inti prosesnya sama
Fase-fase dalam Waterfall Model menurut referensi Pressman:
Gambar 2.3a. Waterfall/Linear Sequential Model
Fase-fase dalam Waterfall Model menurut referensi Sommerville:
Gambar 2.3a. Waterfall/Linear Sequential Model
Dimodelkan setelah siklus engineering konvensional, model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut:
1. Rekayasa dan pemodelan system (informasi)
Adakalanya Sistem merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membentuk syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan software tersebut. Pandangan sistem ini penting saat software harus berhubungan dengan elemen-elemen lain seperti software, manusia, dan database. Rekayasa dan analisa sistem menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisa serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.
2. Analisa kebutuhan Software
Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, perilaku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan ditinjau bersama customer.
- Desain
Desain software sebenarnya adalah proses multi langkah yang fokus pada empat atribut sebuah program yang berbeda, yaitu 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 presentasi program. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.
- Pembuatan Program ( Koding )
Desain harus diterjemahkan kedalam bentuk yang bisa dibaca dan dimengerti oleh mesin. Langkah ini merupakan tugas dalam pembuatan program (kode). Jika desain dilakukan dengan cara yang lengkap, pembuatan program dapat diselesaikan secara mekanis.
5. Pengujian
Sekali program dibuat, selanjutnya pengujian program dimulai. Proses pengujian fokus pada logika internal software, yaitu memastikan bahwa semua statement sudah diuji, dan fungsi secara eksternal, yaitu mengarahkan pengujian untuk mencari kesalahan dan memastikan bahwa input yang terbatas akan memberi hasil aktual yang sesuai dengan hasil yang dibutuhkan.
6. Pemeliharaan ( Maintenance )
Software akan mengalami perubahan setelah diimplementasikan pada customer (kecuali software lain yang perbantukan). Perubahan akan terjadi akibat kesalahan tertentu, karena software harus disesuaikan untuk mengakomodasi perubahan di lingkungan eksternal (misal perubahan yang ditimbulkan oleh peripheral atau sistem operasi baru), atau customer perlu mengembangkan fungsi atau kinerja program. Pemeliharaan software menggunakan fase-fase sebelumnya dan tidak membuat program baru lagi.
Kerugian waterfall :
1. Perubahan sulit dilakukan karena sifatnya yang kaku.
2. Karena sifatnya yang kaku, model ini cocok saat kebutuhan dipetakan secara utuh sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali customer yang bisa memberikan kebutuhan secara lengkap, karena perubahan kebutuhan adalah sesuatu yang wajar terjadi.
3. Waterfall umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa sub-proyek.
b. Evolutionary Software Process Model
Model ini bersifat iteratif/perulangan, yaitu hasil proses berupa produk yang makin lama makin lengkap sampai menghasilkan versi lengkap sebagai produk akhir proses. Dua model dalam evolutionary software process model adalah:
1. Incremental Model
Gambar 2.4a. Incremental Model
Keterangan:
1. Kombinasikan elemen-elemen dari waterfall dengan sifat iterasi/perulangan.
2. Elemen-elemen 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. Demikian seterusnya sampai semua spesifikasi memenuhi kebutuhan yang ditetapkan customer.
3. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau direview/pengecekan detil. Hasil review tersebut menjadi dasar pembangunan pada increment berikutnya. Proses ini terus dikerjakan sampai produk dianggap komplit.
4. Model ini cocok jika jumlah anggota tim pengembang relative sedikit.
5. Mempunyai kemampuan mengakomodasi perubahan secara fleksibel.
6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.
Kerugian Incremental model:
1. Hanya cocok untuk proyek berukuran kecil (tidak lebih 200.000 baris coding)
2. Terjadi kesulitan untuk memetakan kebutuhan customer ke dalam rencana spesifikasi masing-masing hasil increment
2. Spiral model
Gambar 2.4b. Spiral Model
Proses digambarkan sebagai spiral, dimana setiap loop mewakili satu fase dari software process. Loop paling dalam fokus pada kelayakan sistem, loop selanjutnya tentang definisi kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :
1. Objective setting : menentukan tujuan yang ingin dicapai, mendefinisikan proses dan produk yang diharapkan,melakukan perencanaan, mengetahui resiko yang akan ditimbulkan dan mencari alternatif strategi berdasarkan resiko yang mungkin timbul dan sudah direncanakan.
2. Risk assessment and reduction (menilai dan pengurangan resiko): setiap resiko dianalisa secara rinci. Selanjutnya dilakukan penanganan, misalnya membuat prototype untuk mengetahui ketidak-cocokan kebutuhan.
3. Development and validation (pembangunan dan pengujian): setelah evaluasi resiko, selanjutnya memilih model pengembangan sistem apa yang akan digunakan. Jika model resiko user interface dominant yang akan digunakan, maka perlu dibuat prototype User Interface. Tetapi jika bagian keamanan yang bermasalah, maka gunakan model formal dengan perhitungan matematis. Sedangkan bila integrasi sistem jadi masalah, maka model waterfall-lah yang cocok digunakan.
4. Planning: proyek dievaluasi serta diputuskan untuk terus ke fase loop berikutnya atau tidak. Jika dilanjutkan, maka buatlah rencana loop selanjutnya.
Salah satu bentuk variasi pembagian sektor pada model spiral dapat dikembangkan seperti pada gambar di bawah ini:
Gambar 2.4c. Variasi Model Spiral
Customer communication: membangun komunikasi yang baik dengan customer.
Planning: mendefinisikan sumber, batas waktu, informasi lain seputar proyek.
Risk analysis: identifikasi manajemen resiko dan teknis.
Engineering: membangun contoh aplikasi, misalnya prototype
Construction and release : pembangunan, test, install dan support.
Customer evaluation: mendapatkan feedback dari customer beradasarkan evaluasi pada fase engineering dan instalasi.
Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistis untuk proyek berskala besar. Customer dan developer bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian moderl ini memerlukan waktu yang cukup lama dan tentu menimbulkan cost yang besar.
c. Transformasi formal
Metode ini didasarkan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda untuk program yang dapat dieksekusi. Trasformasi menyatakan spesifikasi program yang menggunakan pendekatan Cleanroom untuk pengembangan Software
Gambar 2.5. Transformasi formal
Metode ini mempunyai keterbatasan dalam pemakaiannya. Keunggulannya adalah dapat mengurangi kesalahan pada sistem sehingga penggunaan utamanya adalah pada sistem yang kritis dan memerlukan cost yang relatif lebih kecil. Pemakaian model pengembangan formal memerlukan tingkat kerahasian sebelum digunakan.
Permasalahan dalam model pengembangan metode formal:
1. Memerlukan keahlian khusus dan pelatihan untuk mengaplikasikannya
2. Sulit menentukan beberapa aspek dari suatu sistem seperti user interface
d. 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
Gambar 2.6. Penggunaan ulang
MODEL RAPID APLICATION DEVELOPMENT
Rapid Aplication Development (RAD) adalah sebuah model proses pengembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi kecepatan tinggi dari model sekuensial linier dimana penembangan 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 yang terjadi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang berhak menerbitkannya? Ke mana informasi itu diarahkan? Siapa yang memprosesnya?
2. Data modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling diseleksi untuk memperoleh serangkaian objek data yang dibutuhkan untuk men-support bisnis. Karakteristik (atribut) masing–masing objek diidentifikasi dan hubungan antar objek juga didefinisikan.
3. Prosess modeling
Aliran informasi yang didefinisikan pada 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. Aplication generation
RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan software dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses dengan memkai lagi komponen program yang ada (pada saat yang memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, tools dipakai untuk memfasilitasi pembuatan software.
5. Testing and turn-over
Karena proses RAD menekankan pada pemakaian ulang, banyak komponen program telah diuji, maka hal ini akan mengurangi waktu pengujian. Tetapi komponen baru harus diuji dan semua interface harus dososialisasikan dulu.
Gambar 2.7. Rapid Application Development Model
Kekurangan model RAD adalah :
1. Bagi proyek yang berskala besar, tetapi RAD memerlukan sumber daya manusia yang memadai untuk menciptakan sejumlah tim yang baik.
2. RAD menuntut pengembangan dan customer memiliki komitmen dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.
Prototyping Model
Gambar 2.7. Rapid Application Development Model
Kadangkala klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Dilain pihak tim developer tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi ini terjadi model prototyping sangat membantu proses pembangunan software.
Proses pada model prototyping yang digambarkan di atas, dapat dijelaskan sebagai berikut:
§ Pengumpulan kebutuhan: developer dan klien membicarakan untuk menentukan tujuan umum, kebutuhan yang ada dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan 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.
Pengulangan ketiga proses terus dilakukan sampai semua kebutuhan terpenuhi. Prototype dibuat untuk memuaskan kebutuhan dan memahami kebutuhan klien. Prototype yang dibuat dapat digunakan kembali untuk membangun software denagn 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 pengembangan, 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 digunakan saat diperlukan. Jika ternyata ada kebutuhan class baru, maka class baru dibuat dengan metode berorientasi objek.
3. Bentuk 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 mampu mengurangi waktu sampai 70%.
b. Biaya produksi berkurang sampai 84% karena 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.8:
1. Domain engineering menciptakan model domain bagi aplikasi yang akan digunakan untuk menganalisa kebutuhan customer. Identifikasi, pembangunan, pengelompokan dan pengalokasikan komponen software supaya bisa digunakan pada sistem yang ada dan yang akan datang.
2. Software engineering (component-based development) melakukan analisa terhadap domain model yang sudah ditetapkan kemudian menentukan spesifikasi dan merancang berdasarkan model struktur dan spesifikasi sistem, kemudian melakukan pembangunan software dengan menggunakan komponen yang sudah ditetapkan berdasarkan analisa dan rancangan yang dihasilkan sebelumnya hingga akhirnya menghasilkan software.
Gambar 2.8. Component-based Software Engineering
Extreme Programming (XP) Model
Model proses ini diciptakan dan dikembangkan oleh Kent Beck. Model ini adalah model proses yang terbaru dalam dunia software engineering 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
3. pay-as-you-go design
Adapun empat nilai penting dari XP
- Communication : 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 juga diperhitungkan.
- Simplicity: menekankan pada kesederhanaan pengkodean: What is the simplest thing that could possibly work? Lebih baik melakukan hal yang sederhana dan dikembangkan kemudian jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
- Feedback : setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
- Courage: banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.
Gambar 2.9. Extreme Programming Model Process
Gambar 2.10. Iteration in Extreme Programming Proses Model
