Archive for September 2008

PUSTAKA RUJUKAN

Kata reference berasal dari refer yang artinya merujuk ke sesuatu atau informasi. Sumber informasi yang digunakan untuk rujukan informasi tentang suatu topik, tema, kejadian, orang, tanggal tertentu, atau kata disebut sumber informasi rujukan atau reference source.
Sumber informasi ini biasanya digunakan untuk mencari informasi secara cepat, dan singkat. Informasi yang diberikan adalah informasi awal dan sederhana. Yang termasuk sumber informasi rujukan adalah :
1.kamus : informasi tentang kata: arti, cara pengucapan, contoh penggunaan, sinonim
2.ensiklopedia : penjelasan tentang suatu topik: definisi, penjelasan, latar belakang.dan lain-lain secara singkat dan bersifat pengenalan.
3.Almanak : Kalender (tanggal dan bulan) yang dilengkapi dengan informasi lain seperti prediksi dan statistik, kumpulan fakta tentang hal tertentu.
4.sumber statistik
5.atlas atau peta: peta geografi tanpa informasi pendukung yang menjelaskan tentang lokasi-lokasi.
6.kamus biografi: kamus tentang
7.gazetteer : peta geografi yang disertai dengan informasi pendukung tentang lokasi
8.Direktori : berisi alamat dan nama perusahaan atau organisasi yang dilengkapi dengan informasi tentang perusahaan atau organisasi tersebut.
Pustaka rujukan digunakan pada saat kita membutuh informasi tentang suatu hal dalam waktu cepat, informasi yang singkat dan jelas, dan bersifat pengenalan awal. Sumber informasi ini memberikan informasi awal yang kita perlukan sehingga dari sumber informasi ini kita dapat menentukan apakah hal yang kita cari tersebut layak untuk diperdalam atau diketahui lebih atau tidak.

Buku Teks
Sumber informasi Sekunder lain adalah buku teks. Buku teks memiliki beberapa bagian yang perlu diperhatikan:
1.halaman judul : menjelaskan judul, penerbit pengarang. Untuk yang terbiasa dengan buku-buku keluaran penerbit tertentu, penerbit tertentu dapat menjadi jaminan kualitas buku, sekalipun ini tidak selalu menjadi jaminan. Buku yang beredisi terbaru biasanya memiliki isi yang lebih dari edisi sebelumnya.
2.kata pengantar: berisi penjelasan tentang isi buku tersebut secara singkat, siapa audiens yang dituju, dan bagaimana buku tersebut dapat digunakan dan diatur.
3.daftar isi: berisi daftar pokok bahasan yang ditulis di dalam buku.
4.isi buku
5.indeks: daftar kata-kata terseleksi atau istilah-istilah yang dibahas di dalam buku disertai letak halaman.
Menentukan buku yang akan digunakan sebagai sumber informasi, perlu strategi di dalam memastikan bahwa buku yang dipilih sesuai dengan kebutuhan. Bagian-bagian buku di atas dapat membantu untuk menentukan apakah buku tersebut sesuai.
Daftar isi merupakan salah satu tempat yang penting untuk diperiksa dalam rangka memastikan apakah pokok bahasan yang dibutuhkan ada dalam buku. Indeks juga akan banyak membantu dengan lebih ringkas dari segi istilah yang ditentukan dan bentuk yang ringkas.
Sementara kata pengantar akan memberikan gambaran dari pembaca yang diharapkan mendapatkan manfaat dari buku tersebut. Misalnya untuk seorang programmer pemula, buku Pemrograman yang bertingkat advanced tentu tidak cukup membantu.

Artikel Ilmiah
Artikel ilmiah memiliki abstrak dan kata kunci yang menjelaskan secara singkat apa isi dari artikel tersebut. Karena itu untuk menentukan isi dari artikel akan lebih baik jika abstrak dari artikel tersebut dibaca lebih dahulu. Judul jurnal dan penjelasan tentang jurnal tersebut akan membantu menentukan bahwa artikel tersebut berada pada domain ilmu yang sesuai sudut pandangnya dengan yang kita perlukan.



