REKAYASA PERANGKAT LUNAK

PROGRAM STUDI TI FIKOM

: Jl. Tarakan No. 22

Komplek PT. ARUN

Lhokseumawe, 24353

: 08116702263 : johan tm PIN : 2663C69E

: johantm@yahoo.com

: johan.peusangan

: @tmjohan

: peusangan-robotic.blogspot.com (download bahan kuliah)

: Ir. Teuku Muhammad Johan, M.IT

Midtem : 25 % Final : 40 % Tugas Kelompok : 25 % Absensi : 10 %

CARA PENILAIAN

1. Pressman, Roger.S. "Software Engineering : A Practioner's Approach." 4th . McGrawHill. 1997.

2. Pressman, Roger.S. “Rekayasa Perangkat Lunak” Buku 1 dan 2 Edisi 7. ANDI Yogyakarta 2010.

3. Nugroho, Adi. “Rekayasa Perangkat Lunak Berorientasi Objek”. ANDI Yogyakarta 2010.

Buku Rujukan:

1. Rekayasa Perangkat lunak Pendahuluan

2. Proses Rekayasa Perangkat Lunak.

Course Outline

5

RPL sesungguhnya merupakan teknologi yang berlapis.

Termasuk di dalamnya; proses, metode dan perkakas yang semuanya fokus pada kualitas

Proses Rekayasa Perangkat Lunak.

6

PERKAKAS

METODE

PROSES

FOKUS PADA KUALITAS

Proses merupakan suatu perekat antara perkakas dan metoda (cara membangun perangkat lunak) sehingga dapat menghasilkan produk yang berkualitas tinggi.

RPL merupakan pendekatan adaptif yang memung-kinkan tim perangkat lunak untuk melakukan serangkaian langkah dan tugas. Tujuannya adalah menyampaikan PL secara tepat waktu dengan kualitas yang cukup bagus sehingga memuaskan mereka yang menggunakannya.

Kerangka kerja proses yang umum bagi RPL terdiri dari; komunikasi, perencanaan, pemodelan, konstruksi dan penyerahan P L.

Apakah Proses RPL

7

Aktivitas yang mendasar (umum) dari setiap proses perangkat lunak:

Spesifikasi Menentukan fungsi & batasan dari perangkat lunak.

Desain & ImplementasiMenentukan struktur / arsitektur dan mengembangkan perangkat lunak

berdasarkan spesifikasi.

ValidasiPerangkat lunak yang dikembangkan harus diuji untuk meyakinkan apakah

sesuai dengan keinginan pelanggan.

EvolusiPerangkat lunak yang dihasilkan harus senatiasa berkembang sesuai dengan

perubahan kebutuhan pelanggan.

Apakah Proses RPL

8

Apa yang dimaksud dengan Model Proses P L?

Sebuah model proses perangkat lunak adalah representasi abstrak dari sebuah proses.

Model ini menggambarkan sebuah proses dari beberapa perspektip (yaitu; orientasi rekayasa; orientasi pengguna dll).

Umumnya ada 3 model proses P L: Air Terjun (tertua) Proses Evolusioner Rekayasa Perangkat Lunak berbasis komponen

Model Air Terjun

Komunikasi

Konstruksi

Pemodelan

Perencanaan

Penyerahan P L

Model Air Terjun1. Komunikasi :

a. Permulaan proyek

b. Teknik untuk mendapatkan spesifikasi kebutuhan pengguna.

2. Perencanaan:

a. Membuat prakiraan-prakiraan.

b. Penjadwalan.

c. Pelacakan.

3. Pemodelan:

a. Analisis.

b. Perancangan.

4. Konstruksi:

a. Penulisan kode-kode program.

b. Pengujian.

5. Penyerahan P L ke pengguna/pelanggan:

a. Pengiriman.

b. Dukungan terhadap pengguna.

c. Umpan balik.

Permasalahan Model Air Terjun1. Proyek P L yang nyata jarang mengikuti aliran

berturutan seperti model air terjun.2. Seringkali sulit bagi pelanggan untuk menetapkan

semua spesifikasi kebutuhan secara eksplisit. Model air terjun menghendaki hal seperti ini dan model ini sulit mengakomodasi ketidak pastian alamiah yang selalu hadir pada awal kebanyakan proyek.

3. Pelanggan dapat melihat hasil setelah selesai. Suatu kesalahan, jika tidak terdeteksi hingga program berjalan ditinjau, dapat saja berakibat fatal.

Model Proses Evolusioner

Model Proses Evolusioner

PerencanaanSecara cepat

