IF36318 Rekayasa Perangkat Lunak

Presentasi berjudul: "IF36318 Rekayasa Perangkat Lunak"— Transcript presentasi:

1 IF36318 Rekayasa Perangkat Lunak
Jurusan Teknik Informatika Universitas Komputer Indonesia RPL/Mira/Pendahuluan

2 RPL/Mira/Pendahuluan
Perangkat Lunak Rekayasa Perangkat Lunak Proses Perangkat Lunak Standar Perangkat Lunak CASE Tools Software Professionalism RPL/Mira/Pendahuluan

3 RPL/Mira/Pendahuluan
Perangkat Lunak Apa itu perangkat lunak Karakteristik perangkat lunak Komponen perangkat lunak Aplikasi perangkat lunak Perkembangan perangkat lunak Mitos perangkat lunak RPL/Mira/Pendahuluan

4 Apa yang dimaksud dengan Perangkat Lunak?
Perintah (Program Komputer) yang bila dieksekusi memberikan fungsi dan ujuk kerja seperti yang diinginkan. Struktur data yang memungkinkan program memanipulasi informasi secara proporsional. Dokumen yang menggambarkan operasi dan kegunaan program. RPL/Mira/Pendahuluan

5 Karakteristik Perangkat Lunak
Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik Perangkat lunak tidak pernak usang, artinya berhubungan dengan perangkat keras Sebagian besar perangkat lunak dibuat secara custom built, serta tidak dapat dirakit dari komponen yang sudah ada RPL/Mira/Pendahuluan

6 Komponen Perangkat Lunak
Dibentuk dengan menggunakan bahasa pemrograman Karakteristik yang paling penting adalah reusability, artinya sebuah perangkat lunak harus didesain dan diimplementasi sehingga dapat dipakai lagi pada berbagai program yang berbeda RPL/Mira/Pendahuluan

7 Aplikasi Perangkat Lunak
Perangkat lunak sistem Perangkat lunak Real-time Perangkat lunak bisnis Perangkat lunak teknik dan ilmu pengetahuan Embedded Software Perangkat lunak komputer personal Perangkat lunak kecerdasan buatan RPL/Mira/Pendahuluan

8 Perangkat lunak : Krisis di masa mendatang
Krisis perangkat lunak : Krisis adalah merupakan titik balik dari segala hal, waktu yang menentukan atau krusial, keadaan atau kejadian (webster’s dictionary) Sementara untuk perangkat lunak tidak ada lagi titik balik, tidak ada waktu yang menentukan, dan yang ada hanya perubahan evolusi yang lambat Dalam industri perangkat lunak kita telah mengalami krisis selama 30 tahun, dalam bentuk yang sangat kontradiktif Serta penderitaan (affliction) Masalah perangkat lunak : bagaimana membuat perangkat lunak tersebut berjalan sesuai dengan fungsinya, bagaimana mengembangkan perangkat lunak, bagaimana kita memelihara suatu volume perangkat lunak yang sedang tumbuh, dan bagaimana kita mengejar kebutuhan akan lebih banyak perangkat lunak lagi Keputusan : Rekayasa Perangkat Lunak(pengembangan perangkat lunak) RPL/Mira/Pendahuluan

9 Software used, but criticized or dropped Software delivered but
Software Problems Software used after modifications 3% Software used, but criticized or dropped 19% Software paid for but never delivered 29,7% Software delivered and used as it is 2% Software delivered but never used 47% 1982: Nine DOD contracts amounting to $6.8 million (source: GAO, quoted in CMU/SEI-93-EM-8) RPL/Mira/Pendahuluan

10 Distribution of effort : Distribution of effort:
Software Problems (2) Distribution of effort : what is believed Distribution of effort: what happens Specification Specification Testing Design Encoding Testing Design Encoding Maintenance RPL/Mira/Pendahuluan

11 RPL/Mira/Pendahuluan
Software Problems (3) Time Failure Rate "Infant Mortality" "Wear Out" Ideal Actual Change FAILURE CURVE FOR HARDWARE FOR SOFTWARE * Software Engineering, Module 1, Richard Conn, University of Cincinnati, May 1993 RPL/Mira/Pendahuluan