18 Sep, 2008 | othie |

Rekayasa Kebutuhan

Pembahasan rekayasa kebutuhan diadaptasi dari : Pressman, Roger S . Software Engineering: A Practitioner's Approach. 6th Edition. McGraw-Hill. 2005.

What is it ?
Requirement engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of what the business impact of the software will be, what the customer wants, and how end-users will interact with the software
Why is it important ?
Designing and building an elegant computer program that solves the wrong problem serves no one's needs. That's why it is important to understand what the customer wants before you begin to design and build a computer-based system.
What is the work product ?
The intent of the requirements engineering process is to provide all parties with a written understanding of the problem. This can be achieved though a number of work products: user scenario's, functions, and features lists, analysis models, or a specification.

Latar belakang mengapa perlu adanya rekayasa kebutuhan adalah kenyataan bahwa menemukan kebutuhan klien secara lengkap adalah tidak mudah dan mahal. Tidak mudah karena :
1. klien tidak selalu mengetahui dengan pasti dan jelas apa yang diperlukan
2. kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud
3. kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak
Hal-hal di atas menyebabkan biaya pembangunan perangkat lunak menjadi mahal karena ada tambahan biaya lagi untuk perubahan yang dilakukan dan waktu yang dibutuhkan lebih dari seharusnya.

Rekayasa kebutuhan membangun jembatan menuju desain dan pembangunan perangkat lunak dengan menyediakan mekanisme yang tepat untuk memahami apa yang diinginkan klien, menganalisis kebutuha, menguji kelayakan, bernegosiasi untuk solusi yang masuk akal, menetapkan solusi yang dapat dipahami dua belah pihak, uji spesifikasi dan mengelola kebutuhan yang akan diwujudkan ke sistem operasional. Rekayasa kebutuh terdiri dari 7 fungsi:
1. inception [permulaan]
Inception atau permulaan, merupakan awal dari terjadinya pembicaraan tentang kebutuhan akan software. Permulaan ini dapat terjadi karena dari pembicaraan biasa,kebutuhan bisnis yang dirasakan, adanya pasar potensial, atau munculnya layanan potensial yang dapat dilakukan oleh software.
Aktifitas diawali dengan penetapan siapa stakeholder/pihak-pihak terkait dengan perangkat lunak yang akan dibangun. Misal :
- business operation manager
- product managers
- marketing people
- internal + external customer
- end-users
- consultants
- product engineers
- software engineers
- support and maintenance engineers
- others.
Kebutuhan dieksplorasi dari berbagai pandangan dari masing-masing stakeholders. Kebutuhan yang sama dan berbeda dari masing-masing dicatat, perbedaan persepsi diluruskan. Pertanyaan-pertanyaan awal/dasar dilontarkan kepada setiap stakeholder.

2. elicitation [Pengungkapan]
Klien mengungkapkan kebutuhan. Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah.
Aktifitas dilakukan dalam bentuk pertemuan, dimana setiap stakeholder yang diundang diminta untuk membuat daftar kebutuhan software yang disertai penjelasan tentang karakteristik atau detil dari kemampuan tersebut.

3. elaboration [Penjelasan]
Apa yang diungkapkan pada proses permulaan dan pengungkapan kebutuhan, dijelaskan panjang lebar. Fokus pada pemodelan fungsi, fitur dan batasan dari perangkat lunak. Dalam kasus OOP, maka class, atribute dan hubungan antar class diidentifikasi pada aktifitas ini.