Komunikasi

PemodelanPerancangansecara cepat

Pembentukanprototipe

Penyerahan P L ke pelangganPengiriman& Umpan Balik

Model Proses Evolusioner1. Idenya:

o Mengembangkan pelaksanaan awal.o Expose kepada pengguna untuk review dan komentar.o Terus diperbaiki sampai proses lengkap.

2. Terdiri dari 2 jenis:

a. Eksplorasi pengembangan (Exploratory development)o Tujuan: bekerja secara bersama-sama dengan pelanggan dan

mengembangkan sebuah sistem akhir berdasarkan spesifikasi awal secara garis besar.

o Harus dimulai dengan persyaratan awal yang jelas dan menambahkan fitur baru secara bertahap seperti yang diusulkan oleh pelanggan.

b. Prototipe yang tidak digunakan (Throw-away prototyping)oTujuan: Untuk memahami persyaratan sistem.oHarus mulai dengan persyaratan kurang dipahami untuk menjelaskan apa

yang benar-benar dibutuhkan.

Pro dan Kontra Proses EvolusionerPRO: Seringkali lebih efektif dibandingkan dengan model air terjun.

o Melibatkan pelanggan sehingga dapat memenuhi kebutuhan mendesak mereka.

Software dikembangkan secara bertahap.oPelanggan memahami lebih lanjut tentang sistem seiring berjalannya waktu.

KONTRA: Kurangnya visibilitas proses.

oTerlalu cepat berarti tidak efektif untuk menghasilkan dokumen begitu sering – Manajer biasanya membutuhkan laporan untuk mengukur kemajuan.

Sistem sering kurang terstruktur.o Perubahan terus menerus cenderung merusak struktur sistem.

Dibutuhkannya keterampilan khusus (misalnya program untuk prototipe cepat) .

Penerapan Proses EvolusionerPenerapan

1. Untuk sistem interaktif yang kecil atau menengah:o Umpan balik dari pelanggan adalah penting, Penambahan

secara bertahap lebih mudah dikelola.

2. Untuk bagian dari suatu sistem yang besar:o Bagian-bagian kritis dari sistem (yang biasanya persyaratan

dipahami dengan baik) masih mungkin perlu pendekatan konvensional seperti air terjun.

o Pendekatan Evolusi dapat digunakan untuk bagian-bagian yang sulit untuk menentukan semua keperluan diawal (misalnya pengguna antarmuka).

3. Untuk sistem dengan lifetime yang pendeko Tim yang kecil dan homogen

RPL Berbasis Komponen

1. Berdasarkan penggunaan kembali secara sistematis di mana sistem diintegrasikan dari komponen-komponen yang tersedia atau sistem COTS (Commercial-off-the-shelf) .

2. Tahapan proses:

Analisa komponen o Mengidentifikasi persyaratan sistem.o Pencarian dibuat berdasarkan pada persyaratan.

3. Modifikasi persyaratano Biasanya, tidak ada yang benar-benar sesuai. Persyaratan

perlu dimodifikasi agar sesuai dengan fungsi dan kendala dari komponen ditemukan.o Jika modifikasi tidak mungkin, ulangi pencarian dan analisis

untuk mencari alternatif.

RPL Berbasis Komponen

4. Desain sistem dengan penggunaan kembalio Kerangka kerja yang ada digunakan kembali atau

diubah. Jika tidak, rancang kerangka kerja baru.

5. Pengembangan dan integrasio Komponen yang cocok yang diintegrasikan untuk

menciptakan sistem baru. Komponen yang tidak cocok diganti dengan raancangan komponen yang baru.

6. Manakala komponen standar telah muncul, pendekatan ini menjadi semakin dipekerjakan.

Pro dan KontraPRO: Mengurangi jumlah perangkat lunak yang akan

dikembangkan. Turunkan biaya dan risiko. Pengiriman cepat.

KONTRA: Persyaratan modifikasi (dalam rangka untuk mencocokkan

Komponen) dapat mengalihkan dari tujuan yang sebenarnya dari sistem.

Kehilangan kontrol.

• Organisasi (pengguna) tidak dapat mengendalikan versi.

Proses Iterasi (pengulangan) Persyaratan sistem selalu berkembang dengan

berjalannya suatu proyek. Proses iterasi adalah normal terutama untuk sistem

yang besar. Iterasi dapat diterapkan ke setiap model dari proses Dua pendekatan yang digunakan:

• Pengiriman bertahap (Incremental delivery)• Pembangunan model spiral (Spiral development)

Pengiriman bertahap (Incremental delivery)

