IF36318 Rekayasa Perangkat Lunak

RPL/Mira/Pendahuluan

IF36318 Rekayasa Perangkat Lunak

Jurusan Teknik Informatika

Universitas Komputer Indonesia


Pendahuluan

• Perangkat Lunak

• Rekayasa Perangkat Lunak

• Proses Perangkat Lunak

• Standar Perangkat Lunak

• CASE Tools

• Software Professionalism


Perangkat Lunak

• Apa itu perangkat lunak

• Karakteristik perangkat lunak

• Komponen perangkat lunak

• Aplikasi perangkat lunak

• Perkembangan perangkat lunak

• Mitos perangkat lunak


Apa yang dimaksud dengan Perangkat Lunak?

1. Perintah (Program Komputer) yang bila dieksekusi memberikan fungsi dan ujuk kerja seperti yang diinginkan.

2. Struktur data yang memungkinkan program memanipulasi informasi secara proporsional.

3. Dokumen yang menggambarkan operasi dan kegunaan program.


Karakteristik Perangkat Lunak

1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik

2. Perangkat lunak tidak pernak usang, artinya berhubungan dengan perangkat keras

3. Sebagian besar perangkat lunak dibuat secara custom built, serta tidak dapat dirakit dari komponen yang sudah ada


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


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


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)


Software Problems

Software paid for but never delivered

29,7%

Software delivered butnever used

47%

Software used after modifications

3%Software used, but

criticized or dropped19%

Software delivered and used as it is

2%

1982: Nine DOD contracts amounting to $6.8 million(source: GAO, quoted in CMU/SEI-93-EM-8)


Software Problems (2)

Specification

Design

Encoding

Testing

Distribution of effort :what is believed

Distribution of effort:what happens

SpecificationDesign

Encoding

Testing

Maintenance


Software Problems (3)

Time Time

FailureRate

"InfantMortality"

"WearOut"

Ideal

Actual

Change

FAILURE CURVEFOR HARDWARE

FAILURE CURVEFOR SOFTWARE

* Software Engineering, Module 1, Richard Conn, University of Cincinnati, May 1993


Mitos Perangkat Lunak dari pandangan manajemen

Mitos :• 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.


Mitos Perangkat Lunak Pelanggan

Mitos :• 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


Mitos Perangkat Lunak Pra Praktisi

Mitos :• 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.


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


Diagram Pengaruh Perubahan

1x

1.5-6x

60-100x

Biaya Perubahan

Definisi Pengembangan Setelah Peluncuran

Documents

IF36318 Rekayasa Perangkat Lunak