4. negotiation [Konflik Resolusi]
Jika terjadi konflik kepentingan karena perbedaan kebutuhan antara bagian pada klien, atau antar end-user, maka aktifitas negosiasi diperlukan untuk membuat prioritas kebutuhan, mengevaluasi tiap kebutuhan untuk mengurangi atau mengubah sesuai dengan yang dimaksud pihak-pihak yang berkonflik.
5. specification
Spesifikasi dapat berubap dokumen, model grafik, model matematika, skenario atau prototype yang merupakan produk akhir dari rekayasa kebutuhan. Apa yang disajikan sebagai spesifikasi merupakan hasil identifikasi kebutuhan melalui aktifitas-aktifitas sebelumnya.Spesifikasi menggambarkan fungsi dan keinerja dari perangkat lunak dan batasan-batasan yang ditentukan.
6. validation
Menguji kualitas dari spesifikasi untuk memastikan kebutuhan yang dinyatakan dapat diterima/sepaham, konsisten, lengkap dan bebas kesalahan. Mekanisme yang dapat dilakukan adalah formal technical review atau pertemuan evaluasi teknis.
7. management
mengelola kebutuhan dengan identifikasi, kontrol dan mengikuti perkembangan kebutuhan software yang dikerjakan selama proyek dan perubahan-perubahan yang terjadi.

13 Sep, 2008 | othie |

Pengantar Rekayasa Perangkat Lunak

Berbicara tentang rekayasa perangkat lunak, bukanlah berbicara tentang pemrograman untuk membangun sebuah perangkat lunak. Apa yang dibahas di dalam rekayasa perangkat lunak adalah kegiatan-kegiatan yang dilakukan untuk membangun perangkat lunak dan kegiatan yang menaunginya sehingga perangkat lunak yang dihasilkan sesuai dengan standar mutu yang ditentukan.
Mengajarkan dan mengikuti kuliah rekayasa perangkat lunak (RPL) sama-sama tidak mudahnya. Mengajarkan suatu konsep memerlukan kreatifitas sehingga konsep tersebut tidak hanya dapat dibayangkan dan masuk akal, tapi juga menarik. Memahami suatu konsep yang tidak terpikirkan saat melakukan pemrograman memerlukan imajinasi dan analogi yang membantu diterima secara logis.

Pada umumnya mahasiswa Teknik Informatika dan Sistem Informasi lebih mengutamakan pemrograman, karena menurut mereka itu adalah kemampuan inti yang harus dikuasai. Pada kenyataannya, banyak kemampuan lain yang mungkin selama ini dianggap sebelah mata, justru menjadi penopang dan penentuk proses membangun perangkat lunak: kerja sama dalam tim, kemampuan berkomunikasi, kemampuan membuat dokumentasi, kemampuan wawancara, kemampuan belajar cepat bidang lain di luar pemrograman dan sebagainya.

Dalam rekayasa perangkat lunak umumnya ada beberapa kegiatan yang senantiasa ada pada model proses apapun : identifikasi kebutuhan, desain, pengkodean, penerapan dan pemeliharaan. Dari kegiatan-kegiatan yang berurutan tersebut, pengkodean baru dapat dilakukan jika kebutuhan sudah dikumpulkan dan diketahui lalu didesain. Pengkodean yang sering menjadi fokus mahasiswa ini tidak berhenti ketika selesai, tapi ada pemeliharaan yang pasti terkait juga dengan kebutuhan. Kegiatan lain yang menaungi rekayasa perangkat lunak adalah jaminan mutu perangkat lunak [SQA- Software Quality Assurance]. Pada dasarnya, setiap kegiatan memilik standar bagaimana kegiatan tersebut seharusnya dilakukan untuk menghasilkan produk yang diinginkan.

Matakuliah RPL semester ini banyak mengadopsi bab-bab di buku Pak Roger S Pressman, Software Engineering: A Practioner's Approach. Selain itu informasi yang dikelola lokal dan tidak kalah menarik untuk dibaca dan didiskusikan adalah dari Pak Romi Satria Wahono, secara khusus di kumpulan tulisan tentang Software Engineering. Sumber pengetahuan lokal lain adalah ilmukomputer.com pada katagori Rekayasa Perangkat Lunak.

13 Sep, 2008 | othie |

© 2007 yoursite.com | Designed by DesignsByDarren
Ported to Nucleus CMS: Suvoroff