Suatu pendekatan “berulang” dari model air terjun. Pengembangan dan pengiriman sistem di breakdown menjadi

tahapan penambahan daripada pengiriman tunggal.• Setiap kenaikan tahapan memberikan tambahan dari fungsi yang diperlukan.

Persyaratan dari pengguna diprioritaskan.• Persyaratan prioritas tertinggi dimasukkan dalam kenaikan awal.

Manakala pembangunan suatu tahapan dimulai, persyaratan dibekukan.• Persyaratan untuk tahapan berikutnya dapat mulai dikembangkan.

Extreme Programming adalah varian dari pengiriman bertahap.• Pengembangan dan pengiriman dari fungsionalitas tahapan yang sangat kecil.

• Mengandalkan perbaikan kode yang konstan , keterlibatan pengguna dalam tim pengembangan dan pemograman.

Pro dan KontraPRO: Pelanggan tidak perlu menunggu sampai seluruh sistem disampaikan sebelum mereka

bisa mendapatkan nilai dari itu.• Tahapan pertama biasanya adalah fungsi-fungsi yang kritis.

Tahapan awal bertindak sebagai prototipe untuk membantu mendatangkan persyaratan pada tahapan berikutnya.

Menurunkan resiko kegagalan proyek secara keseluruhan. Prioritas tertinggi dari layanan sistem cenderung mendapatkan pengujian yang

terbaik.

KONTRA: bertahap harus relatif kecil (<20.000 baris kode), jika tidak, masalah akan timbul. Setiap tahapan harus memberikan suatu fungsionalitas.

• Sulit untuk memetakan kebutuhan pelanggan menjadi “tahapan-tahapan" dengan tepat .

Persyaratan tidak didefinisikan secara rinci sampai suatu tahapan akan diimplementasikan.

• Sulit untuk mengidentifikasi fasilitas umum yang dibutuhkan oleh semua tahapan.

 

Penerapan (aplikasi)

Hal ini sangat berguna ketika staf yang ada terbatas/tidak tersedia.• Kenaikan yang awal dapat dikembangkan dengan lebih sedikit orang.

• Ketika memuaskan, lebih banyak staf tambahan dapat ditambahkan untuk tahapan berikutnya.

Ketika bagian-bagian tertentu dari sistem “tidak berkembang ".• Kenaikan direncanakan berdasarkan pada ketersediaan bagian-bagian tersebut.

Model Pembangunan Spiral Proses direpresentasikan sebagai spiral bukan

sebagai urutan kegiatan dengan perjalanan mundur (backtracking).

Setiap loop dalam spiral merupakan suatu fasa dalam proses.

Tidak ada fase tetap seperti spesifikasi atau desain.• Loops pada spiral dipilih tergantung pada apa yang

dibutuhkan. Risiko secara eksplisit dinilai dan diselesaikan

selama proses berlangsung.

Model Pembangunan SpiralPerencanaanPembuatan prakiraan-prakiraaanPenjadwalanAnalisis terhadap resiko-resiko PL

Komunikasi PermodelanAnalsisPerancangan

KonstruksiPenulisan kode-kode programPengujian

Penyerahan P L/sistem ke para pelanggan/penggunaPengiriman Umpan balik

Mulai

Model Pembangunan Spiral

Model Pembangunan Spiral Menentukan tujuan

• Tujuan khusus bagi setiap tahap diidentifikasi.

Penilaian dan pengurangan risiko• Risiko dinilai dan kegiatan-kegiatan diterapkan untuk

mengurangi risiko utama.

Pengembangan dan validasi• Sebuah model pengembangan untuk sistem dipilih yang dapat menjadi

salah satu model umum/generik.

Perencanaan• Proyek ini ditinjau dan tahap berikutnya dari spiral

direncanakan.

Pro dan KontraPRO: Menggabungkan "prototyping" dan "berulang" pendekatan. Software berkembang sebagai proses berlangsung. Pengembang dan pelanggan memahami lebih baik dan bereaksi terhadap

risiko pada setiap tingkat evolusi. Dapat disesuaikan di seluruh siklus hidup. Satu siklus untuk setiap tahap.

KONTRA: Sulit untuk meyakinkan pengguna (dalam kontrak) bahwa proses ini

terkendali. Memerlukan manajer risiko / ahli untuk berhasil. Jika risiko utama tidak ditemukan dan dikelola, akan terjadi masalah.

Contoh Aplikasi

30

Motor Stepper

Sensor Inframerah

200 mm

Laptop

Kamera web

Lampu fluorescent

Contoh aplikasi RPL

31