Rekayasa Perangkat Lunak

Fajar Pradana S.ST., M.Eng

Fajar Pradana

CP. 08 222 820 2121

Email

fajar.p@ub.ac.id

fajar.prd@gmail.com

Blog: fajar.lecture.ub.ac.id

Student representative

contact person

Mata Kuliah

Mata Kuliah : Rekayasa Perangkat Lunak

Kode Mata Kuliah : PTI15011

Beban Studi : 4 SKS

Sifat : Wajib

Praktikum : Ada

Deskripsi Singkat : Memberikan pemahaman tentang pengertian dan urgensi RPL, serta

penerapan metoda-metoda pengembangan perangkat lunak dalammelakukan analisis kebutuhan perangkat lunak, perancangan awal danperacangan detil, implementasi / pemrograman, dan pengujianperangkat lunak.

Setelah mengikuti perkuliahan ini, mahasiswa diharapkan akan dapatmenjabarkan metoda-metoda yang harus diterapkan dalammengembangkan sebuah perangkat lunak.

Materi

Pengertian dan Urgensi RPL (Introduction/Pengenalan)

Spesifikasi/Analisis Kebutuhan Perangkat Lunak

Analisa Model

Prototyping

Desain Model

Desain Antar Muka

Desain Tingkat Komponen

Implementasi

Teknik Pengujian Perangkat Lunak

Strategi Pengujian Perangkat Lunak

Deployment dan instalasi

Operasi dan dukungan (Operation and Support)

Evolusi perangkat lunak

Topik penelitian dalam RPL

Pustaka

• Booch, Grady, 1994, Object-Oriented Analysis and Design –With

Applications, The Benjamin/Cummings Publishing Compani, Inc.,

Second Edition.

• Brackett, John W., 1990, Software Requirements, Software Engineering

Institute.

• Coad, Peter/Edward Yourdon, 1991, Object-Oriented Analysis, Prentice-

Hall International Inc., Second Edition.

• Coad, Peter/Edward Yourdon, 1991, Object-Oriented Design, Prentice-

Hall International Inc.

• Pressman, Roger. S, 2001, Software Engineering – A Practitioner’s

Approach, McGraw-Hill Series in Computer Science, Fifth Edition.

• Sommerville, Ian, 1996, Software Engineering, Addison-Wesley, Fifth

Edition.

Penilaian

Praktikum 20%

Kuliah 80% :

UTS 30%

UAS 40%

Tugas / keaktifan 20%

Quiz 10%

Peraturan

Tugas dikumpulkan tepat waktu, keterlambatan tugas dan

plagiarisme akan mengakibatkan nilai 0

Plagiarisme tugas akan ditindak tegas

Tugas copy paste berakibat nilai 0

Regulasi

Kehadiran

Minimal kehadiran 80%

Kehadiran < 80%, nilai akhir adalah K

Toleransi keterlambatan 15 menit

Kode Etik Mahasiswa

Pakaian

Sikap

9/14

Pendahuluan

Relevansi Perkuliahan :

Tuntutan customer semakin tinggi dan kompleks

PL kurang andal, jadwal projek molor, perawatan susah, dll.

S/W engineer belum menguasai RPL

Tujuan Instruksional Khusus :

Mahasiswa akan dapat menjelaskan pengertian rekayasa perangkat

lunak dan mengapa rekayasa perangkat lunak diperlukan dalam

mengembangkan PL

10/14

Agenda Pembahasan

Pendahuluan

Pengertian RPL

Urgensi RPL

RPL Hari Ini

Mitos Seputar RPL

11/14

Pengertian RPL (S/W Engineering - WHAT)

Teknologi yang meliputi proses, sekumpulan metoda &

sederetan alat bantu untuk pengembangan P/L (Roger S.

Pressman)

Penerapan sebuah pendekatan yang sistematik, tertib, dan

terukur terhadap pengembangan, pengoperasian, dan

perawatan perangkat lunak (IEEE Standards Collection)

Penerapan prinsip-prinsip keteknikan/rekayasa dlm rangka

memperoleh P/L yg ekonomis tetapi andal dan cukup

efisien berjalan pada mesin yang sesungguhnya (Fritz

Bauer)

12/14

Pengertian RPL (S/W Engineering - WHAT)

Analisis

Perancangan

Implementasi

Pengujian

Siklus Hidup Pengembangan PL

(S/W Development Life Cycle – SDLC) :

1. Model Waterfall/Classic/Linear Sequential

13/14

Pengertian RPL (S/W Engineering - WHAT)

Implementasi

2. Model V

Perancangan

Awal

Perancangan

Detil

Analisis

Pengujian

Unit

Pengujian

Terintegrasi

Validasi

3. Model Spiral, RAD, Prototyping, RUP, XP, dll.

14/14

Urgensi RPL (S/W Engineering – WHY)

Penderitaan Kronis (Chronic Affliction) :

S/W delivered behind schedule

S/W costs exceeds estimates

S/W unreliable

S/W difficult to maintain

S/W performs poorly

15/14

Urgensi RPL (S/W Engineering – WHY)

Data Survei :

Standish Group – 1995

365 IT executives in US comp. in diverse industry segments

8,380 projects

Project completion

16%

31%

53%

On time, on budget,

with all of the specified

features and functions

Cancelled before they

were completed

delivered and

operational but over-

budget, over-schedule

or with fewer features

and functions than

specified

average cost

overrun = 189%

average

time

overrun =

222%.

61% of originally specified

features included

?

?

16/14

Urgensi RPL (S/W Engineering – WHY)

S/W Eng. FrameworkHigh quality

s/w

Customer Developer

17/14

Faktor Utama Kegagalan P/L

Kebutuhan customer tidak bisa dipahami dan ditangkap

dengan tepat

Kebutuhan customer sering mengalami perubahan

Customer tidak bisa bekerja sama dengan pengembang

Pengembang kurang memiliki kecakapan dalam

menjalankan tugas

Sistem yang dikembangkan tidak terlalu banyak

memberikan manfaat kepada customer

18/14

RPL Hari Ini

RPL tidak populer dan hanya sedikit industri PL yang

menerapkan :

Pengembangan PL dipahami hanyalah sebatas membuat

program saja, tanpa memahami pentingnya melakukan analisis

dan perancangan

Jadwal projek yang ketat

Belum adanya kesadaran pengambil keputusan dlm. industri PL

akan kemanfaatannya

Belum banyak s/w engineer yang menguasai

Manajemen projek masih belum menjadi kebutuhan

19/14

Mitos Seputar RPL

Jika jadwal molor maka kita bisa menambah lebih banyak

programmer

Jika kita bisa outsourcing PL maka kita bisa lebih santai

Pernyataan umum tentang tujuan sistem yang akan

dikembangkan sudah cukup untuk memulai pemrograman

Kebutuhan sistem sering mengalami perubahan, ttp hal ini

mudah diakomodasi krn PL itu fleksibel

Begitu selesai program & jalan selesai

20/14

Mitos Seputar RPL

Hasil dari projek yang sukses hanyalah program yang jalan

dengan baik

RPL akan membuat kita repot dengan pembuatan

dokumen yang tidak perlu

21/14

Penutup

apabila kita gagal membuat perencanaan

dengan baik, maka kita sebetulnya

merencanakan untuk gagal . . .