tea's corner

live and life

Masa SMA masa yang indah. Masa remaja, bebas melakukan apa saja. Banyak sih yang bilang begitu. Udah karakter kali ya…

Bayangkan jika karakter seperti itu menemukan habitatnya selepas SMA. Bisa-bisa anggota hedonism bertambah. Dan berkali-kali lipat pastinya. Brarti harus ada tempat hiburan tuk menampung mereka. Bertambahlah kafe, pub, diskotik, dan semua hingar bingar dunia malam. Bentar bentar, koq jadi ngomongin hedonism dan dunia malam.

Sebetulnya itu hanya gambaran kecil tentang bagaimana jika kehidupan ini mengalir apa adanya. Tanpa arahan dan petunyuk, tanpa rambu-rambu, norma, dan bahkan akhlaq. Selepas SMA, bisa dikatakan masa remaja menjadi lebih indah. Kehidupan semakin bebas dengan predikat “aku lho udah 17 tahun lebih, udah dewasa khan!”. Huff, jadi inget comment yang kulayangkan ke kolega, “sebenarnya kapan sih kita disebut dewasa, dan bagaimana seorang dewasa itu bersikap?”

Masa-masa selepas SMA merupakan masa-masa dimana seseorang mencari jati diri. Pendekatan yang benar pasti memberikan hasil yang benar. Kalo istilah lainnya, orang itu benar-benar “menjadi orang”. Atas dasar inilah sebuah kegiatan kampus, yang berorientasi tidak hanya pada pendidikan (keilmuan), tetapi juga pada kehidupan, direncanakan. OKK, sebuah kegiatan berorientasi kehidupan kampus, yang digelar STIKOM Surabaya, merupakan salah satu pendekatan agar calon-calon orang ini tadi benar-benar menjadi orang.

Untuk informasi tentang OKK, mulai dari kepanitiaan, kolega, dan berbagai kegiatannya, bisa diakses disini.

Salam,
TEA

(…lanjutan dari bagian 1)

Ada 2 jenis RE, yaitu (1) user requirement, dan (2) system requirement. User requirement lebih mengutamakan pencatatan secara linguistic (natural language) disertai oleh diagram-diagram yang menggambarkan layanan sistem secara global serta batasan-batasan operasionalnya. Jenis ini ditujukan kepada stakeholder. Sedangkan system requirement merupakan dokumen terstruktur yang mendeskripsikan secara mendetil fungsi-fungsi sistem, layanan, dan batasan operasional. Dokumen ini mendefinisikan implementasi sistem yang (mungkin) merupakan  bagian kontrak antara client dengan kontraktor.

Functional requirement

Mendeskripsikan fungsionalitas atau layanan sistem. Functional requirement ini dependent pada tipe software, pengguna, dan sistem (platform). Contoh: sistem harus menyediakan antar muka untuk menampilkan dokumen, setiap pemesanan harus dialokasikan berdasarkan nomor yang unik (ORDER_ID), dll.

Non-functional requirement

Mendefinisikan properti sistem dan batasannya, misalnya reliability, response time, dan storage requirements, device capability, dll. Non-functional requirement (mungkin) lebih critical daripada functional requirement, karena jika kebutuhan ini tidak terpenuhi, dapat dikatakan bahwa software tidak layak. Ada 3 pembagian requirement disini, yaitu (1) product requirement yang berkaitan dengan reliability, usability, portability dan efficiency; (2) organizational requirement yang berkaitan dengan standar, implementasi, dan delivery; dan (3) external requirement yang berkaitan dengan interoperability, etika, privasi, dan keamanan.

Software Requirement Specification (SRS)

Seperti yang telah dijelaskan pada bagian 1, bahwa visualisasi dapat membantu porsentase penerimaan pesan, maka semua requirement harus didokumentasikan. Ada 5 macam pengguna dokumen ini:

  1. System customer. Digunakan untuk menspesifikasikan requirement dan cek apakah requirement telah memenuhi kebutuhan (need) mereka. Mereka mempunyai hak untuk melakukan perubahan dalam requirement.
  2. Manager. Menggunakan dokumen ini untuk merencanakan biaya dan system development process.
  3. System engineer. Untuk memberikan kemudahan dalam memahami sistem seperti apa yang akan di-develop.
  4. System test engineer. Menggunakan dokumen ini untuk membangun berbagai test-case untuk sistem.
  5. System maintenance engineer. Menggunakan requirement untuk membantu memahami sistem dan hubungan antar sub-sistem.

Dokumen ini sebaiknya memenuhi 6 hal berikut:

  1. Menjelaskan perilaku eksternal
  2. Menjelaskan batasan pada implementasi
  3. Mudah diubah
  4. Sebagai alat referensi untuk pemeliharaan system
  5. Mencatat peringatan awal tentang siklus dari system
  6. Menjelaskan bagaimana system merespon hal-hal yang tidak biasa

Referensi:

  1. Nuseibeh, B., Easterbrook, S.(tanpa tahun).Requirement Engineering: A Roadmap.
  2. Sommerville, Ian. 2004. Software Engineering 7th Edition. Addison Wesley. Massachusetts

NB:

Template-nya bisa di-download disini.

