Pengenalan Rekayasa Perangkat Lunak

Cakupan Materi Konsep dasar PL dan RPL Biaya PL Software Quality Attribute Standar Kualitas Takaran Jaminan Kualitas Pemahaman dasar tentang RPL Keberadaan RPL Tanggung Jawab Profesional & Etika Siklus Hidup PL ( Software Development Life Cycle)

Biaya Perangkat Lunak Biaya PL sering mendominasi biaya sistem secara keseluruhan Biaya pengadaan PL yang dipasang di komputer (PC) sering lebih besar dibanding dengan harga hardware nya (pengecualian di negara yang kurang menghargai HAKI) Biaya terbesar untuk suatu PL terletak pada proses maintenance di banding proses pembuatannya.

Biaya Perangkat Lunak (2) Rekayasa PL, terpusat pada biaya efektif dari suatu pembangunan Untuk PL berjenis Custom, biaya evolusi sering melebihi biaya pembangunan. Secara umum besarnya biaya bervariasi tergantung pada tipe sistem yang dibangun dan kebutuhan sistem seperti kinerja dan kehandalan sistem.

Software Quality Attribute Ciri-ciri (Atribut) Kualitas menurut lembaga penjamin PL ( ISO, IEEE, dll) Correctness (Kebenaran) Reliability ( tahan uji) User Friendliness (mudah digunakan) Maintenatibility (mudah dirawat) Efficiency Portability (Mudah didistribusikan)

Ukuran Jaminan Kualitas Ada 3 ukuran jaminan kualitas. Ukuran membangun (Contructive Measures) Aplikasi yang konsisten pada metode di seluruh fase proses pembangunan. Penggunaan tools yang memadai Pembangunan PL pada basis kualitas yang tinggi di akhir tahapan. Perawatan yang konsisten pada dokumentasi pengembangan

Ukuran Jaminan Kualitas (2) Ukuran Analitik (Analytical Measures) Analisis program yang statis Analisis program yang dinamis Pemeliharaan test case yang sistematis Pencatatan yang konsisten pada analisis Produk

Ukuran Jaminan Kualitas (3) Ukuran Organisasi ( Organisasi Measures) Pengalaman pengembang (developer) dalam mempelajari strategi dan tehnik yang tepat dalam membangun PL.

Krisis Perangkat Lunak Masalah yang muncul : Estimasi jadwal dan biaya yang seringkali tidak tepat. Produktivitas orang-orang software yang tidak dapat mengimbangi permintaan software Kualitas software yang kurang baik

Krisis Perangkat Lunak (2) Kurangnya pengetahuan tentang : Bagaimana mengembangkan software Bagaimana memelihara software yang ada yang berkembang dalam jumlah besar. Bagaimana mengimbangi perminataan software yang makin besar.

Mitos dalam PL ( Management) Kita tidak perlu mengubah pendekatan terhadap pengembangan software karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu. Realitasnya : walau hasil pemrograman sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments.

Mitos dalam PL ( Management) (2) Kita sudah punya buku yang berisis standarisasi dan prosedur untuk pembentukan software. Realitasnya : Memang buku tersebut ada tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan zaman.

Mitos dalam PL ( Management) (3) Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian Hard Concept.

Mitos Dalam PL ( Customer) Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian. Realitasnya : Definisi awal yang yang buruk adalah penyebab utama kegagalan terhadap usaha-usaha pembentukan software. Penjelasan yang formal dan terinci tentang informasi fungsi performance interface, hambatan desain dan kriteria validasi adalah penting. Karakteristik diatas dapat ditentukan hanya setelah adanya komunikasi antara customer dan developer.

Mitos Dalam PL ( Customer) (2) Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Realitasnya : Memang benar bahwa kebutuhan software berubah tetapi dampak dari perubahan berbeda dari waktu ke waktu.

Mitos dalam PL ( Praktisi) Tiak ada metode untuk analisis desain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding. Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software.

Mitos dalam PL ( Praktisi) (2) Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara :Catch as Catch CAM. Realitasnya : Diperlukan budget yang besar dalam maintenance software. Pemeliharaan software harus diorganisir, direncanakan dan dikontrol seolah-olah sebagai suatu proyek besar dalam sebuah organisasi.

Tantangan PL Tantangan Warisan ( dikembangkan bertahun-tahun dengan orang-orang yang berbeda) Tantangan heterogenesis ( distribusi & teknologi) Tantangan pengiriman ( bagaimana mengirim sistem yang besar dan kompleks dengan cepat dan kualitas yang tetap terjaga.

Pemahaman Rekayasa Perangkat Lunak Merupakan disiplin ilmu pengetahuan serta ilmu rekayasa atau tehnik yang berkaitan dengan semua aspek dalam membangun/menghasilkan sebuah perangkat lunak yang mampu : Tepat waktu Tepat anggaran Meningkatkan kinerja Mengoperasikan prosedur sistem dengan benar

Pemahaman Rekayasa Perangkat Lunak (2) RPL merupakan teknologi yang harus digunakan oleh setiap orang yang akan membangun PL dengan melalui serangkaian proses, menggunakan sekumpulan metode dan alat bantu (tools) Intinya adalah bagaimana melakukan usaha supaya sebuah PL yang dibuat dapat memenuhi kriteria yang diinginkan.

Pelaku dalam RPL Manajer Software Developer Pendukung Manajer Proyek, Manajer Konfigurasi, Manajer Penjamin kualitas PL, dll Software Developer Analis Sistem, Desainer, Programmer, Inspektor PL, Pengontrol Perubahan Pendukung Staf admin, Humas, Pencatat teknis, Admin database, Admin Jaringan.

Kode Etik Profesi Konfidensialitas ( menghormati klien) Tidak boleh menerima pekerjaan di luar kompetensinya. Hak Kekayaan Intelektual (HaKI) Penyalahgunaan komputer, hack, crack, nge- game, dll.

Kode etik Internasional Digagas oleh masyarakat profesional di Amerika (1999) yang tergabung dalam ACM/IEEE. Makna yang terkandung : Prinsip kesepakatan yang dihubungkan dengan tingkah laku dan keputusan yang dibuat oleh para ahli profesional. Masyarakat profesional : Praktisi, pengajar, manajer, supervisor, pengambil kebijakan

Kode etik Internasional (2) Yang diatur : Masyarakat dan kepentingannya Klien dan atasan (Pelayanan terbaik) Produk (Jaminan Mutu) Manajemen Profesi Kolega Diri sendiri ( ada usaha untuk mengupdate ipteknya)

Hubungan RPL, ILKomp & Rekasaya Sistem Ilmu Komputer berkaitan erat dengan teori dan konsep-konsep dasar tentang komputer dan aplikasinya. RPL berkaitan dengan praktek pembangunan PL hingga pengiriman PL ke pelanggan. Teori ilmu komputer masih kurang memadai jika dijadikan sebagai penyangga RPL sehingga ada bahasan khusus mengenai RPL.

Bersambung…… Software Development Life Cycle