12 Mitos Perangkat Lunak dari pandangan manajemen
Kita sudah memiliki buku yang penuh dengan standar dan prosedur untuk membuat perangkat lunak. Apakah buku itu tidak memberikan semua yang ingin diketahui oleh staf saya? Staf saya sebenarnya memiliki alat pengembangan perangkat lunak terkini, karena itulah kita membeli komputer baru bagi mereka Jika kita menta’ati jadwal, kita dapat menambah lebih banyak lagi pemrogram dan mengejar ketinggalan (“Mongolia Horde concept”) Kenyataan : Buku standar mungkin ada, tetapi apakah buku-buku tersebut dipakai?apakah praktisi perangkat lunak sadar akan keberadaan buku tsb?Apakah dia benar-benar mencerminkan praktik perkembangan perangkat lunak modern?apakah sudah lengkap?hampir semua jawabannya “tidak” Dibutuhkan lebih dari sekedar mainframe model terakhir, workstation atau PC untuk mengembangkan perangkat lunak berkualitas tinggi. CASE lebih penting daripada H/W untuk mendapat kualitas dan produktivitas yang tinggi, tetapi mayoritas pengembang P/L tetap belum menggunakannya. Perkembangan P/L bukan merupakan proses mekanis seperti pemanufakturan, artinya orang dapat ditambah tetapi waktu dan cara yang sudah terkoordinasi dengan baik. RPL/Mira/Pendahuluan

13 Mitos Perangkat Lunak Pelanggan
Pernyataan umumtentang obyektivitas sudah cukup untuk memulai menulis program. Kita dapat mengisi detailnya nanti Kebutuhan proyek berubah terus menerus, tetapi perubahan tersebut dapat diakomodasi karena P/L bersifat fleksibel Kenyataan : Definisi awal yang buruk merupakan sebab utama gagalnya kerja P/L Memang benar bahwa kebutuhan-kebutuhan perangkat lunak selalu berubah, tetapi pengaruh perubahan itu bervariasi sesuai waktu saat perangkat lunak dikenalkan RPL/Mira/Pendahuluan

14 Mitos Perangkat Lunak Pra Praktisi
Sekali kita menulis program, dan dapat membuatnya bekerja, pekerjaan kita akan terselesaikan Saya benar-benar tidak mempunyai cara untuk “menilai” kualitas program, kecuali jika saya dapat membuat program itu “berjalan” Satu-satunya yang dapat disampaikan untuk sebuah proyek yang sukses adalah program yang bekerja Kenyataan : 50%-70% dari semua usaha yang dilakukan pada sebuah program akan terus dilakukan sampai program diantar ke tangan konsumen untuk yang pertama kalinya. Tinjauan perangkat lunak merupakan “filter kualitas” yang lebih efektif daripada pengujian untuk menemukan kelas-kelas kesalahan perangkat lunak yang khusus. Program yang bekerja hanya merupakan salah satu bagian dari konfigurasi P/L yang menyangkut program, dokumen, dan data. Dokumentasi membentuk fondasi bagi perkembangan yang berhasil, serta yang lebih penting lagi, memeberikan tuntunan bagi tugas pemeliharaan perangkat lunak. RPL/Mira/Pendahuluan

15 Software Professionalism
Banyak profesional perangkat lunak mengakui pemikiran yang keliru dari mitos yang digambarkan diatas. Sayangnya, sikap dan metode yang biasa digunakan mendukung buruknya praktik teknis dan manajemen, bahkan ketika kenyataan menunjukkan pendekatan yang baik. Pengakuan atas kenyataan perangkat lunak merupakan langkah pertama menuju terbentuknya pemecahan praktis bagi pengembangan perangkat lunak RPL/Mira/Pendahuluan

16 Diagram Pengaruh Perubahan
Biaya Perubahan 60-100x 1.5-6x 1x Definisi Pengembangan Setelah Peluncuran RPL/Mira/Pendahuluan