Bayangkan ketika kita ingin membuat potongan besi menjadi rounded-corner dengan radian 2.5 cm. Sedangkan pemotongan dilakukan dibengkel oleh teknisi. Ada saja rasa was-was kalo tidak ditunggu. Tapi kembali lagi, kita pun tidak punya banyak waktu mengurusi hal-hal seperti itu. Pemenuhan kebutuhan akan pemotongan besi, harus ditulis (dan bahkan digambarkan) secara mendetil. Tujuannya hanya satu, agar keinginan kita terpenuhi. Bagi teknisi, tulisan dan gambaran tersebut diperlukan agar mampu bekerja professional untuk memenuhi kebutuhan customer. Memang, bentuk komunikasi verbal bisa digunakan. tetapi pada titik tertentu, visualisasi dapat membantu porsentase penerimaan pesan.

Bayangkan jika masing-masing role bertindak sendiri-sendiri tanpa adanya relationship!

Dalam pengembangan perangkat lunak, terjadi hal yang sama. Hanya saja kita sebagai pakar dibidang sistem informasi, berperan sebagai professional yang mampu memberikan kepuasan bagi kebutuhan customer. Kebutuhan software (atau software requirement) tidak hanya penting bagi customer, tetapi juga bagi tim pengembang. Harus ada komunikasi dua arah dalam pemenuhan dokumentasi software requirement, contohnya wawancara dan observasi sebagai tahap awal dan dilanjutkan oleh diskusi sebagai media untuk bargain.

Software requirement merupakan gambaran dari layanan (service) dan batasan-batasan dalam pengembangan sistem. Seluruh proses yang dimulai dari penemuan, analisis, dokumentasi, dan pengujian dalam layanan dan batasan tersebut, disebut sebagai requirement engineering. Dan inilah yang menjadi tolok ukur kesuksesan (atau kualitas) software.

Seperti yang disebutkan sebelumnya, requirement engineering (RE) merupakan human-centered process. Karena itulah, RE harus sensitif terhadap persepsi user dan bagaimana user memahami lingkungannya, bagaimana user berinteraksi, dan bagaimana efek sosial (tempat kerja) mempengaruhi aksi mereka. Karena itulah, menurut Nuseibeh [1], dalam elisitasi dan pemodelan requirement ada 4 komponen yang perlu diperhatikan:

  1. Psikologi kognitif. Menyediakan pemahaman terhadap kesulitan yang mungkin dialami oleh user dalam mendeskripsikan kebutuhannya.
  2. Antropologi. Menyediakan pendekatan dalam observasi aktivitas user yang dapat membantu pengembang untuk lebih memahami bagaimana komputer (sistem) dapat membantu mereka.
  3. Sosiologi. Menyediakan pemahaman terhadap perubahan politik dan budaya yang disebabkan oleh komputerisasi.
  4. Bahasa (linguistic) menjadi penting karena RE sebagian besar adalah tentang komunikasi. Pemilihan bahasa harus mampu meminimalisasi ambiguitas dan meningkatkan pemahaman.

Selain itu, RE juga tentang bagaimana menginterpretasi dan memahami terminology, konsep, sudut pandang dan tujuan dari stakeholder. Karena itulah, RE harus mampu memahami epistemology, phenomenology, dan ontology.

(bersambung ke bagian 2)

Referensi:

  1. Nuseibeh, B., Easterbrook, S.(tanpa tahun).Requirement Engineering: A Roadmap.
  2. Sommerville, Ian. 2004. Software Engineering 7th Edition. Addison Wesley. Massachusetts

(Diambil dari tegarheru.wordpress.com)

Dalam pengukuran kualitas database, ada 4 dimensi yang meliputi proses, data, semantik, dan perilaku (behavior). Proses dalam kualitas database ditentukan sebagian besar oleh kebutuhan pada solusi bisnis. Langkah awal adalah knowledge engineering, yaitu tentang bagaimana melakukan akuisisi data, elisitasi, sampai dengan validasi data. Selain studi literatur dan kajian pustaka, salah satu pendekatan aktual adalah melalui wawancara, kuisioner, dan observasi lingkungan.

Setelah kebutuhan terdefinisikan, agar kebutuhan tersebut dapat ter-deliver dengan baik tidak hanya bagi stakeholder tetapi juga bagi sub-tim dalam tim pengembang, diperlukan standarisasi dalam desain database. Desain database meliputi desain konseptual, desain logical, dan desain fisik.

Untuk posting selengkapnya, liat disini.

(Diambil dari tegarheru.wordpress.com)

Kita semua tahu, database adalah kumpulan fakta yang nantinya diolah menjadi informasi untuk keperluan berbagai problem domain. Dapat dikatakan bahwa database merupakan model dari aplikasi. Sedangkan aplikasi merupakan model dari problem domain. Bayangkan jika sebuah database tidak di-develop dengan “BENAR” ?

Josh Berkus, pakar database dari PostgreSQL mengatakan:

You can simply model the database as a derivative of your problem domain.
If you don’t understand your database, you don’t understand the problem you’re solving.

Apakah hanya dengan Normalisasi sebuah database bisa dikatakan “BENAR” ?
Ataukah dengan penyelarasannya dengan proses bisnis membuatnya “BENAR” ?

Untuk posting selengkapnya, liat disini.

Skip to toolbar