Requirements engineering merupakan tahapan yang sangat penting dari proses software engineering (rekayasa perangkat lunak), karena software requirements adalah suatu bentuk definisi kebutuhan customer dan  user yang berhubungan dengan transformasi system kerja mereka untuk dijadikan software. Dimana definisi kebutuhan itu sangat perlu diorganisasi dan disepakati bersama antara customer dan pengembang software.

Banyak para software developer gagal mengembangkan software karena salah  menafsirkan kebutuhan yang diinginkan oleh customer. Kesalahan penafsiran kebutuhan customer dapat dari berbagai sudut, seperti: kurangnya mengerti proses bisnis yang berjalan, kurang lengkapnya informasi yang diterima saat survey, dan adanya perbedaan informasi yang diperoleh dari berbagai sumber dalam suatu organisasi tersebut.

Untuk menghindari hal tersebut, maka perlu dilakukan suatu pendekatan yang akan memperkecil kegagalan dari suatu proses pengembangan suatu software. Maka seluruh definisi dan spesifikasi software requirements customer harus didokumentasikan dan disetujui oleh kedua belah pihak – customer dan software developer. Sebelum kesepakatan dicapai, software developer bisa membuat definisi dan spesifikasi software requirements berulang kali sampai semua yang diperlukan bisa di-cover atau setidaknya pendekatannya – tetapi disepakati.

Untuk mencapai kesepakatan tersebut perlu adanya tawar-menawar antara customer dan software developer yang dalam requirements engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and verification. Formula ini dikenal dengan nama The Three Dimensions of Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya umpan balik dari customer.

Requirements Elicitation

Requirements Elicitation adalah proses mengumpulkan dan memahami masalah dan kegiatan yang berjalan. Pada proses ini biasanya dilakukan dengan observasi terhadap lingkungan proyek yang akan digarap – termasuk fact gathering, wawancara pada pengguna langsung atau para menajer, dan bisa juga dengan mempelajari alur kerja yang terjadi dari bisnis proses yang berjalan. Biasanya proses ini dilakukan dengan terus menerus dengan jangka waktu tertentu sehingga keselarasan akan pemahaman suatu permasalahan bisa tercapai.

Requirements Specification

Jika seluruh kegiatan dan permasalah yang terjadi pada bisnis proses yang berjalan dimengerti dengan baik, maka software developer akan menkonversikan ke dalam suatu bentuk laporan tertulis yang berisi tentang semua definisi dan spesifikasi dari seluruh kebutuhan yang ada pada bisnis proses yang ada.

Requirements Validation and Verification

Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha: Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis. Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar. Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.

REFERENSI
Romi Satria Wahono,  Menyegarkan Kembali Pemahaman tentang Requirement Engineering, www.romisatriowahono.net, 2006.

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.

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

1. 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:

1. keterlibatan user secara langsung
2. pengujian

3.       pay-as-you-go design

Adapun empat nilai penting dari XP

1. 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.
2. 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.
3. Feedback : setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. 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

Hal yang perlu diperhatikan dalam pencapaian kesuksesan bisnis adalah bahwa dalam melakukan proses tersebut perlu definisi lingkup yang tertentu, jelas dan sesuai pada bidangnya, sehingga keselarasan strategi bisnis dan teknologi informasi dapat dicapai. Kegagalan pencapaian kesuksesan bisnis, salah satu alasannya adalah kurangnya selarasan strategi bisnis dan teknologi informasi, dimana perhatian terlalu focus pada teknologi, sedangkan aspek-aspek lain seperti bisnis, manajemen, dan isu organisasi itu sendiri terabaikan. Sehingga tujuan membangun suatu struktur organisasi dan proses bisnis yang merefleksikan strategi perusahaan yang saling mengisi serta pemanfaatan teknologi informasi yang seimbang bisa gagal. Mengingat hubungan teknologi informasi dan strategi perusahaan secara signifikan sangat mempengaruhi daya saing dan efisiensi bisnis. Oleh karena itu, hal yang paling penting adalah bagaimana teknologi informasi mampu memberikan support yang signifikan, kompetitif dan strategis untuk memberikan keuntungan pada perusahaan.

Hampir di seluruh belahan dunia dewasa ini sedang mengalami perubahan di berbagai aspek seperti, politik, ekonomi, lingkungan dan sosial. Demikian juga di dunia bisinis sedang mengalami perubahan yang sangat cepat dan signifikan, antara lain :

1. Perubahan yang mengarah pada transformasi bisnis dengan konsep baru dan sangat berbeda.

2. Perubahan akibat penggunaan teknologi informasi yang memberikan pengaruh terhadap selurh kegiatan bisnis.

3. Akibat perubahan di atas, diperlukan penyelarasan antara strategi bisnis dan strategi teknologi informasi.

1. Diperkenalkannya suatu metoda yang digunakan oleh Hak cipta 1993 oleh International Business Machines Corporation. Pengcopian dalam bentuk formulir/cetakan untuk penggunaan pribadi, diijinkan dan tanpa pembayaran royalti asalkan sesuai dengan ketentuan yang telah ditetapkan.
2. Strategi bisnis dan revisi perencanaan teknologi informasi, menggambarkan bagaimana menerapkan kerangka keselarasan strategi untuk mengidentifikasi metoda yang sesuai dengan yang dipakai untuk mentransformasikan perusahaan. Objektifitas yang akan disajikan oleh metodan dan bagan adalah harus menerapkan pengetahuan serta teknologi untuk mempercepat perubahan dari perusahaan menjadi organisasi sukses yang berkesinambungan dimasa depan.

 Penggunaan software dewasa sudah sangat luas, hal ini menunnjukan bahwa pengembangan software yang terus menerus mulai memperlihatkan hasilnya. Adalah suatu jenis soaftware yang belakangan in isangat populer dikalangnan bisnis. Sebut saja ERP (Enterprise Resources Planning), yaitu suatu software lengkap yang biasa digunakan untuk keperluan bisinis. Dimana software ini pada awalnya dirancang untuk mendekati suatu system bisnis dari perusahaan yang sekup besar dengan harga yang sangat besar pula. Tetapi dengan berjalannya perkembangan software tersebut dan lirikan pangsa pasar dari beberapa pengembang, maka beberapa software ERP system berusaha terus dirampingkan secara lingkup dengan kemampuan yang tetap diupayakan tetap mendekati aslinya. Dengan tujuan untuk dapat dijangkau oleh perusahaan menengah ke bawah.

Banyak software ERP system yang ditawarkan di pasaran, tetapi yang sangat populer adalah SAP. SAP adalah suatu softwareterintegrasi dari hampir seluruh bidang bisnis. Mulai dari system informasi pemasaran, produksi atau jasa, hrd sampai akunting. Jadi sangat jelas bahwa system informasi dalam suatu bisnis yang lengkap bisa di-cover. Selain itu kehandalannya tidak dapat diragukan lagi. Oleh karena itu maka harganya pun sangat mahal.

Berbicara masalah Software ERP dengan harga yang relative mahal, dan berkembangnya dan dorongan menggunakan software-software yang open source terutama di Indonesi, maka ada baiknya kita juga memanfaatkan suatu software ERP yang open source yang mungkin membutuhkan biaya yang relative lebih ringan – sebut saja COMPIERE [ http://www.compiere.org ].

Jadi sebetulnya tren penggunaan software-software berbasis open source tidak perlu dikhawatirkan. Sudah sangat banyak aplikasi yang dibangun dan bisa mendukung keberadaan open source – system operasi dan berbagai aplikasi.

Maka ada baiknya kita mulai hijrah dalam penggunaan software ke open source.