Rekayasa Perangkat Lunak PDF

REKAYASA PERANGKAT LUNAK
( RPL )
MULAI MATERI
Tujuan Pembelajaran
1. Memahami dan rnenggunakan metode-metode pengemhangan perangkat
lunak termasuk pernbuatan, peneliharaan, rnanajemen organisa,si
pengernbangan perangkat lunak, kebutuhan sisteul dan manajemen kualitas
untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan
efektif untuk pengguna.
2. Memahami konsep dasar rekayasa perangkat lunak, Software Requirement,
Spesifikasi Kebutuhan Perangkat Lunak (SKPL), Proses Perangkat Lunak,
tnodel dan metode lekayasa perangkat lunak, practice Rekayasa Perangkat
Lunak,
3. Menerapan berbagai model dan metode proses Perangkat Lunak, Strategi
Pengujian Perangkat Lunak dan Teknik Pargujian Perangkat Lunak.
Capaian Pembelajaran
Mahasiswa diharapkan mampu :
1. Memahami Konsep Dasar Rekayasa Perangkat Lunak
2. Memahami Software Requerement
3. Memahami Spesifikasi Kebutuhan Perangkat l,unak (SKPL)
4. Memahami Proses Perangkat Lunak
5. Memahami Metode Rekayasa Perangkat Lunak
6. Memahami Practice Rekayasa Perangkat Lunak
7. Memahami Model Proses Perangkat Lunak
8. Memahami Strategi Pengujian Perangkat Lunak
9. Memahami Teknik Pengujian Perangkat Lunak
Metode Pembelajaran
Ceramah Praktek
Latihan Project
Metode Penilaian
10%
Kehadiran
20%
Tugas Harian
30% Project Akhir
20%
UTS
20%
UAS
Peraturan Kelas
Introduction
PERTEMUAN 1
PENGENALAN PERANGKAT LUNAK
Definisi Perangkat Lunak
• Perangkat Lunak (Pressman, 1997).
– Instruksi (program komputer) yang bila dieksekusi
dapat menjalankan fungsi tertentu
– Struktur data yang dapat membuat program
memanipulasi informasi
– Dokumen yang menjelaskan operasi dan
penggunaan program
Karateristik Perangkat Lunak
• Perangkat lunak dikembangkan atau direkayasa, jadi tidak
diproduksi dalam pengertian klasik
• Merupakan produk yang unik (tidak ada seri produksi).
• Perangkat lunak tidak pernah akan rusak/aus karena selalu
diperbaharui
• Tidak terlihat (invisible).
• Perangkat lunak pada umumnya dibangun sesuai keinginan, jadi
tidak dibentuk dari komponen yang sudah ada.
• Fleksibel, sehingga mudah dimodifikasi.
• Dihubungkan (linked) dengan sistem komputer.
Aplikasi Perangkat Lunak
• Dilihat dari sudut pandang fungsinya:
1. Perangkat Lunak Sistem
2. Perangkat Lunak Aplikasi
• Dilihat dari sudut pandang Aplikasinya:
1. Perangkat Lunak Sistem (Sistem Software)
2. Perangkat Lunak Waktu Nyata (Real Time Software)
3. Perangkat Lunak Bisnis (Business Software)
4. Perangkat Lunak Rekayasa dan Sains (Engineering and Scientific Software)
5. Embedded Software
6. Perangkat Lunak Komputer Pribadi (Personal Computer Software)
7. Perangkat Lunak Intelegensia Buatan (Artificial Intelligent Software)
Instalasi dan Konfigurasi AppServ
2. License Agreement : AppServ berada dibawah lisensi GNU/GPL. Anda harus membaca
persetujuan ini sebelum install. If you agree for this license click Next to go to next step. If
you not agree click Cancel to cancel install.
3. Choose Install Location: AppServ default location is C:AppServ. If you need to change
destination click Browse botton to change your destination for AppServ program and then
click Next to go to next step.
4. Select Components : AppServ default package components it's checked all package.
If you need to choose some package to install. You can click at check box.
- Apache HTTP Server is a Web Server.
- MySQL Database is a Database Server.
- PHP Hypertext Preprocessor is a PHP Programming processor.
- phpMyAdmin is a MySQL Database control via WWW. If you complete choosing it click Next
to go next step.
5. Apache Configuration : This screen for specify Apache configure.
Server Name You must specify Server Name e.g. www.appservnetwork.com.
Admin Email You must specify Admin Email e.g. root@appservnetwork.com
HTTP Port You must specify HTTP port for Apache Web Server.
6. MySQL Configuration :
Root Password You must enger root password for MySQL Database.
Default user for this password is root .
Character Sets Specify for data storage language and collations.
Old Password If you have problem when you coding PHP code with
Old MySQL API.
And found error Client does not supportauthentication
protocol requested by server;
consider upgrading MySQL client
You must check this option to avoid error.
Enable InnoDB If you use InnoDB must check this option.
7. Complete AppServ setup : Setup ask for start Apache and MySQL
immediately. Click Finish to end this setup and AppServ prompt to use.
Copyright © by AppServNetwork All Right Reserved.

Published on: 2006-10-10 (37140 reads)
PERTEMUAN 2
SOFTWARE REQUIREMENT
Prinsip Kebutuhan Perangkat Lunak
Kebutuhan perangkat lunak meliputi :
SPESIFIKASI DAN VALIDASI

KEBUTUHAN PERANGKAT LUNAK
MANAJEMEN KEBUTUHAN
SELAMA SIKLUS HIDUP
PERANGKAT LUNAK
• Kebutuhan perangkat lunak menunjukkan kebutuhan dan
kendala yang terdapat pada perangkat lunak dan memiliki
kontribusi untuk menyelesaikan masalah.
• Area Kebutuhan Perangkat lunak berhubungan erat dengan
Desain Perangkat lunak, Pengujian Perangkat lunak,
Perawatan Perangkat lunak, Manajemen Konfigurasi
Perangkat lunak, Manajemen Rekayasa Perangkat lunak,
Proses Rekayasa Perangkat lunak, Model dan Metode
Rekayasa Perangkat lunak, dan Kualitas Perangkat lunak.
Prinsip Kebutuhan Perangkat Lunak
A. Defenisi
• Pada dasarnya kebutuhan perangkat lunak adalah sebuah properti yang harus diperlihatkan atau
ditunjukkan oleh perangkat lunak untuk menyelesaikan suatu permasalahan yang ada di dunia
nyata. Misal untuk otomatisasi pekerjaan pada proses bisnis, memperbaiki kekurangan pada
perangkat lunak, atau untuk mengontrol suatu alat. Kebutuhan perangkat lunak merupakan
kombinasi rumit dari kebutuhan berbagai orang di bermacam-macam tingkat organisasi dan
lingkungan di mana perangkat lunak akan dioperasikan.
• Properti yang esensial dari kebutuhan perangkat lunak harus dapat diverifikasi sebagai fitur individu
dalam persyaratan fungsional atau sebagai kebutuhan non-fungsional pada tingkat sistem.
Memverifikasi suatu kebutuhan perangkat lunak dapat menjadi perkerjaan yang sulit dan memakan
banyak biaya. Misal memverifikasi kebutuhan throughput pada call center mungkin membutuhkan
pengembangan perangkat lunak simulasi. Biasanya, kebutuhan perangkat lunak diidentifikasi secara
khusus sehingga dapat digunakan untuk manajemen konfigurasi perangkat lunak untuk seluruh
siklus hidup dari fitur dan perangkat lunak.
B. Proses dan Produk
• Parameter produk adalah kebutuhan pada software untuk
dikembangkan contohnya “Software harus memeriksa
prasyarat mata kuliah yang diambil mahasiswa” sedangkan
Parameter proses adalah batasan-batasan dalam
mengembangkan software. Contohnya pilihan teknik
verifikasi. Process requirement juga bisa ditetapkan oleh
organisasi pengembang, pelanggan atau pihak ketiga
seperti badan regulator.
Kebutuhan Perangkat Lunak
Knowledge Area
c. Kebutuhan fungsional dan non-fungsional
• Kebutuhan fungsional menjabarkan fungsi-fungsi yang akan
dilaksanakan software. Contohnya memformat teks.
Kadang disebut juga sebagai kapabilitas. Kebutuhan non-
fungsional memberikan batasan terhadap solusi yang akan
dihasilkan. Disebut juga sebagai quality requirement.
Kebutuhan jenis ini masih bisa dibagi lagi menjadi
performance requirements, maintainability requirements,
safety requirements, reliability requirements atau salah
satu kebutuhan perangkat lunak lainnya.
d. Emergent Properties
• Beberapa kebutuhan perangkat lunak merupakan
perwakilan dari emergent properties yaitu kebutuhan
yang mungkin timbul dan tidak bisa ditangani oleh satu
komponen saja. Keberhasilan dalam menanganinya
juga bergantung pada interoperasi dari berbagai
komponen yang ada. Emergent properties amat
bergantung pada arsitektur sistem.
e. Kebutuhan yang dapat diukur
• Kebutuhan perangkat lunak harus bisa dinyatakan
dengan jelas, tidak ambigu dan pada beberapa
bagiannya yang sesuai, kuantitatif. Contoh kebutuhan
yang memenuhi syarat : Sebuah perangkat lunak dari
suatu call center harus meningkatkan throughput
sebanyak 20% dan sistemnya hanya menghasilkan
kesalahan fatal dengan peluang lebih rendah.
f. Kebutuhan sistem dan kebutuhan perangkat lunak
• Dalam topik ini sistem berarti kombinasi dari elemen-
elemen yang berinteraksi untuk mencapai suatu tujuan
yang terdefinisikan. Ini termasuk hardware, software,
firmware, manusia, informasi, tehnik, fasilitas, layanan dan
berbagai elemen pendukung lainnya
• Kebutuhan sistem adalah kebutuhan untuk sistem secara
keseluruhan. Dalam sebuah sistem yang mengandung
komponen perangkat lunak, kebutuhan perangkat lunak
diperoleh dari kebutuhan sistem.
Kebutuhan Proses
1. Kebutuhan Proses
• Pada model proses perlu dipahami bahwa kebutuhan proses :
a. bukan kegiatan yang berawal-berakhir secara diskrit tetapi dimulai
dari awal suatu proyek dan terus disempurnakan selama siklus
hidup perangkat lunak;
b. mengidentifikasi kebutuhan perangkat lunak sebagai konfigurasi
item-item dan mengaturnya menggunakan manajemen
konfigurasi perangkat lunak yang sama dengan produk lain dari
proses siklus hidup perangkat lunak tersebut;
c. perlu diadaptasikan sesuai dengan konteks organisasi dan proyek
2. Aktor Proses
• Contoh umum dari stakeholder perangkat lunak adalah :
a. Pengguna : Kelompok yang kelak akan mengoperasikan perangkat lunak.
b. Pelanggan : Kelompok inilah yang akan memberlakukan suatu perangkat lunak ke
dalam suatu organisasi.
c. Analis Pasar : Analis pasar diperlukan untuk mengetahui kebutuhan pasar.
d. Regulator : Banyak bidang di mana aplikasi terkena regulasi misalnya perbankan
dan transportasi umum. Karenanya perangkat lunak yang dioperasikan pada
bidang – bidang semacam ini harus sesuai dengan ketentuan dari badan
regulator yang berwenang.
e. Perekayasa perangkat lunak : Kelompok ini memiliki hak yang sah untuk
mengambil keuntungan dari pengembangan suatu perangkat lunak, termasuk
menggunakan ulang beberapa komponennya untuk produk lain.
3. Dukungan dan Manajemen
• Bagian ini memperkenalkan sumber daya
manajemen proyek dibutuhkan oleh kebutuhan
proses. Tujuan utamanya adalah untuk membuat
hubungan antara kegiatan proses diidentifikasi
dalam kebutuhan proses dan isu biaya, sumber
daya manusia, pelatihan, dan alat-alat.
4. Kualitas dan Pengembangan
Topik ini berkaitan dengan penilaian kualitas dan pengembangan kebutuhan
proses. Tujuannya untuk menunjukkan peran kunci kebutuhan proses dari segi
biaya dan ketepatan waktu dari produk perangkat lunak dan tingkat kepuasan
pelanggan. Ini akan membantu mengarahkan kebutuhan proses dengan standar
kualitas dan model pengembangan untuk perangkat lunak dan sistem. Kualitas
proses dan Pengembangan berkaitan erat dengan Kualitas Perangkat lunak dan
proses Rekayasa Perangkat Lunak, yang terdiri dari :
• kebutuhan proses, meliputi model dan standar pengembangan proses;
• pengukuran dan benchmarking;
• perencanaan perbaikan dan implementasi;
• keamanan
Elisitasi Kebutuhan Perangkat Lunak
• Elisitasi fokus pada asal-usul kebutuhan perangkat lunak dan
bagaimana programmer mendata kebutuhan tersebut.
• Tahap elisitasi merupakan tahap pertama dalam memahami
masalah yang harus dipecahkan oleh perangkat lunak.
• Salah satu prinsip dasar dari proses elisitasi adalah komunikasi yang
efektif antara berbagai stakeholders.
• Komunikasi ini berlanjut selama Software Development Life Cycle
(SDLC).
• Sebelum pengembangan dimulai, spesialis kebutuhan perangkat
lunak harus melakukan mediasi antara pengguna perangkat lunak
(dan stakeholder lainnya) dan programmer.
1. Sumber Kebutuhan
• Kebutuhan perangkat lunak muncul dari banyak sumber dan merupakan prinsip dasar untuk mengidentifikasi dan
mengevaluasi semua potensi sumber yang ada. Sumber kebutuhan perangkat lunak diantaranya :
a. Tujuan.
Tujuan bisa memberi motivasi bagi pembuatan perangkat lunak tetapi sayangnya sering diformulasikan secara
samar. Karenanya perlu dinilai biaya dan nilainya secara jelas.
b. Pengetahuan akan domain.
Seseorang perekayasa perangkat lunak harus mengetahui domain dari aplikasi yang dikerjakannya.
c. Pihak yang berkepentingan.
Banyak perangkat lunak yang tidak memuaskan karena terlalu condong pada kepentingan pihak tertentu saja dan
mengorbankan pihak lain. Hendaknya dipahami dan dicapai keseimbangan dari sudut pandang tiap pihak.
d. Lingkungan operasional.
Kebutuhan akan disusun dari lingkungan di mana perangkat lunak akan bekerja. Misalnya batasan timing untuk
real-time software atau kemampuan interoperasional
e. Lingkungan organisasional.
Seringakali suatu perangkat lunak dibuat untuk menunjang proses bisnis. Karenanya perlu diperhatikan struktur,
budaya kerja dan situasi politik dari organisasi yang bersangkutan.
2. Teknik Elisitasi
Setelah sumber kebutuhan telah diidentifikasi, programmer
dapat mulai memunculkan informasi persyaratan dari
mereka. Topik ini fokus pada teknik untuk mendapatkan
informasi yang relevan mengenai kebutuhan perangkat
lunak dari stakeholder. Ini adalah tugas yang sangat sulit
dan programer harus peka karena pengguna mungkin
memiliki kesulitan menggambarkan tugas-tugas mereka,
lupa menyertakan informasi yang sebenarnya penting, atau
mungkin tidak mau atau tidak mampu untuk bekerja sama.
• Beberapa teknik umum dalam elisitasi kebutuhan perangkat lunak diantaranya :
a. Wawancara.
Wawancara merupakan tehnik yang paling tradisional. Perlu diketahui batasan dan tata caranya.
b. Skenario
Teknik ini mampu memberikan konteks untuk menyusun kebutuhan perangkat lunak untuk pengguna. Memberikan
kerangka kerja bagi perekayasa perangkat lunak dengan membolehkan pertanyaan seperti “Bagaimana jika…” atau
“Bagaimana ini dikerjakan”.
c. Prototipe
Teknik ini bisa memberi kejelasan pada kebutuhan perangkat lunak yang masih kabur. Teknik ini bertindak mirip dengan
skenario karena bisa memberikan konteks di mana pengguna bisa tahu informasi apa yang harus diberikan.
d. Pertemuan terfasilitasi.
Teknik ini baik untuk menghimpun pandangan berbagai pihak yang berkepentingan. Bisa pula timbul – saran atau ide yang
membantu. Selain itu juga bisa mengenali konflik antar kebutuhan perangkat lunak. Tetapi pertemuan sebaiknya
menggunakan jasa seorang fasilitator untuk mencegah / mengendalikan kemungkinan dominasi pihak tertentu.
e. Observasi.
Teknik ini relatif mahal namun wajib karena mungkin saja proses bisnis terlau kompleks dan canggih untuk dijelaskan secara
lisan. Perekayasa perangkat lunak harus masuk ke dalam lingkungan kerja pengguna dan mengamati interaksi pengguna
dengan perangkat lunak dan sesama pengguna lain.
Analisis Kebutuhan Perangkat Lunak
• Pada analisis kebutuhan membahas proses analisa
kebutuhan untuk :
a. Mendeteksi dan menangani konflik antara kebutuhan
perangkat lunak;
b. Mencari keterkaitan perangkat lunak dan bagaimana
interaksinya dengan lingkungan organisasional dan
operasional;
• Topik ini berkaitan dengan proses menganalisis persyaratan
untuk menguraikan persyaratan sistem untuk menurunkan
persyaratan perangkat lunak.
1. Klasifikasi Kebutuhan
a) Fungsional dan non fungsional
b) Apakah suatu kebutuhan perangkat lunak didapat dari satu atau lebih kebutuhan
dengan level lebih tinggi atau merupakan emergent propety (sub bagian 1.4)
atau ditetapkan oleh pihak yang berkepentingan atau sumber lain.
c) Apakah kebutuhan perangkat lunak ada pada produk atau proses.
d) Prioritas. Secara umum, semakin tinggi prioritas suatu kebutuhan perangkat
lunak semakin mendesak pula untuk dipenuhi dalam produk akhir.
e) Cakupan dari kebutuhan perangkat lunak. . Hal ini sangat berpengaruh pada
arsitektur perangkat lunak dan desain komponen.
f) Stabilitas. Kebutuhan perangkat lunak kadang berubah dalam suatu siklus hidup
perangkat lunak bahkan mungkin dalam proses pengembangannya.
2. Konsep Model
• Pemodelan dari permasalahan riil adalah kunci
dari analisa kebutuhan perangkat lunak.
• Tujuannya untuk membantu memahami
permasalahan. Model konseptual terdiri dari
model entitas dari domain permasalahan yang
disusun untuk mewakili relasi riil dan
ketergantungan riil.
• Ada beberapa model yang bisa dikembangkan. Antara lain aliran data dan kontrol,
model keadaan, pelacakan even, interaksi pengguna, model objek, model data dan
lain-lain.
• Faktor yang mempengaruhi pemilihan pemodelan :
a. Sifat dari permasalahan. Beberapa tipe perangkat lunak menuntut agar aspek
tertentu dianalisa secara menyeluruh
b. Keahlian perekayasa perangkat lunak. Lebih baik menggunakan notasi atau
metode permodelan yang sudah familier.
c. Kebutuhan proses dari pelanggan. Mungkin pelanggan ingin menetapkan notasi
atau metode pemodelan tertentu
d. Ketersediaan metode dan alat. Meskipun cocok namun jika tidak ditunjang
dengan keahlian dan alat yang baik, suatu notasi atau metode tidak bisa dipakai.
3. Desain Arsitektural dan Alokasi Kebutuhan
Desain arsitektural adalah suatu tahap di mana kebutuhan proses
dilakukan bersamaan dengan desain sistem atau perangkat lunak.
Karenanya sulit memisahkan dua aktivitas tersebut. Desain
arsitektural sangat berhubungan dengan pemodelan konseptual.
Pemetaan domain entitas dunia nyata menjadi komponen
perangkat lunak tidak selalu jelas, sehingga desain arsitektural
dianggap sebagai topik terpisah. Kebutuhan untuk notasi dan
metode secara umum sama pada pemodelan konseptual dan
desain arsitektural.
4. Negoisasi Kebutuhan
Topik ini disebut juga sebagai “penyelesaian konflik”. Topik
ini membahas penanganan masalah kebutuhan perangkat
lunak di mana timbul konflik antara dua pihak yang sama-
sama berkepentingan, antara kebutuhan dengan sumber
daya atau kebutuhan fungsional dan non fungsional. Dalam
kebanyakan kasus, keputusan yang diambil secara unilateral
bukanlah sikap bijaksana. Karenanya penting untuk
mencapai konsensus dengan pihak yang berkepentingan.
• Tugas Kelompok
PERTEMUAN 3
SPESIFIKASI KEBUTUHAN PERANGKAT
LUNAK (SKPL)
Spesifiksi Kebutuhan
• Pada kebanyakan profesi perekayasaan, istilah spesifikasi merujuk pada
kegiatan memberikan nilai numerik atau batas pada tujuan produk akhir.
Tetapi definisi ini tidak bisa dipakai pada rekayasa perangkat lunak
mengingat banyaknya kebutuhan yang ada dan kompleksitas interaksinya.
Karenanya pada rekayasa perangkat lunak istilah “spesifikasi kebutuhan
perangkat lunak” mengacu pada pembuatan dokumen baik fisik maupun
elektronis.
• Pada sistem yang kompleks, terutama yang melibatkan banyak kompone
non-software, ada 3 jenis dokumen yang dibuat yaitu definisi sistem,
requirement sistem dan requirement perangkat lunak. Pada produk
perangkat lunak yang sederhana hanya satu dari 3 jenis dokumen itu yang
perlu dibuat. Semua tiga jenis dokumen itu akan dijelaskan di sini.
1. Dokumen Definisi Sistem
Dokumen ini menyimpan requirement sebuah sistem. Dokumen
ini mendaftar semua kebutuhan perangkat lunak beserta
keterangan latar belakang tujuan keseluruhan sebuah sistem,
lingkungan yang menjadi sasaran dan pernyataan batasan, asumsi
dan kebutuhan non-fungsional. Mungkin juga di dalamnya
terdapat model konseptual yang didesain untuk memberikan
gambaran tentang konteks sistem, skenario pemakaian dan
entitas-entitas domain yang penting, termasuk juga data,
informasi dan aliran kerja.
2. Spesifikasi Kebutuhan Sistem
Para pengembang dari sebuah sistem berkomponen
software dan non-software yang cukup banyak, seringkali
memisahkan deskripsi dari kebutuhan sistem dari deskripsi
kebutuhan perangkat lunak. Dengan cara ini, kebutuhan
sistem dispesifikasikan, kebutuhan perangkat lunak didapat
dari kebutuhan sistem dan kebutuhan untuk komponen
perangkat lunak dispesifikasikan . Karena merupakan
bidang rekayasa sistem, dokumen jenis ini tidak akan
dibahas terperinci di sini.
3. Spesifikasi Kebutuhan Perangkat Lunak
Dokumen jenis ini mendirikan dasar untuk sebuah perjanjian antara
pelanggan dan kontraktor atau penyuplai tentang apa yang
seharusnya dan tidak seharusnya dikerjakan oleh produk perangkat
lunak. Untuk pembaca yang kurang paham hal-hal yang sifatnya
teknis, dokumen jenis ini juga didampingi oleh dokumen definisi
kebutuhan perangkat lunak. Dokumen ini memungkinkan penilaian
mendalam tentang kebutuhan perangkat lunak sebelum desain
dimulai sehingga mengurangi keharusan desain ulang. Dokumen ini
juga memberikan dasar-dasar realistis untuk memperkirakan biaya,
risiko dan jadwal produksi.
Validasi Kebutuhan
• Kebutuhan dokumen difokuskan pada prosedur
validasi dan verifikasi. Kebutuhan akan validasi
untuk meyakinkan bahwa programer telah
mengerti tentang kebutuhan yang diperlukan,
dan juga sangat penting untuk membuktikan
bahwa dokumen kebutuhan dapat disesuaikan
dengan kebutuhan standard suatu perusahaan,
dan juga dapat mudah dipahami, konsisten, dan
lengkap.
1. Review Kebutuhan
Arti umum validation adalah memeriksa (inspection)
atau review (meninjau) dokumen kebutuhan.
Reviewer bertugas mencari error (look for errors),
asumsi yang salah (mistaken assumptions), hal-hal
yang kurang jelas (lack of clarity), dan penyimpangan
standar (deviation from standard practice). Hal ini
sangat penting dan mungkin membantu memberikan
petunjuk apa yang dicari dalam tabel checklists.
• Review kebutuhan terdapat pada :
a) penyelesaian dari dokumen definisi sistem;
b) dokumen spesifikasi sistem;
c) dokumen spesifikasi perangkat lunak;
d) spesifikasi dasar pada release baru;
e) atau pada langkah lain dalam suatu proses.
2. Prototyping
Prototyping secara umum berarti untuk melakukan
validasi, interpretasi software engineer mengenai
software requirements, sama seperti memperoleh
requirement baru. Keuntungan dari prototype adalah
akan memudahkan software engineer
menginterpretasikan asumsinya dan juga berguna
untuk mengetahui kembali jika terdapat kesalahan.
3. Validasi Model
Merupakan suatu hal yang dibutuhkan untuk mengesahkan
kualitas suatu model yang sedang dianalisis. Sebagai
contoh, dalam objek model sangat berguna untuk
melakukan static anlisis untuk menguji bahwa jalur
komunikasi antara objek itu ada, dimana dalam daerah
stakeholders, terjadi pertukaran data. Jika formal
specification notations digunakan, sangat memungkinkan
untuk menggunakan formal reasoning untuk membuktikan
spesifikasi properties.
4. Uji Kelayakan
Property yang diperlukan dari sebuah software requirement adalah
bahwa sangat mungkin untuk mengesahkan produk yang telah
selesai dapat memenuhinya. Requirements yang tidak dapat
divalidasi merupakan hanya sebuah ‘keinginan’. Sebuah tugas yang
penting adalah merencanakan bagaimana menguji masing-masing
requirement. Dalam berbagai kasus, desain acceptance tests yang
melakukannya. Mengidentifikasi dan mendesain acceptance tests
mungkin sangat sulit untuk non-functional requirement. Agar bisa
divalidasi, pertama harus dianalisis pada poin dimana dapat
ditunjukkan secara kuantitatif.
Manajemen
• Tidak semua organisasi mempunyai kebiasaan
mendokumentasikan dan mengatur kebutuhan
perangkat lunak. Namun, sejalan dengan
perkembangan perusahaan, pelanggan mereka
bertambah, dan produk mulai berkembang, mereka
menyadari perlunya untuk memperbaiki kebutuhan
perangkat lunak berdasarkan usulan-usulan
perubahan. Oleh sebab itu, dokumentasi kebutuhan
dan manajemen perubahan adalah kunci sukses dari
proses kebutuhan perangkat lunak.
1. Pertumbuhan Kebutuhan
Kebanyakan proyek didesak oleh lingkungannya, dan
banyak perubahan, atau revisi, dari software yang
ada. Sehingga, selalu tidak bisa melakukan
implementasi kebutuhan proses secara linear. Hampir
tidak pernah ada kebutuhan perangkat lunak dalam
skala besar yang dipahami dan dispesifikasi dengan
sempurna.
2. Manajemen Perubahan
Manajemen prubahan adalah pusat untuk
mengatur kebutuhan perangkat lunak. Topik
ini menggambarkan peran dari manajemen
perubahan, prosedur yang diperlukan, dan
analisa yang seharusnya digunakan untuk
usulan pengubahan.
3. Atribut Kebutuhan
Kebutuhan perangkat lunak sebaiknya tidak hanya terdiri
dari perincian dari apa yang dibutuhkan, tapi juga dari
informasi tambahan yang membantu mengatur dan
menafsirkan kebutuhan tersebut. Mungkin juga
memasukkan informasi tambahan seperti kesimpulan serta
sumber daya dari masing-masing kebutuhan, dan
perubahan sejarah. Atribut kebutuhan yang paling penting
adalah sebuah pengenal yang membuat kebutuhan
tersebut unik dan jelas.
4. Penelusuran Kebutuhan
Penelusuran kebutuhan fokus pada menelusuri sumber
kebutuhan dan memprediksi efek dari kebutuhan
tersebut. Prinsip dari penelusuran kebutuhan yaitu
melakukan analisis dampak bila dilakukan perubahan.
Kebutuhan perangkat lunak harus mampu telusur ke
belakang dan siapa stakeholder yang mengajukannya.
Kebutuhan perangkat lunak harus mampu telusur ke
depan yaitu kesesuaiannya dengan desain.
• Buat contoh dokumentasi kebutuhan
perangkat lunak
PERTEMUAN 4
PROSES PERANGKAT LUNAK
PROSES PERANGKAT LUNAK
Gambar Elemen Proses Perangkat Lunak

SIKLUS HIDUP PROSES
PERANGKAT LUNAK
System Development Life Cycle (SDLC) : Merupakan Siklus Pengembangan
Sistem (engineering system development)
SDLC menggambarkan 4 tahapan utama dari setiap tahapan kegiatan yaitu :
1) initiation
2) analysis
3) Design
4) implementation.
SIKLUS HIDUP PROSES PERANGKAT LUNAK
countinue...
Departemen Kehakiman AS mendefenisikan SDLC sebagai sebuah proses

pengembangan software yang digunakan oleh analyst system, untuk
mengembangkan sebuah sistem informasi.
SDLC mencakup kebutuhan (requirement), validasi, pelatihan, kepemilikan
(user ownership) sebuah sistem informasi yang diperoleh melalui investigasi,
analisis, desain, implementasi, dan perawatan software.
Software yang dikembangkan berdasarkan SDLC akan menghasilkan sistem
dengan kualitas yang tinggi, memenuhi harapan penggunanya, tepat dalam
waktu dan biaya, bekerja dengan efektif dan efsien dalam infrastruktur teknologi
informasi yang ada atau yang direncanakan, serta mudah dalam perawatan dan
pengembangan lebih lanjut
SEJARAH SDLC
CLICK HERE
Tahapan System Development
Life Cycle (SDLC)
1) System initiation adalah perencanaan awal untuk sebuah proyek guna
mendefinisikan lingkup, tujuan, jadwal dan anggaran bisnis awal yang
diperlukan untuk memecahkan masalah atau kesempatan yang
direpresentasikan oleh proyek.
Lingkup proyek yang mendefinisikan area bisnis yang akan ditangani oleh
proyek dan tujuan-tujuan yang akan dicapai. Lingkup dan tujuan pada
akhirnya berpengaruh pada komitmen sumber yaitu jadwal dan anggaran
yang harus dibuat supaya berhasil menyelesaikan proyek.
Life Cycle (SDLC)....continue
2) System analysis ialah studi domain masalah bisnis untuk merekomendasikan
perbaikan dan menspesifikasikan persyaratan dan prioritas bisnis untuk
solusi. Analisis system ditujukan untuk menyediakan tim proyek dengan
pemahaman yang lebih menyeluruh terhadap masalah-masalah dan
kebutuhan-kebutuhan yang memicu proyek. Area bisnis dipelajari dan
dianalisis untuk memperoleh pemahaman yang lebih rinci mengenai apa
yang bekerja, apa yang tidak bekerja dan apa yang dibutuhkan.
Life Cycle (SDLC) ....continue
3) System design adalah spesifikasi atau konstruksi solusi yang teknis dan
berbasis komputer untuk persyaratan bisnis yang diidentifikasikan dalam
analisis sistem.
Selama desain sistem, pada awalnya akan mengekspolarasi solusi teknis
alternatif. Setelah alternatif solusi disetujui, maka fase desain sistem
mengembangkan cetak biru (blueprint) dan spesifikasi teknis yang
dibutuhkan untuk mengimplementasikan database, program, antarmuka
pengguna dan jaringan yang dibutuhkan untuk sistem informasi,
Life Cycle (SDLC) ....continue
4) System implementation adalah konstruksi, instalasi, pengujian dan
pengiriman sistem ke dalam produksi (artinya operasi sehari-hari).
Implementasi sistem mengontruksi sistem informasi baru dan
menempatkannya ke dalam operasi, selanjutnya dilaksanakan pengujian.
Penilaian dan Pengembangan
Proses Perangkat Lunak
 Penilaian proses perangkat lunak digunakan untuk mengevaluasi bentuk dan isi proses perangkat
lunak dengan beberapa kriteria khusus.
 Penilaian proses dilakukan di semua level organisasi.
 Penilaian proses perangkat lunak meriview kriteria entry dan exit perangkat lunak, faktor dan
manajemen resiko.
 Penilaian proses perangkat lunak berbeda dengan audit. Penilaian dilakukan untuk menetapkan
level dari kemampuan atau kematangan untuk memperbaiki proses perangkat lunak.
 Sedangkan audit dilakukan untuk memastikan kesesuaian perangkat lunak dengan kebijakan dan
standar.
 Faktor kesuksesan penilaian dan pengembangan proses perangkat lunak yaitu sponsor,
perencanaan, pelatihan, pemimpin yang mampu dan berpengalaman, komitmen tim, manajemen
sasaran, penggunaan agen perubahan, proyek percontohan dan percobaan dengan alat.
Penilaian dan Pengembangan Proses
Perangkat Lunak......continue
1. Model Penilaian Proses Perangkat Lunak

Mencakup kriteria penilaian untuk proses perangkat lunak. Praktik-praktik ini dapat mengatasi
proses pengembangan perangkat lunak saja, atau juga dapat mencakup topik-topik seperti
perawatan perangkat lunak, perangkat lunak manajemen proyek, rekayasa sistem, atau
manajemen sumber daya manusia.
2. Metode Penilaian Proses Perangkat Lunak

Metode penilaian proses perangkat lunak dapat bersifat kualitatif atau kuantitatif. Penilaian
kualitatif mengandalkan penilaian dari ahli; sedangkan penilaian kuantitatif menetapkan nilai
numerik untuk proses software berdasarkan analisis bukti objektif.
Metode penilaian proses perangkat lunak meliputi perencanaan, fakta (dengan mengumpulkan
bukti-bukti melalui kuesioner, wawancara, dan observasi dari praktek kerja), pengumpulan dan
validasi data proses, dan analisis dan pelaporan. penilaian proses dapat mengandalkan subjektif,
penilaian kualitatif dari penilai, catatan, dan bukti lainnya.
Kualitas hasil penilaian tergantung pada metode penilaian proses perangkat lunak, integritas dan
kualitas data yang diperoleh, kemampuan tim penilai dan objektivitas, dan catatan selama
penilaian.
Tujuan dari penilaian proses perangkat lunak adalah untuk mendapatkan wawasan yang akan
menetapkan status dari proses atau proses dan memberikan dasar untuk perbaikan proses.
3. Model Pengembangan Proses Perangkat Lunak

Model pengembangan proses perangkat lunak menekankan pada siklus berulang dari perbaikan
terus-menerus. Sebuah siklus perbaikan proses software melibatkan subproses mengukur,
menganalisis, dan mengubah.
Model Plan-Do-Check-Act adalah pendekatan berulang yang biasa digunakan untuk perbaikan
proses software. Kegiatan perbaikan termasuk mengidentifikasi dan memprioritaskan perbaikan
yang diinginkan (perencanaan); memperkenalkan perbaikan, termasuk manajemen dan pelatihan
(melakukan) perubahan; mengevaluasi perbaikan.
Pengukuran Perangkat
Lunak
o pengukuran aktivitas manusia menambah nilai dan terlibat aktif dalam proses informasi
membantu untuk membentuk karakteristik khusus dari proses dan produk informasi
o evaluasi kuantitatif yang biasanya menggunakan metrik serta ukuran dapat menggunakan secara
langsung menentukan pencapaian tujuan kualitas numerik
o Pengukuran selalu menjadi fundamental bagi kemajuan untuk setiap disiplin rekayasa dan
pengujian perangkat lunak. pengukuran perangkat lunak dan metrik menjadi peran mendasar
dalam siklus hidup pengembangan perangkat lunak, dan Metrik perangkat lunak yang telah
digunakan dalam membuat keputusan kuantitatif/kualitatif maupun dalam penilaian risiko dan
pengurangan kendala dalam proyek perangkat lunak.
Lunak .... continue
1. Domain Metrik
o Metrik digunakan oleh industri perangkat lunak untuk mengukur proses
pembuatan, operasi, dan perawatan perangkat lunak.
o Metrik pada proyek pengembangan perangkat lunak berhubungan dengan
tenaga dan pikiran yang diperlukan untuk menyelesaikan proyek, sumber
daya yang digunakan untuk menyelesaikannya, dan metodologi yang
diterapkan, misalnya: waktu yang diperlukan untuk menyelesaikan, tenaga
ahli yang diperlukan, biaya-biaya yang dikeluarkan, dan metodologi yang
digunakan dalam pembuatan perangkat lunak.
Lunak .... continue
2. Tujuan Umum Pengukuran
Pengukuran adalah pemetaan dari dunia empiris ke dunia formal relasional. Akibatnya, ukuran
adalah jumlah atau simbol ditugaskan untuk suatu entitas dengan pemetaan ini untuk
mengkarakterisasi atribut (Sheikh Umar Farooq 2011).
Karakteristik pengukuran yang baik adalah :
1) Hasil dari proses pengukuran adalah direproduksi. (Hasil yang sama didapatkan dari waktu ke
waktu dan di seluruh situasi.)
2) Validitas - Proses pengukuran benar-benar mengukur apa yang dimaksudkan untuk
mengukur.
3) Sensitivitas - Proses pengukuran menunjukkan variabilitas dalam tanggapan ketika ada dalam
stimulus atau situasi.
Sehubungan dengan perangkat lunak, Pengukuran adalah proses yang berkesinambungan dalam
menetapkan, mengumpulkan, dan menganalisis data pada proses pengembangan perangkat
lunak dan produk-produknya dalam rangka untuk memahami dan mengontrol proses dan produk,
dan memberikan informasi yang berarti untuk meningkatkan proses dan produk
Lunak .... continue
Kemudian software sendiri biasanya diukur untuk melayani tujuannya diantaranya :
1) Karakterisasi
pengumpulan informasi tentang beberapa karakteristik dari proses perangkat lunak dan produk,
dengan tujuan mendapatkan ide yang lebih baik dari “apa yang terjadi. "
2) Evaluasi
menilai beberapa karakteristik dari proses perangkat lunak atau produk, misalnya berdasarkan
sejarah data dalam lingkungan pengembangan yang sama atau data yang tersedia dari sumber
eksternal.
3) Perbaikan
dengan menggunakan hubungan sebab-akibat untuk mengidentifikasi bagian dari proses atau
produk yang dapat berubah untuk mendapatkan efek positif pada beberapa karakteristik yang
menarik, dan mengumpulkan data setelah perubahan memiliki telah dilakukan untuk
mengkonfirmasi atau disconfirm apakah efeknya positif dan menilai luasnya.
Lunak .... continue
4) Prediksi
mengidentifikasi hubungan sebab-akibat antara karakteristik produk dan proses.
5) Pelacakan
akuisisi (mungkin konstan dan teratur) informasi tentang beberapa karakteristik perangkat lunak
proses dan produk dari waktu ke waktu, untuk un derstand jika karakteristik tersebut berada di
bawah pengendalian di on-akan proyek.
6) Validasi
mem-validasi praktik terbaik diidentifikasi eksperimen.
Lunak .... continue
3. Determinan Kualitas dan Efektivitas Perangkat Lunak
Kualitas perangkat lunak adalah gabungan yang kompleks dari berbagai faktor yang akan
bervariasi dan pelanggan yang berbeda kebutuhannya. Gabungan antara kebutuhan pengguna
perangkat lunak dan faktor-faktor lain akan menghasilkan kualitas perangkat lunak.
(Grady. 1992) mendefinisikan ukuran kualitas perangkat lunak dilihat dari beberapa aspek, yaitu :
1) Cacat per KLOC; dimana cacat diartikan kurangnya kesesuaian dengan persyaratan
2) Maintanabilitas; kemudahan dimana program dapat dikoreksi jika ditemukan kesalahan,
dapat beradaptasi jika lingkungan berubah. Mudah dikembangkan bila pelanggan
menginginkan perubahan.
3) Integritas; kemampuan sistem untuk menahan serangan terhadap sekuritasnya. Serangan
dapat berupa virus maupun hacker yang mengganggu program data maupun dokumen.
Lunak .... continue
 Pengukuran dapat dipisahkan dalam dua kategori, yaitu pengukuran langsung
dan pengukuran tidak langsung.
 Pengukuran langsung dalam proses rekayasa perangkat lunak berhubungan
dengan biaya dan sumber daya yang diperlukan, misalnya: pengukuran
jumlah baris kode, kecepatan eksekusi, ukuran memori, dan kesalahan yang
ditemui dalam suatu periode waktu.
 Pengukuran tidak langsung dari suatu produk berhubungan dengan
fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas, dan lain
sebagainya
Lunak .... continue
 Kesulitan yang biasanya dihadapi adalah pada saat melakukan
kombinasi pada metrik-metrik yang diukur disebabkan karena
sering terjadi perbedaan metrik antara idividu satu dengan
individu lainnya.
 Masalah tersebut biasa diatasi apabila dilakukan normalisasi
pada proses pengukuran.
 Dengan adanya normalisasi maka dapat dilakukan perbandingan
metrik pada cakupan yang lebih luas.
Lunak .... continue
 Karakteristik pengukuran yang baik yaitu :
a) Keandalan  Hasil dari proses pengukuran adalah
direproduksi. (Hasil yang sama didapatkan dari waktu ke
waktu dan di seluruh situasi.)
b)Validitas  Proses pengukuran benar-benar mengukur apa
yang dimaksudkan untuk mengukur.
c) Sensitivitas  Proses pengukuran menunjukkan variabilitas
dalam tanggapan ketika ada dalam stimulus atau situasi.
Size-Oriented Metrics
diperoleh dengan cara melakukan normalisasi ukuran

kualitas dan produktivitas dengan menghitung ukuran
dari perangkat lunak yang dibuat.
 Ukuran yang biasanya dijadikan sebagai acuan
normalisasi adalah LOC (lines of code).
Size-Oriented Metrics ...
continue
 Dari pengukuran jumlah LOC pada suatu perangkat lunak, dapat
diperoleh:
a) Kesalahan per KLOC (ribuan LOC)
b) Kekurangan atau cacat pada spesifikasi per KLOC
c) Harga per LOC
d) Jumlah halaman dokumentasi per LOC
Size-Oriented Metrics ...
continue
 Adapula beberapa metrik yang bisa dihitung adalah:
a) Kesalahan per orang-bulan
b) LOC per orang-bulan
c) Harga per halaman dokumentasi
Menurut Jones 1986, metrik berorientasi ukuran tidak dapat diterima secara
universal sebagai cara terbaik untuk mengukur proses rekayasa perangkat lunak.
Alasan yang dikemukakan adalah kadang-kadang fungsionalitas program dapat
dicapai dengan baris program yang lebih sedikit. Selain itu, untuk melakukan
estimasi LOC harus digunakan analisis desain tingkat tinggi.
Function-Oriented Metrics
menggunakan ukuran fungsionalitas yang dihasilkan oleh aplikasi sebagai nilai
normalisasi.
 Metrik berorientasi fungsi pertama kali diusulkan oleh Albrecth [1979], yang
menyarankan pengukuran yang disebut dengan function point (FP). FP
diperoleh dengan menggunakan hubungan empiris berdasarkan pengukuran
langsung dan estimasi terhadap kompleksitas perangkat lunak.
 Terdapat lima karakteristik yang digunakan sebagai acuan, yaitu:
a) Jumlah masukan (user inputs)
b) Jumlah keluaran (user outputs)
c) Jumlah permintaan (inquiry)
d) Jumlah berkas
e) Jumlah antarmuka eksternal
Function Points
 Diukur dari perspektif Functional dari software yang akan dibangun
 Function Point harus dilakukan oleh orang terlatih dan berpengalaman dalam
development software, karena dalam memberikan nilai-nilai dari setiap
komponen Function point bersifat subyektif, dan akan wajar apabila hasil
perhitungan function point seseorang akan berbeda dengan yang lain
Function poin harus dimasukkan sebagai bagian dari rencana proyek secara
keseluruhan
Hasil dari pengukuran menggunakan Function Point dapat digunakan untuk
mengestimasi biaya dan effort yang diperlukan dalam development perangkat
lunak.
Function Points... continue
Penghitungan Metrik Function Points
Pengukuran yang berhubungan dengan fungsi (Metric Function Oriented) adalah
pengukuran fungsionalitas yang disampaikan oleh aplikasi sebagai suatu nilai
normalisasi.
Metode ini sendiri terdiri dari banyak Variasi yang pada langkah/tahapan yang
ada maupun pada isi dari tiap tahapan yang muncul karena metode ini dapat
diubah sesuai dengan kebijakan perusahaan pengembang software. Namun
apapun varian yang digunakan oleh pengembang, hendaknya digunakan dengan
konsisten agar tercipta komparasi yang benar antara software-software yang
dinilai.
Kualitas Perangkat Lunak
Menurut Heri Abi Burachman Hakim 2008 yang dikutip
dari McCall menjelaskan bahwa kualitas perangkat lunak
diukur dari sebelas aspek yang merupakan gabungan
antara kebutuhan pengguna dan faktor-faktor lainnya
yang mempengaruhi kualitas sebuah perangkat lunak.
Kualitas Perangkat Lunak ... count
Aspek-aspek yang digunakan untuk mengukur kualitas sebuah perangkat lunak

adalah:
1) Kebenaran yaitu kemampuan perangkat lunak mampu memenuhi spesifikasi
dan misi kebutuhan pengguna
2) Reliabilitas yaitu kemampuan sebuah perangkat lunak dapat melaksanakan
fungsinya dengan tingkat ketelitian yang diperlukan.
3) Efisiensi yaitu sumber daya komputasi yang dibutuhkan oleh perangkat lunak
untuk melakukan fungsinya.
4) Integritas yaitu tingkat kemampuan kontrol akses ke perangkat lunak atau
data oleh orang yang tidak berhak.
Kualitas Perangkat Lunak ... count
5) Usabilitas yaitu usaha yang dibutuhkan untuk mempelajari, mengoperasikan,

menyiapkan input, dan menginterpretasikan output suatu perangkat lunak.
6) Maintanabilitas yaitu kemampuan perangkat lunak untuk mencari dan
membetulkan kesalahan pada sebuah perangkat lunak.
7) Fleksibilitas yaitu kemampuan perangkat lunak untuk memodifikasi perangkat
lunak operasional.
8) Testabilitas yaitu kemampuan yang diperlukan untuk menguji perangkat lunak
dan untuk memastikan apakah perangkat lunak telah melakukan fungsi-
fungsinya.
Faktor yang Mempengaruhi
Kualitas
Ada beberapa faktor yang menilai perangkat lunak dari tiga sudut
pandang bebeda yaitu :
1) operasi produk (menggunakannya)
2) revisi produk (mengubahnya)
3) transisi produk (memodifikasi untuk bekerja dalam lingkungan
yang berbeda
PERTEMUAN 5-6
MODEL DAN METODE REKAYASA
PERANGKAT LUNAK
Model Proses Perangkat Lunak
Model proses perangkat lunak merupakan deksripsi yang

disederhanakan dari proses perangkat lunak yang dipresentasikan
dengan sudut pandang tertentu.
Merupakan penyederhanaan sehingga model proses bisa
mencakup kegiatan yang merupakan bagian dari proses perangkat
lunak, produk perangkat lunak, peran orang yang terlibat pada
rekayasa perangkat lunak.
Model Proses Perangkat Lunak
1. Model Air Terjun (Waterfall)

2. Model Sekuensial Linier
3. Model Prototipe
4. Pengembangan Evolusioner
5. Pengembangan Sistem Formal
6. Pengembangan Berorientasi Pemakaian Ulang
Definisi
persyaratan
Perancangan
sistem dan
perangkat lunak
Implementasi dan
pengujian unit
Integrasi dan
pengujian sistem
Operasi dan
pemeliharaan
Gambar 1.1a Model Waterfall

Tahap-tahap utama dari model ini memetakan kegiatan-kegiatan pengembangan

dasar, yaitu:
1) Analisis dan Definisi persyaratan. Pelayanan, batasan dan tujuan sistem
ditentukan melalui konsultasi dengan user sistem. Persyaratan ini kemudian
didefinisikan secara rinci dan berfungsi sebagai spesifikasi sistem.
2) Perancangan sistem dan perangkat lunak. Proses perancangan sistem
membagi persyaratan dalam sistem perangkat keras atau perangkat lunak.
Kegiatan ini menentukan arsitektur sistem secara keseluruhan. Perancangan
perangkat lunak melibatkan identifikasi dan deskripsi abstraksi sistem
perangkat lunak yang mendasar dan hubungan-hubungannya.
3) Implementasi dan pengujian unit. Pada tahap ini, perancangan perangkat lunak
direalisasikan sebagai serangkaian program atau unit program. Pengujian unit
melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasi.
4) Integrasi dan pengujian sistem. Unit program atau program individual diintegrasikan
dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem
telah dipenuhi. Setelah pengujian sistem, perangkat lunak dikirim kepada pelanggan.
5) Operasi dan pemeliharaan. Biasanya merupakan fase siklus hidup yang paling lama.
Sistem diinstall dan dipakai. Pemeliharaan mencakup koreksi dan berbagai error yang
tidak ditemukan pada tahap-tahap terdahulu, perbaikan atas implementasi unit
sistem dan pengembangan pelayanan system, sementara persyaratan-persyaratan
baru ditambahkan.
Sekuensial linier untuk rekayasa perangkat lunak, yang sering disebut juga dengan “siklus
kehidupan klasik” atau “fase lingkaran”.
Definisi Masalah
Status Quo Pengembangan Teknis
Penyatuan Solusi
Gambar 1.2a Fase lingkaran pemecahan masalah (Raccoon, 1995)

Problem
Definition
Status Solution
Quo Integration
Teknikal
Development
Problem
Definition
Status Solution
Quo Integration
Status Quo
Teknikal
Development
Problem
Definition
Status Solution
Quo Integration
Teknikal
Development
Gambar 1.2b Fase-fase di dalam fase lingkaran pemecahan masalah (Raccoon, 1995)
Pemodelan Sistem Informasi
Analisis Desain Kode Tes
Gambar 1.3 Model sekuensial linier

Model sekuensial linier melingkupi aktivitas-aktivitas sebagai berikut:

a) Rekayasa dan Pemodelan Sistem/Informasi
Rekayasa dan pemodelan sistem/informasi perangkat lunak harus
berhubungan dengan elemen-elemen yang lain seperti perangkat lunak,
manusia, dan database.
Rekayasa dan analisis sistem menyangkut pengumpulan kebutuhan pada
tingkat sistem dengan sejumlah kecil analisis serta desain tingkat puncak.
Rekayasa informasi mencakup juga pengumpulan kebutuhan pada tingkat
bisnis strategis dan tingkat area bisnis.
b) Analisis Kebutuhan Perangkat Lunak

Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada
perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat
lunak (analis) harus memahami domain informasi, tingkah laku, unjuk kerja, dan
antar-muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun
perangkat lunak di dokumentasikan dan dilihat lagi dengan pelanggan.
c) Desain
Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada
empat atribut sebuah program yang berbeda; struktur data, arsitektur perangkat
lunak, representasi interface, dan detail (algoritma) procedural. Proses desain
menerjemahkan syarat/kebutuhan ke dalam sebuah representasi perengkat lunak yang
dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana
persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat
lunak.
d) Generasi Kode
Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca.
Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan
cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.
e) Pengujian
Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus
pada logika internal perangkat lunak, memastikan bahwa semua pernyataan
sudah diuji, dan pada eksternal fungsional – yaitu mengarahkan pengujian
untuk menemukan kesalahan-kesalahan dan memastikan bahwa input yang
akan memberikan hasil actual yang sesuai dengan hasil yang dibutuhkan.
f) Pemeliharaan
Perangkat lunak akan mengalami perubahan setelah disampaikan kepada
pelanggan (perkecualian yang mungkin adalah perangkat lunak yang
dilekatkan). Perubahan akan terjadi karena kesalahan-kesalahan ditentukan,
karena perangkat lunak harus disesuaikan untuk mengakomodasi perubahan-
perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang
dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang
baru), atau karena pelanggan membutuhkan perkembangan fungsional atau
unjuk kerja. Pemeliharaan perangkat lunak mengaplikasikan lagi setiap fase
program sebelumnya dan tidak membuat yang baru lagi.
Masalah-masalah yang kadang–kadang terjadi ketika model sekuensial linier

diaplikasikan :
a) Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh
model. Meskipun model linier bisa mengakomodasi iterasi, model itu
melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan-
perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.
b) Kadang-kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya
secara ekplisit. Model linier sekuensial memerlukan hal ini dan mengalami
kesulitan untuk mengakomodasi ketidakpastian natural yang ada pada
bagian awal beberapa proyek.
d) Pelanggan harus bersikap sabar. Sebuah versi kerja dari program-program itu
tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan
besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji
ulang, bias menjadi petaka.
e) Pengembang sering melakukan penundaan yang tidak perlu. Di dalam
analisis yang menarik tentang proyek actual, (Bradac, 1994) mendapatkan
bahwa sifat alami dari siklus kehidupan klasik membawa kepada blocking
state dimana banyak anggota tim proyek harus menunggu tim yang lain
untuk melengkapi tugas yang saling memiliki ketergantungan. Kenyataannya,
waktu yang dipakai untuk menunggu bisa mengurangi waktu untuk usaha
produktif! Blocking state cenderung menjadi lebih lazim pada awal dan akhir
sebuah proses sekuensial linier.
oMasing-masing dari masalah tersebut bersifat riil.

oParadigma siklus kehidupan klasik memiliki tempat yang terbatas
namun penting di dalam kerja rekayasa perangkat lunak.
oParadigma itu memberikan template dimana metode analisis,
desain, pengkodean, pengujian, dan pemeliharaan bisa dilakukan.
oSiklus kehidupan klasik tetap menjadi model bagi rekayasa
perangkat lunak yang paling luas dipakai.
oSekalipun memiliki kelemahan, secara signifikan dia lebih baik
daripada pendekatan yang sifatnya sembrono kepada
pengembangan perangkat lunak.
3. Model Prototipe
Yang dikenal dengan perancangan kilat
Gambar 1.4 Prototipe Paradigma

3. Model Prototipe
Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk

mengidentifikasi kebutuhan perangkat lunak.
Bila prototype yang sedang bekerja dibangun, pengembang harus
mempergunakan fragmen-fragmen program yang ada atau
mengaplikasikan alat-alat bantu (contohnya report generator,
window manager, dll) yang memungkinkan program yang bekerja
untuk dimunculkan secara cepat.
Pengembangan evolusioner berdasarkan ide untuk

mengembangkan implementasi awal, memperlihatkannya
kepada user untuk dikomentari, dan memperbaikinya
versi demi versi sampai sistem yang memenuhi
persyaratan diperoleh
Spesifikasi Versi awal
Penjelasan garis
besar Pengembangan Versi menengah
Versi akhir
Versi akhir
Validasi Versi akhir
Gambar 1.5 Model Evolusioner

5. Pengembangan Sistem
Formal
Pengembangan sistem formal merupakan pendekatan terhadap
pengembangan perangkat lunak yang memiliki kesamaan dengan
model air terjun (waterfall). Tetapi proses pengembangannya
didasarkan pada transformasi matematis dari spesifikasi sistem
menjadi program yang dapat dijalankan.
5. Pengembangan Sistem Formal
Definisi Transformasi Integrasi dan

Spesifikasi Formal
Persyaratan Formal Pengujian Sistem
Gambar 1.6 Model Sistem Formal

6. Pengembangan Berorientasi
Pemakaian Ulang
Pengembangan berorientasi pemakaian ulang terjadi secara
informal ketika orang yang bekerja di sebuah proyek mengetahui
adanya rancangan atau kode yang mirip dengan yang dibutuhkan.
Maka mereka mencari rancangan atau kode ini, memodifikasinya
sebagaimana dibutuhkan, dan menggabungkannya dalam sistem
6. Pengembangan Berorientasi Pemakaian Ulang
Spesifikasi Analisis Memodifikasi

Persyaratan Komponen Persyaratan
Perancangan Sistem
dengan pemakaian
ulang
Pengembangan dan
integrasi
Gambar 1.7 Model

Pengembangan
Berorientasi Validasi Sistem
Pemakaian Ulang
TUGAS
1. Buatlah contoh sebuah sistem yang menggunakan model

waterfall
2. Buatlah contoh sebuah sistem yang menggunakan model
sekuensial linear
PERTEMUAN 7
STUDY CASE
PERTEMUAN 8
UJIAN TENGAH SEMESTER (UTS)
PERTEMUAN 9
PRACTICE REKAYASA PERANGKAT LUNAK
Materi :
• Prinsip memandu proses
• Prinsip memandu praktik
• Komunikasi
• Perencanaan
• Pemodelan
• Konstruksi
• Deployment (Penyerahan)
Apakah “Proses”?
What … ?
Apakah “Praktik”?
• Praktek adalah sejumlah konsep, prinsip,
metode dan tools that yang harus dimiliki
ketika software direncanakan dan
dikembangkan.
• Konsideran teknis dan praktis, yang berada di
dalam proses perangkat yang berada di dalam
proses perangkat lunak, sesuatu yang
dibutuhkan untuk membangun perangkat lunak
komputer berkualitas tinggi.
Esensi dari Praktek
• Esensi dari Praktek Rekayasa Perangkat Lunak
diantaranya:
1. Memahami Permasalahan (Komunikasi dan
Analisis)
2. Merencanakan Solusi (Pemodelan dan Desain
Perangkat Lunak)
3. Melaksanakan Rencana (Pembuatan Kode)
4. Memeriksa Akurasi Hasil (Menguji dan Quality
Assurance)
Prinsip Inti RPL
• Menyediakan nilai pada konsumen dan pengguna
• KIS—keep it simple!
• Mengelola produk dan visi project
• Apa yang anda hasilkan, yang lain akan
memanfaatkan
• Terbukalah pada masa depan
• Rencaana ke depan untuk menggunakan kembali
• Berpikir !
Praktek-Praktek RPL
Kerangka kerja proses Mengidentifikasi :
umum :
• Prinsip-prinsip
• Komunikasi
• Perencanaan • Bagaimana memulai
• Pemodelan praktek
• Konstruksi • Sekelompok tugas yang
• Deployment bisa diperpendek
Praktek Komunikasi
Prinsip dasar komunikasi
• Mendengar • Kolaborasi dengan
konsumen
• Persiapkan sebelum • Tetap fokus
komunikasi • Buat gambar ketika ada
• Fasilitasi komunikasi sesuatu yang tidak jelas
• Tatap muka adalah • Terus bergerak
yang terbaik • Negosiasi sukses ketika dua
belah pihak menang /
• Buat keputusan dan mendapat kesepakatan
catatan Tertulis
Praktek Komunikasi
(countinue..)
 Inisiasi
• Pihak terkait harus dekat satu dengan  Buat lebih detail
yang lain • Stakeholder harus
• Pastikan komunikasi interaktif mendefinisikan
• Ciptakan ekosistem tim yang solid skenario penggunaan
• Gunakan struktur tim yang tepat • Ambil fungsi-fungsi
 Sekelompok tugas yang dapat utamanya
diperpendek  Review hasilnya
• Kenali siapa yang perlu diajak bicara dengan semua
• Tentukan mekanisme terbaik untuk stakeholder
komunikasi
• Buat tujuan keseluruhan dan
Praktek Perencanaan
 Prinsip-prinsip :
• Pahami ruang lingkup proyek • Sesuaikan hal-hal kecil yang
• Libatkan konsumen (dan berserakan ketika anda
stakeholder yang lain) merencanakan
• Kenali bahwa perencanaan • Tentukan bagaimana kualitas dapat
adalah iteratif digapai
• Lakukan estimasi berdasar • Tentukan bagaimana anda dapat
apa yang anda ketahui mengakomodasi perubahan
• Sadari resiko • Lacak apa yang telah anda
• Realistis rencanakan
Praktek Perencanaan (continuee..)
 Inisiasi
Berikan pertanyaan-
pertanyaan :
• Mengapa sistem mulai • Dimana mereka ditempatkan
dikembangkan ? (secara organisatoris)?
• Apa yang akan dikerjakan ? • Bagaimana tugas diselesaikan,
• Kapan itu akan selesai ? baik secara teknis maupun
• Siapa yang akan bertanggung manajerial ?
jawab? • Berapa banyak untuk masing-
masing sumberdayanya ?
Praktek Perencanaan
(continuee..)
Sekelompok tugas yang

bisa diperpendek:
• Periksa kembali ruang • Buat rencana bertahap :
lingkup project • Jumlah tahapan PL
• Periksa resiko • Jadwal keseluruhan
• Tanggal penyajian untuk
• Evaluasi fungsi/fitur setiap tahapan
• Pahami fungsi/fitur • Buat rencana awal yang baik
infrastruktur untuk tahapan pertama
• Periksa kemajuan
Praktek Pemodelan
• Kita membuat model untuk mendapatkanpemahaman
yang lebih baik terhadap entitias aktual yang akan
dibangun
• Model Analisis menampilkan kebutuhan konsumen
dengan melukiskan PL dalam tiga domain yang berbeda :
domain informasi, domain fungsi, dan domain perilaku.
• Model Desain menampilkan karakteristik PL yang
membatu praktisi untuk mengkonstruksinya secara efektif
: arsitektur, antarmuka, detail level komponen
Praktek Pemodelan Analisis
 Prinsip-prinsip pemodelan analisis
• Menampilkan domain informasi
• Menampilkan fungsi PL
• Menampikan perilaku PL
• Partisi dari tiga representasi ini
• Bergerak dari esensi menuju implementasi
• Elemen-elemen model analisis
• Data model
• Flow model
• Class model
• Behavior model
Praktek Pemodelan Desain
 Prinsip-prinsip :
• Desain harus dapat dilacak dari model analisis
• Senantiasa memahami arsitektur
• Fokus pada desain data
• Antarmuka (pengguna maupun internal) harus didesain
• Komponen harus menunjukkan independensi
• Fungsional
• Komponen-komponen harus “loosely coupled”
• Representasi desain harus mudah dipahami
• Model desain harus dikembangkan secara iteratif
• Elemen-elemen model desain
• Data design
• Architectural design
• Component design
• Interface design
Praktek Konstruksi
 Prinsip Persiapan : Sebelum pengkodean, pastikan bahwa :

• Memahami permasalahan yang akan di selesaikan
• Memahami prinsip dan konsep desain dasar
• Mengambil bahasa pemrograman yang memenuhi kebutuhan PL
untuk dibangun dan lingkungan dimana dia beroperasi.
• Pilih lingkungan pemrograman yang menyediakan tool ntuk
memudahkan perkerjaan anda.
• Buat sejumlah tes unit yang akan dilakukan ketika kode
komponen sudah lengkap
Praktek Konstruksi
(countinuee)..
• Prinsip-prinsip coding: ketika mulai menulis program, pastikan anda
• Batasi algoritma anda dengan mengikuti ketentuan pemrograman
terstruktur.
• Pilih struktur data yang memenuhi kebutuhan desain.
• Pahami arsitektur PL dan buat antarmuka yang konsisten dengannya
• Jaga logika kondisional sesederhana mungkin.
• Buat perulangan bersarang dg cara yang membuatnya mudah untuk diuji.
• Pilih nama-nama variabel yang bermakna, dan ikuti standar lokal yang lain.
• Tulislah kode yang self-documenting.
• Buatlah layout visual (indent, baris kosong) yang mempengaruhi
pemahaman.
Praktek Konstruksi
(countinuee)..
Prinsip-prinsip validasi : Setelah melengkapi kode
pertama, pastikan anda :
• Melakukan pelacakan kode ketika dimungkinkan.
• Melakukan tes unit dan memperbaiki kesalahan
yang anda temukan
• Refactor kode program.
Praktek Konstruksi
(countinuee)..
• Prinsip-prinsip Pengujian
• Semua tes harus bisa dilacak dari requirement
• Pengujian harus bisa direncanakan
• Pengujian mulai dari “kecil” dan bergerak ke
“besar” Pengujian yang melelahkan tidak
mungkin
Praktek Deployment
• Prinsip-prinsip :
• Kelola harapan pengguna pada setiap tahap
• Paket penyajian lengkap harus disusun terpadu dan teruji
• Tim pendukung harus disediakan harus disediakan
• Materi pelatihan harus disediakan pada pengguna akhir
• PL yang buggy, diperbaiki dulu, baru disajikan
PERTEMUAN 10-11
PENERAPAN MODEL PROSES PERANGKAT
LUNAK
Materi
• Object Oriented Analysis (OOA)

• Object Modelling Technique (OMT)
• RUP
• USDP
• AGILE
• UWE
Object Oriented Analysis
(OOA)
Object Oriented Analysis
(OOA)
• Object-oriented analysis (OOA) telah ada sejak 1988. Metode ini
sudah digunakan Shlaer-Mellor, Jacobson, Coad-Yourdon, and
Rumbaugh.
• Hasil sukses dalam penerapan metode ini dibuktikan di AT & T
Bell Labs. AT & T Bell Labs menerapkan metode ini dalam
project besar yang disebut Call Attempt Data Collection System
(CADCS).
• Dari proyek tersebut didapat bahwa penggunaan metode ini
mengurangi 8% dari total waktu untuk spesifikasi kebutuhan
project dan pengurangan 30% staff effort.
Pengertian Analisa Object-Oriented
• Object-Oriented Analysis (OOA) adalah teknik pemodelan yang

mengintegrasikan antara data dan proses kedalam suatu kesatuan yang
disebut dengan objek. Model OOA berupa gambar yang mengilustrasikan
objek system dari berbagai macam persepsi.
• Object-Oriented Analysis (OOA) merupakan suatu metode dalam
pengembangan perangkat lunak berbasis object. Yang dimaksud dengan
object bisa dipandang sebagai suatu item informasi atau representasi entitas
di dunia nyata. Seperti contohnya dalam system reservasi penerbangan hal-
hal yang bisa disebut sebagai object seperti pesawat, jalur penerbangan dll.
Hubungan OOA dengan
object oriented yang lain
Diantaranya yaitu :
a) Object-Oriented Database,
b) Object- Oriented Design,
c) Object-Oriented Programming Languages.
Dalam penerapannya semua metode itu digunakan secara keseluruhan
dalam project disebut dengan metode object-oriented. Jika hanya
melakukan analisis saja dengan metode object-oriented dan tidak diikuti
dengan design dan programming dengan metode yang sama tentunya
akan menambah kesulitan dalam pengambangannya. Dalam kenyataannya
ketiga metode diatas tidak bisa dilepaskan satu sama lain. Karena memang
untuk mendapatkan hasil yang maksimal dari metode object-oriented,
ketiganya harus ada.
Karakteristik dari object-oriented
1. Abstraction and Classification

2. Encapsulation and Information Hiding
3. Polymorphism and Inheritance
Konsep objek
Obyek dalam ‘software analysis & design’ adalah konsep (concept),
benda (thing), dan sesuatu yang membedakannya dengan lingkungannya.
Secara sederhana obyek adalah mobil, manusia, alarm dan lainnya. Tapi
obyek dapat pula merupakan sesuatu yang abstrak yang hidup didalam
sistem seperti tabel, database, event, system messages. Obyek dikenali
dari keadaannya dan juga operasinya.
Konsep objek
Sebagai contoh sebuah mobil dikenali dari warnanya, bentuknya,
sedangkan manusia dari suaranya. Ciri-ciri ini yang akan membedakan
obyek tersebut dari obyek laiObyek dalam ‘software analysis & design’
adalah sesuatu berupa konsep (concept), benda (thing), dan sesuatu yang
membedakannya dengan lingkungannya. Secara sederhana obyek adalah
mobil, manusia, alarm dan lainnya. Tapi obyek dapat pula merupakan
sesuatu yang abstrak yang hidup didalam sistem seperti tabel, database,
event, system messages. Obyek dikenali dari keadaannya dan juga
operasinya. Sebagai contoh sebuah mobil dikenali dari warnanya,
bentuknya, sedangkan manusia dari suaranya.
Konsep objek
Alasan mengapa saat ini pendekatan dalam pengembangan software
dengan object-oriented, pertama adalah scalability dimana obyek lebih
mudah dipakai untuk menggambarkan sistem yang besar dan komplek.
Kedua dynamic modeling, adalah dapat dipakai untuk permodelan sistem
dinamis dan real time.nnya. Alasan mengapa saat ini pendekatan dala1m
pengembangan software dengan object-oriented, pertama adalah
scalability dimana obyek lebih mudah dipakai untuk menggambarkan
sistem yang besar dan komplek. Kedua dynamic modeling, adalah dapat
dipakai untuk permodelan sistem dinamis dan real time.
Kelebihan OOA
Maintainability
Mengurangi kompleksitas dalam
perarancangan design system
Reusability ,
Kelebihan OOA
Maintainability
Mengurangi kompleksitas dalam
perarancangan design system
Reusability ,
Tujuan OOA
Untuk menentukan semua kelas(dan hubungan serta tingkah laku yang berkaitan
dengannya) yang relevan dengan masalah yang akan dipecahkan. Untuk itu perlu
melakukan sejumlah tugas yaitu:
1. Persyaratan pemakaian dasar harus di komunikasikan diantara pelanggan dan
perekayasa perangkat lunak.
2. Kelas – kelas harus diidentifikasi(misalnya: atribut dan metode yang ditentukan)
3. Hirarki kelas harus di pesifikasikan.
4. Hubungan objek – ke - objek(koneksi objek) harus direpresentasikan.
5. Tingkah laku objek dimodelkan.
6. Tugas 1 sampai 5 diaplikasikan lagi secara sampai model selesai.
Pengujian OOA
• Pengujian model symbol OOA
• Konsistensi hubungan antar entitas dalam
model OOA
Proses Analisis Domain:
Input dan output
untuk analisis domain
:
Menurut Firesmith mengambarkan analisis
domain perangkat lunak dengan cara
mengnalisis domain perangkat lunak adalah
identifikasi, analisis, dan spesifikasi dari
persyaratan umum suatu domain aplikasi
spesifik.
Input dan output
untuk analisis domain
:
 Aktivitas – aktivitas dalam proses analisis domain:
1. Tentukan domain yang diselidiki
2. Kategorikan item yang di ekstrak dari domain
3. Kumpulkan sampel representatif dari aplikasi di dalam
domain
4. Analisis masing –masing aplikasi pada sampel
5. Kembangkan model analis untuk objek tersebut.
OOA vs Convensional
:
• Fichman dan Kamerer mengusulkan 11 dimensi permodelan
yang dapat digunakan untuk membandingkan berbagai
metode OOA dan Konvensional :
• Identifikasi/klasifikasi entitas
• Umum ke spesifik dan keseluruhan ke hubungan entitas bagian
• Hubungan entitas lain
• Gambaran atribut entitas
• Partisi model skala besar
• Keadaan dan transisi antar keadaan
OOA vs Convensional
(continue)
:
• Spesifikasi detail untuk fungsi
• Dekomposisi Top-Down
• Urutan pemrosesan end-to-end
• Identifikasi pelayanan eksklusif
• Komunikasi entitas (melalui pesan atau event)
Object Modelling Technique
(OMT)
Object Modelling Technique
(OMT)
Pada Object Oriented Technology ada beberapa metode yang
digunakan dalam pengembangan sistem, Salah satu yang terkenal
adalah OMT (Object Modelling Technique) yang diciptakan oleh
Rambough
Aktivitas-aktivitas yang dilakukan dalam OMT adalah:
• Model Objek
• Model Dinamis
• Model Fungsional
Dalam pengembangan sistem berbasis objek diperlukan tahapan
proses analisis yang akan dilanjutkan dengan tahapan desain /
perancangan sistem.
Langkah-langkah Proses
OOA dalam metode OMT
1. Menentukan domain masalah 3. Pengembangan Model Dinamis
2. Membangun model objek a. Penyiapan scenario
b. Penentuan event dan kembangkan penelusuran
a. Identifikasi kelas yang relevan untuk
event untuk masing-masing scenario
masalah tersebut
c. Pembuatan diagram aliran event
b. Penentuan atribut dan asosiasi
d. Kajian tingkah laku untuk konsistensi dan
c. Penentuan link objek kelengkapannya.
d. Pengorganisasian kelas objek dengan 4. Pembuatan Model Fungsioanal untuk sistem tersebut
menggunakan pewarisan a. Identifikasi input dan output
b. Penggunaan aliran data untuk merepresentasikan
transformasi aliran
c. Pengembangan masing-masing fungsi
Langkah-langkah Proses
OOD dalam metode OMT
1. Desain Sistem 2. Desain Objek
a. Pemilihan operasi model analisis
a. Partissi model analisis ke dalam
b. Penentuan algoritma untuk masing-masing operasi
subsistem
c. Pemilihan struktur data untuk setiap algoritma
b. Identifikasi konkurensi yang
d. Penentuan kelas internal
ditentukan oleh masalah
e. Pengkajian organisasi kelas untuk mengoptimalkan
c. Alokasikan subsistem ke prosesor akses ke data
dan tugas. f. Perancangan atribut kelas
d. Penentuan strategi untuk 3. Implementasi mekasnisme kontrol
manajemen data 4. Penyesuaian struktur kelas untuk memperkuat
e. Identifikasikan sumber daya global pewarisan
dan mekanisme kontrol untuk 5. Perancangan pemesanan untuk
dapat diakses mengimplementasikan hubungan objek asosiasi
f. Pengkajian trade-offs 6. Pengemasan kelas-kelas dan asosiasi ke dalam modul
Perkembangan OOD dalam
metode OMT
1. Konsep awal programming (Basic) dengan kekuatan GOTO statement

2. Bahasa pemrograman terstruktur (procedural Language), menghilangkan
kelemahan GOTO yang menjadikan konsep programming menjadi tidak
terstruktur
Contoh: Pascal, Basic, FORTRAN, COBOL, C++, dll
3. Object Oriented Programming, yang mengarah ke konsep object
Diperkenalkan pertama kali oleh bahasa SIMULA 67 dan masih
berbasiskan Text, dimana program harus dibuat dengan mengetik
serangkaian perintah
Perkembangan OOD dalam
metode OMT
1. Konsep awal programming (Basic) dengan kekuatan GOTO statement

2. Bahasa pemrograman terstruktur (procedural Language), menghilangkan
kelemahan GOTO yang menjadikan konsep programming menjadi tidak
terstruktur
Contoh: Pascal, Basic, FORTRAN, COBOL, C++, dll
3. Object Oriented Programming, yang mengarah ke konsep object
Diperkenalkan pertama kali oleh bahasa SIMULA 67 dan masih
berbasiskan Text, dimana program harus dibuat dengan mengetik
serangkaian perintah
RUP
(Rational Unified Process)
RUP (Rational Unified Process)
Rational Unified Process (RUP) merupakan

suatu metode rekayasa perangkat lunak yang
dikembangkan dengan mengumpulkan
berbagai best practises yang terdapat dalam
industri pengembangan perangkat lunak. Ciri
utama metode ini adalah menggunakan use-
case driven dan pendekatan iteratif untuk siklus
pengembangan perankat lunak
RUP (Rational Unified Process)
RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada
pengembangan model dengan menggunakan Unified Model Language (UML).
Melalui gambar dibawah dapat dilihat bahwa RUP memiliki, yaitu:
• Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili aspek-
aspek dinamis dari pengembangan perangkat lunak. Aspek ini dijabarkan dalam
tahapan pengembangan atau fase. Setiap fase akan memiliki suatu major
milestone yang menandakan akhir dari awal dari phase selanjutnya. Setiap
phase dapat berdiri dari satu beberapa iterasi. Dimensi ini terdiri atas Inception,
Elaboration, Construction, dan Transition.
• Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-aspek
statis dari proses pengembangan perangkat lunak yang dikelompokkan ke dalam
beberapa disiplin. Proses pengembangan perangkat lunak yang dijelaskan
kedalam beberapa disiplin terdiri dari empat elemen penting, yakni who is
doing, what, how dan when. Dimensi ini terdiri atas
•
Gambar
Arsitektur Rational Unified Process
Fase USP
1. Inception/insepsi 3. Construction/konstruksi
– Menentukan Ruang lingkup proyek – Melakukan sederetan iterasi
– Membuat ‘Business Case’ – Pada setiap iterasi akan melibatkan proses
berikut: analisa desain, implementasi dan
– Menjawab pertanyaan “apakah yang
testing
dikerjakan dapat menciptakan ‘good
business sense’ sehingga proyek dapat 4. Transition/transisi
dilanjutkan – Membuat apa yang sudah dimodelkan menjadi
2. Elaboration/elaborasi suatu produk jadi
– Menganalisa berbagai persyaratan dan – Dalam fase ini dilakukan:
resiko • Beta dan performance testing
• Membuat dokumentasi tambahan seperti;
– Menetapkan ‘base line’
training, user guides dan sales kit
– Merencanakan fase berikutnya yaitu • Membuat rencana peluncuran produk ke
construction komunitas pengguna
UNIFIED SOFTWARE DEVELOPMENT PROCESS
(USDP)
USDP
 Metodologi untuk pengembangan perangkat lunak

yang berorientasikan objek.
 Metodologi ini pertama kali diperkenalkan oleh
Rational Team, yang pada perkembangan selanjutnya
metodologi ini disempurnakan kembali menjadi
metodologi baru yang bernama Rational Unified
Process (RUP), yang sekaligus menjadi cikal bakal
tebentuknya kurang lebih tujuh metodologi lainnya
USDP
 Proses yang dicakup tidaklah sesederhana jika

dibandingkan dengan metodologi klasik, seperti
waterfall dan iterative model. Hal ini dikarenakan
USDP lebih digunakan untuk membangun sebuah
kerangka kerja (framework) yang bisa dikustomisasi
untuk kepentingan organisasi dan proyek yang lebih
spesifik. Dengan framework, bisa tercipta beragam
aplikasi karena adanya konsep coding reuse, dimana
coding yang sama bisa dipakai untuk keperluan
aplikasi yang sejenis.
FASE pada USDP
1. Inception,
2. Elaboration,
3. Construction,
4. Transition.
Di tiap-tiap fase tersebut terdapat 6 tahap kerja (iterasi) yang harus dilakukan,
yaitu Business Modeling, Requirements, Analysis & Design, Implementation, Test,
dan Deployment.
Referensi lain yang membagi fase tersebut menjadi 5 tahap saja (Business
Modeling dan Requirements dijadikan satu) dan ada pula yang membaginya
menjadi 7 tahap (fase akhir ditambah dengan Maintenance). Fase kerja ini
berkaitan erat dengan peran seorang project manager, sedangkan tahap kerja
(iterasi) berkaitan erat dengan peran seorang developer atau programmer.
Use Case Driven
• Dalam USDP yang menjadi elemen dasarnya adalah interaksi tunggal
antara pengguna dengan sistem. Use case berguna sebagai langkah
awal untuk memodelkan interaksi tersebut. Setiap use case
merepresentasikan kebutuhan dan hubungan dari tiap-tiap entity yang
kemudian akan diimplementasikan dalam sistem.
• Use case digunakan untuk menangkap kebutuhan fungsi dan
mendifinisikan isi dari tiap-tiap iterasi.
• Dengan demikian tiap iterasi dalam USDP mempunyai use case atau
skenario yang spesifik. Hal ini akan memandu system developers untuk
selalu melihat dari sudut pandang kebutuhan pengguna sehingga
sistem yang dihasilkan betul-betul sesuai dengan keinginan pengguna.
Contoh Use Case Diagram
Yang Dikembangkan
Contoh
Unified Modeling Language (UML)
Hubungan Antar Fase USDP Berdasarkan
Sumber Daya Yang Dibutuhkan
Gambar : Persentase Sumber Daya Yang Diperlukan Untuk Proyek

Standar (Kiri) dan Proyek Sulit/Besar (Kanan)
Hubungan USDP Dilihat Dari
Berbagai Aspek
Gambar: Hubungan Antar Aspek USDP Pada Proyek Dengan Resiko

Rendah (Kiri) Dan Resiko Tinggi (Kanan).
Pembagian Kerja
Dalam USDP
1. Primary Tasks adalah semua penugasan yang berkontribusi

langsung untuk pengembangan proyek di fase-fase yang
lebih tinggi.
2. Secondary Tasks, yaitu :
– Pencegahan atau penanggulangan terhadap resiko-resiko yang ada.
– Penanggulangan masalah-masalah kritis yang terjadi di dalam tim.
– Penelitian yang berkaitan dengan masalah-masalah yang ada
beserta solusinya.
– Pencarian bug (bug tracking) dan pembuatan laporan.
AGILE
(TANGKAS)
AGILE
Agile Development Methods adalah sekelompok metodologi

pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang
sama atau pengembangan sistem jangka pendek yang memerlukan
adaptasi cepat dari pengembang terhadap perubahan dalam bentuk
apapun.
Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan
waspada. Sehingga saat membuat perangkat lunak dengan menggunakan
agile development methods diperlukan inovasi dan responsibiliti yang baik
antara tim pengembang dan klien, agar kualitas dari perangkat lunak yang
dihasilkan bagus dan kelincahan dari tim seimbang.
Diagram Dari Agile
Development Methods
AGILE MANIFESTO
Agile development methods terdefinisi dalam empat nilai, biasa di

sebut Agile Alliance’s Manifesto, diantaranya :
1. Interaksi dan personel lebih penting daripada proses dan alat.
2. Perangkat lunak yang berfungsi lebih penting daripada
dokumentasi yang lengkap.
3. Kolaborasi dengan klien lebih penting daripada negosiasi
kontrak.
4. Respon terhadap perubahan lebih penting daripada mengikuti
rencana
MODEL PROSES AGILE
1. Acceptance Test Driven Development (ATDD)

2. Agile Modeling
3. Adaptive Software Development (ASD)
Sistem kerja adaptive software development :
– Collaboration : orang-orang yang bermotivasi tinggi bekerja sama, saling
melengkapi, rela membantu, kerja keras, terampil di bidangnya, dan
komunikasikan masalah untuk menyelesikan masalah secara efektif.
– Learning: tim developer sering merasa sudah tahu semua hal tentang proyek,
padahal tidak selamanya begitu. Karena itu proses ini membuat mereka belajar
lebih tentang proyek melalui tiga cara:
• Fokus grup, klien dan pengguna memberi masukan terhadap perangkat
lunak.
• Formal Technique Reviews, tim ASD lengkap melakukan review.
Postmortems, tim ASD melakukan instrospeksi pada kinerja dan proses.
MODEL PROSES AGILE
hal yang perlu diperhatikan jika menggunakan dynamic system

4. Agile Unified Process (AUP) development method:
5. Continuous integration (CI) – Feasibility study, siapkan requirement, dan batasan, lalu
uji apakah sesuai gunakan proses DSDM.
6. Crystal Clear 7. Crystal Methods – Business Study, susun kebutuhan fungsional dan
informasi, tentukan arsitektur aplikasi dan identifikasi
8. Dynamic Systems Development kebutuhan pemeliharaan untuk aplikasi.
– Functional model iteration, perlihatkan fungsi perangkat
Method (DSDM) lunak ke klien untuk mendapatkan feedback
– Design and Build Iteration, cek ulang prototip yang
dibangun dan pastikan bahwa prototip dibangun dengan
cara yang memungkinkan fungsi tersebut benar-benar
bekerja.
• Implementation: buat perangkat lunak sesuai prototype
yang ada dan terus tambah fungsionalitasnya.
MODEL PROSES AGILE
9. Extreme Programming (XP) 11. Graphical System Design (GSD)

10. Feature Driven Development (FDD) 12. Kanban
Keuntungan dari metode feature driven 13. Lean software development
development : 14. Rational unified process (RUP)
– User dapat menggambarkan dengan mudah
bentuk sistem yang akan dibuat.
– Dapat diorganisasikan atau diatur ke dalam
kelompok bisnis sesuai hirarki yang ada.
– Desain dan kode lebih mudah diperiksa
secara efektif.
– Perancangan proyek, biaya pembuatan dan
jadwal rilis ditentukan oleh fiturnya.
TUJUAN AGILE
1. High-value & working App system, diharapkan dengan memakai agile development methods
dapat dihasilkan perangkat lunak yang mempunyai nilai jual yang tinggi, biaya pembuatan bisa di
tekan dan perangkat lunak bisa berjalan dengan baik.
2. Iterative, incremental, evolutionary, agile adalah metode pengembangan perangkat lunak yang
iteratif, selalu mengalami perubahan, dan evolusioner. Tim harus bekerja dalam waktu yang
singkat(biasanya 1-3 minggu) dan juga selalu menambah fungsionalitas dari perangkat lunak
sesuai dengan kebutuhan klien. Agile dapat dianalogikan ketika seseorang ingin pergi ke suatu
kota dan dia tidak tahu jalannya. Lalu bagaimana dia bisa sampai tujuan? Dengan sering
bertanya kepada orang yang dia temui dijalan hingga dia sampai di tempat tujuan.
3. Cost control & value-driven development, salah satu tujuan dari agile yaitu pengembangan
perangkat lunak disesuaikan dengan kebutuhan pengguna, tim bisa dengan cepat merespon
kebutuhan yang diinginkan pengguna sehingga waktu dan biaya pembuatan perangkat lunak
bisa dikontrol.
TUJUAN AGILE
4. High-quality production, walaupun biaya pembuatan perangkat lunak bisa ditekan dan proses pembuatan bisa
dipercepat , tetapi kualitas dari perangkat lunak yang dibuat harus tetap dijaga. Dengan melakukan tes setiap
fungsionalitas perangkat lunak setelah selesei dibuat berarti agile juga mengakomodir kebutuhan ini.
5. Flexible & risk management, jika kita menggunakan metode pembuatan yang biasanya dipakai, jika ingin
mengubah fungsionalitas dari wireframe yang telah dibuat di butuhkan proses yang rumit. Mulai dari
pertemuan dengan sistem analis untuk mengubah sistem perangkat lunak, perubahan rencana rilis produk
hingga perubahan biaya produksi. Pertemuan dengan klien untuk melakukan tes perangkat lunak juga sering
dilakukan sehingga fungsionalitas perangkat lunak mudah diubah dan akhirnya kegagalan perangkat lunakpun
bisa diminimalisir.
6. Collaboration, dengan menggunakan agile, tim pengembang diharuskan sering bertemu untuk membahas
perkembangan proyek dan feedback dari klien yang nantinya akan ditambahkan dalam perangkat lunak,
sehingga tim bisa berkolaborasi dengan maksimal.
7. Self-organizing, self-managing teams, rekrut orang terbaik, beri dan dukung kebutuhan mereka lalu biarkan
mereka bekerja. Itulah perbedaan agile dan SDM lainnya. Dengan agile, developer dapat memanajemen
dirinya sendiri, sedangkan manajer tim hanya bertugas mengkolaborasikan developer perangkat lunak dengan
klien. Sehingga terciptalah tim yang solid.
CARA KERJA AGILE
DEVELOPMENT METHODS
2. Story
1. Komposisi tim
Story adalah bagian terpenting dari Scrum,
 Owner / Klien Seperti :
 Manajer / Scrum Master • ID : Identifikasi unik
 Sistem Analis • Nama : Nama story bersifat deskriptif
 Developer • Kepentingan : Derajat kepentingan
yang diberikan oleh klien terhadap
story
• Perkiraan awal : Perkiraan awal tim
tentang berapa banyak kerja yang
diperlukan untuk mengimplemen-
tasikan sebuah story
Sprint
Tim akan melakukan sprint secara simultan

Sprint (Rapat perencanaan pembuatan sampai perangkat lunak selesei dikerjakan,
perangkat lunak dilakukan 2-8 minggu sebagai contoh:
sekali), yang perlu diperhatikan saat
 Sprint 1, tim membuat fungsi login,logout
melaksanakan sprint antara lain :
dan demo perangkat lunak akan dilakukan 3
• Tujuan sprint. minggu kemudian.
• Daftar anggota tim harus lengkap.  Setelah dilakukan demo untuk mengevaluasi
• Sprint backlog (daftar story yang kerja yang dilakukan tim pada Sprint 1, maka
akan diikutkan dalam sprint). Sprint 1 dianggap selesei.
• Tanggal demo yang pasti.  Bahan evaluasi dari Sprint 1 akan dibawa ke
• Tempat dan waktu yang jelas untuk Sprint 2 begitu seterusnya sampai aplikasi
pelaksanaan sprint berikutnya. selesei dikerjakan.
Kelebihan dan Kekurangan Agile
Kelebihan : Kekurangan :
• 82% Menambah produktivitas • Agile tidak akan berjalan dengan baik jika
tim. komitmen tim kurang.
• 77% Menambah kualitas • Tidak cocok dalam skala tim yang besar
perangkat lunak. (>20 orang).
• 78% Menambah kepuasan klien. • Perkiraan waktu release dan harga
• 37% Menghemat biaya. perangkat lunak sulit ditentukan.
UWE
UML-BASED WEB ENGINEERING
DIAGRAM
UWE
• Menurut Rossi, dan Pastor (2008,p 159), dalam bukunya

berjudul ”Web Engineering modeling and implementing web
applications”, dimana pendekatan UWE menyediakan domain
notasi tertentu, proses pengembangan model-driven, dan
dukungan alat untuk rekayasa aplikasi Web.
• Karakteristik UWE adalah fakta y ang akan pendekatan yang
didasarkan pada standar yang tidak terbatas pada penggunaan
"linguafranca" UML tetapi juga menggunakan XMI sebagai
format pertukaran model, Depkeu untuk meta-modeling,
model-driven prinsip MDA pendekatan, transformasi model
bahasa QVT, dan ML.
Analisis dan Desain Model
dalam model UWE
• Analisa terhadap aplikasi Web kebutuhan fungsional

telah ditetapkan oleh use case work flow model data
(isi) persyaratan yang ditentukan oleh model domain
Desain model model aspek informasi struktur aplikasi
web hypertext konten dan fungsi navigasi model
skema navigasi layout presentasi model fungsi model
proses adaptivity model Sevillan sistem pada saat
diselidiki dari luar ketika sistem melakukan fungsinya
Unified Modelling Language
(UML)
Pemodelan (modeling) adalah proses merancang piranti

lunak sebelum melakukan pengkodean (coding). Model
piranti lunak dapat dianalogikan seperti pembuatan
blueprint pada pembangunan gedung. Membuat model
dari sebuah sistem yang kompleks sangatlah penting
karena kita tidak dapat memahami sistem semacam itu
secara menyeluruh. Semakin komplek sebuah sistem,
semakin penting pula penggunaan teknik pemodelan
yang baik.
Pemodelan piranti lunak
ditentukan oleh tiga unsur)
Artifact UML
Artifact didalam UML didefinisikan
sebagai informasi dalam bentuk yang
digunakan atau dihasilkan dalam proses
pengembangan perangkat. Contohnya
adalah source code yang dihasilkan oleh
proses pemrograman.
Diagram grafis
pada UML
• use case diagram • implementation diagram
• class diagram • component diagram
• behavior diagram • deployment diagram
• statechart diagram
• activity diagram Diagram-diagram tersebut diberi
• interaction diagram nama berdasarkan sudut
• sequence diagram pandang yang berbeda-beda
terhadap sistem dalam proses
• collaboration diagram analisis atau rekayasa.
Tujuan UML
• Memberikan model yang siap pakai, bahasa pemodelan
visual yang ekspresif untuk mengembangkan dan saling
menukar model dengan mudah dan dimengerti secara
umum.
• Memberikan bahasa pemodelan yang bebas dari berbagai
bahasa pemrograman dan proses rekayasa.
• Menyatukan praktek-praktek terbaik yang terdapat dalam
bahasa pemodelan.
Cakupan UML
1. UML menggabungkan konsep Booch, OMT dan OOSE, sehingga UML
merupakan suatu bahasa pemodelan tunggal yang umum dan
digunakan secara luas oleh para user ketiga metode tersebut dan
bahkan para user metode lainnya.
2. UML menekankan pada apa yang dapat dikerjakan dengan metode-
meode tersebut.
3. UML berfokus pada suatu bahasa pemodelan standar, bahkan pada
proses standar. Meskipun UML harus diaplikasikan dalam konteks
sebuah proses, dari pengalaman, bahwa organisasi dan masalah yang
berbeda juga memerlukan proses yang berbeda pula.
Notasi Dalam UML
 Actor
Actor menggambarkan segala pengguna software aplikasi
(user). Actor memberikan suatu gambaran jelas tentang
apa yang harus dikerjakan software aplikasi. Sebagai
contoh sebuah actor dapat memberikan input kedalam
dan menerima informasi dari software aplikasi, perlu
dicatat bahwa sebuah actor berinteraksi dengan use
case, tetapi tidak memiliki kontrol atas use case. Sebuah
actor mungkin seorang manusia, satu device, hardware
atau sistem informasi lainnya.
Notasi Dalam UML
Use Case
Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai
suatu tujuan tertentu. Walaupun menjelaskan kegiatan, namun use case hanya
menjelaskan apa yang dilakukan oleh actor dan sistem bukan bagaimana actor dan sistem
melakukan kegiatan tersebut.
• Use-case Konkret adalah use case yang dibuat langsung karena keperluan actor. Actor
dapat melihat dan berinisiatif terhadapnya
• Use-case Abstrak adalah use case yang tidak pernah berdiri sendiri. Use case abstrak
senantiasa termasuk didalam (include), diperluas dari (extend) atau memperumum
(generalize) use case lainnya. Untuk menggambarkannya dalam use case model
biasanya digunakan association relationship yang memiliki stereotype include, extend
atau generalization relationship. Hubungan include menggambarkan bahwa suatu use
case seluruhnya meliputi fungsionalitas dari use case lainnya. Hubungan extend antar
use case berarti bahwa satu use case merupakan tambahan fungsionalitas dari use
case yang lain jika kondisi atau syarat tertentu terpenuhi.
Notasi Dalam UML
Use Case
Use case menjelaskan urutan kegiatan yang dilakukan actor dan sistem untuk mencapai
suatu tujuan tertentu. Walaupun menjelaskan kegiatan, namun use case hanya
menjelaskan apa yang dilakukan oleh actor dan sistem bukan bagaimana actor dan sistem
melakukan kegiatan tersebut.
• Use-case Konkret adalah use case yang dibuat langsung karena keperluan actor. Actor
dapat melihat dan berinisiatif terhadapnya
• Use-case Abstrak adalah use case yang tidak pernah berdiri sendiri. Use case abstrak
senantiasa termasuk didalam (include), diperluas dari (extend) atau memperumum
(generalize) use case lainnya. Untuk menggambarkannya dalam use case model
biasanya digunakan association relationship yang memiliki stereotype include, extend
atau generalization relationship. Hubungan include menggambarkan bahwa suatu use
case seluruhnya meliputi fungsionalitas dari use case lainnya. Hubungan extend antar
use case berarti bahwa satu use case merupakan tambahan fungsionalitas dari use
case yang lain jika kondisi atau syarat tertentu terpenuhi.
Notasi Dalam UML
Class
Class merupakan pembentuk utama dari sistem berorientasi obyek, karena class menunjukkan
kumpulan obyek yang memiliki atribut dan operasi yang sama. Class digunakan untuk
mengimplementasikan interface.
Class digunakan untuk mengabstraksikan elemen-elemen dari sistem yang sedang dibangun.
Class bisa merepresentasikan baik perangkat lunak maupun perangkat keras, baik konsep
maupun benda nyata.
Notasi class berbentuk persegi panjang berisi 3 bagian: persegi panjang paling atas untuk
nama class, persegi panjang paling bawah untuk operasi, dan persegi panjang ditengah untuk
atribut.
Atribut digunakan untuk menyimpan informasi. Nama atribut menggunakan kata benda yang
bisa dengan jelas merepresentasikan informasi yang tersimpan didalamnya. Operasi
menunjukkan sesuatu yang bisa dilakukan oleh obyek dan menggunakan kata kerja.
Notasi Dalam UML
Interface
Interface merupakan kumpulan operasi tanpa implementasi dari suatu
class. Implementasi operasi dalam interface dijabarkan oleh operasi
didalam class. Oleh kaIrena itu keberadaan interface selalu disertai
oleh class yang mengimplementasikan operasinya. Interface ini
merupakan salIah satu cara mewujudkan prinsip enkapsulasi dalam
obyek.
Notasi Dalam UML
Interaction
Interaction digunakan untuk menunjukkan baik
aliran pesan atau informasi antar obyek maupun
hubungan antar obyek. Biasanya interaction ini
dilengkapi juga dengan teks bernama operation
signature yang tersusun dari nama operasi,
parameter yang dikirim dan tipe parameter yang
dikembalikan.
Notasi Dalam UML
Note
Note digunakan untuk memberikan keterangan atau
komentar tambahan dari suatu elemen sehingga
bisa langsung terlampir dalam model. Note ini bisa
disertakan ke semua elemen notasi yang lain.
Notasi Dalam UML
Dependency
Dependency merupakan relasi yang menunjukan bahwa
perubahan pada salah satu elemen memberi pengaruh pada
elemen lain. Elemen yang ada di
Bagian tanda panah adalah elemen yang tergantung pada
elemen yang ada dibagian tanpa tanda panah.
Terdapat 2 stereotype dari dependency, yaitu include dan
extend. Include menunjukkan bahwa suatu bagian dari elemen
(yang ada digaris tanpa panah) memicu eksekusi bagian dari
elemen lain (yang ada di garis dengan panah).
Extend menunjukkan bahwa suatu bagian dari elemen di garis
tanpa panah bisa disisipkan kedalam elemen yang ada di garis
dengan panah.
Notasi Dalam UML
Association
Association menggambarkan navigasi antar class (navigation), berapa banyak
obyek lain yang bisa berhubungan dengan satu obyek (multiplicity antar
class) dan apakah suatu class menjadi bagian dari class lainnya (aggregation).
Navigation dilambangkan dengan penambahan tanda panah di akhir garis.
Bidirectional navigation menunjukkan bahwa dengan mengetahui salah satu
class bisa didapatkan informasi dari class lainnya. Sementara UniDirectional
navigation hanya dengan mengetahui class diujung garis association tanpa
panah kita bisa mendapatkan informasi dari class di ujung dengan panah,
tetapi tidak sebaliknya.
Aggregation mengacu pada hubungan “has-a”, yaitu bahwa suatu class
memiliki class lain, misalnya Rumah memiliki class Kamar.
Notasi Dalam UML
Generalization
Generalization menunjukkan hubungan antara
elemen yang lebih umum ke elemen yang lebih
spesifik. Dengan generalization, class yang lebih
spesifik (subclass) akan menurunkan atribut dan
operasi dari class yang lebih umum (superclass)
atau “subclass is superclass”. Dengan
menggunakan notasi generalization ini, konsep
inheritance dari prinsip hirarki dapat
dimodelkan.
Notasi Dalam UML
Realization
Realization menunjukkan hubungan bahwa
elemen yang ada di bagian tanpa panah akan
merealisasikan apa yang dinyatakan oleh
elemen yang ada di bagian dengan panah.
Misalnya class merealisasikan package,
component merealisasikan class atau interface.
Notasi Dalam UML
Realization
Realization menunjukkan hubungan bahwa
elemen yang ada di bagian tanpa panah akan
merealisasikan apa yang dinyatakan oleh
elemen yang ada di bagian dengan panah.
Misalnya class merealisasikan package,
component merealisasikan class atau interface.
PERTEMUAN 12-13
PRESENTASI
Materi
• PRESENTASI TUGAS KELOMPOK

TENTANG PENERAPAN MODEL PROSES
PERTEMUAN 14
STRATEGI PENGUJIAN PERANGKAT LUNAK
Materi
• Strategi untuk Perangkat Lunak Testing

• Unit Testing
• Integration Testing
• Validation
• Systern'Iesting
PERTEMUAN 15
TEKNIK PENGUJIAN PERANGKAT LUNAK
Materi
• Test Clase Design

• White-Box Testing
• Control Shtcture Testing
• Black-Box Testing
• Testing untuk Lingkungan, Arsitektur
Aplikasi Khusus
Test Clase Design
Untuk meningkatnya visibilitas (kemampuan) perangkat lunak

sebagai suatu elemen sistem dan “biaya” yang muncul akibat
kegagalan perangkat lunak, memotivasi dilakukannya perencanaan
yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian
merupakan satu langkah dalam proses rekayasa perangkat lunak yang
dapat dianggap sebagai hal yang merusak daripada membangun.
Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas,
yaitu :
• Teknik uji coba perangkat lunak
• Strategi uji coba perangkat lunak
Teknik Uji Coba
Perangkat Lunak
• Pada dasarnya, pengujian merupakan

suatu proses rekayasa perangkat lunak
yg dapat dianggap (secara psikologis)
sebagai hal yg destruktif daripada
konstruktif.
Sasaran Pengujian
(Glen Myers) :
• Pengujian adalah proses eksekusi suatu program

dengan maksud menemukan kesalahan.
• Test case yg baik adalah test case yg memiliki
probabilitas tinggi untuk menemukan kesalahan yg
belum pernah ditemukan sebalumnya.
• Pengujian yg sukses adalah pengujian yg
mengungkap semua kesalahan yg belum pernah
ditemukan sebelumnya.
•
Prinsip pengujian
(diusulkan davis) :
• Semua pengujian harus dapat ditelusuri sampai ke persyaratan

pelanggan
• Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
• Prinsip Pareto berlaku untuk pengujian perangkat lunak. Prinsip Pareto
mengimplikasikan 80% dari semua kesalahan yg ditemukan selama
pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua
modul program.
• Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian
"yang besar".
• Pengujian yg mendalam tidak mungkin.
• Paling efektif, pengujian dilakukan oleh pihak ketiga yg independen.
•
Testabilitas:
Testabilitas perangkat lunak adalah

seberapa mudah sebuah program
komputer dapat diuji. Karena pengujian
sangat sulit, perlu diketahui apa yg dapat
dilakukan untuk membuatnya menjadi
mudah.
Testabilitas:
Karakteristik perangkat lunak yg diuji :

• OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat diuji.
• OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji.
• KONTROLABILITAS, semakin baik kita dapat mengontrol perangkat lunak
semakin banyak pengujian yg adapat diotomatisasi dan dioptimalkan.
• DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian kita dapat
lebih cepat mengisolasi masalah dan melakukan pengujian kembali.
• KESEDERHANAAN, semakin sedikit yg diuji semakin cepat pengujian.
• STABILITAS, semakin sedikit perubahan semakin sedikit gangguan pengujian.
• KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki semakin detail
pengujiannya.
ATRIBUT PENGUJIAN YANG BAIK :
• Memiliki probabilitas yg tinggi

menemukan kesalahan.
• Tidak redundan.
• Harusnya ‘jenis terbaik’.
• Tidak boleh terlalu sederhana atau
terlalu kompleks.
Test Case Design
• Pengetahuan fungsi yg spesifik dari produk yg telah dirancang
untuk diperlihatkan, test dapat dilakukan untuk menilai masing-
masing fungsi apakah telah berjalan sebagaimana yg
diharapkan.
• Pengetahuan tentang cara kerja dari produk, test dapat
dilakukan untuk memperlihatkan cara kerja dari produk secara
rinci sesuai dengan spesifikasinya.
Terdapat 2 macam pendekatan test yaitu :
1. Black-Box Testing
2. White-Box Testing
Black-Box Testing
• Test case ini bertujuan untuk menunjukkan fungsi perangkat

lunak tentang cara beroperasinya, apakah pemasukan data
keluaran telah berjalan sebagaimana yang diharapkan dan
apakah informasi yang disimpan secara eksternal selalu dijaga
kemutakhirannya.
• Tehnik pengujian black-box berfokus pada domain informasi
dari perangkat lunak, dengan melakukan test case dengan
menpartisi domain input dari suatu program dengan cara yang
memberikan cakupan pengujian yang mendalam.
Black-Box Testing
• Metode pengujian graph-based mengeksplorasi hubungan

antara dan tingkah laku objek-objek program. Partisi ekivalensi
membagi domain input ke dalam kelas data yang mungkin
untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai
batas memeriksaa kemampuan program untuk menangani data
pada batas yang dapat diterima.
• Metode pengujian yang terspesialisasi meliputi sejumlah luas
kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur
client/ server, dokumentasi dan fasilitas help dan sistem real
time masing-masing membutuhkan pedoman dan tehnik
khusus untuk pengujian perangkat lunak.
White-Box Testing
Uji coba white box adalah metode perancangan test case yang
menggunakan struktur kontrol dari perancangan prosedural untuk
mendapatkan test case. Dengan menggunakan metode white box,
analis sistem akan dapat memperoleh test case yang :
• Menjamin seluruh independent path di dalam modul yang
dikerjakan sekurang-kurangnya sekali
• Mengerjakan seluruh keputusan logikal
• Mengerjakan seluruh loop yang sesuai dengan batasannya
• Mengerjakan seluruh struktur data internal yang menjamin
validitas
Apa yang di uji dengan
white box
Struktur Data
Statement
Kondisi
Statement
Perulangan
Syarat Menjalankan
white box
Mendefinisikan semua alur logika
Membangun kasus untuk digunakan dalam pengujian
Mengevaluasi semua hasil pengujian
Melakukan pengujian secara menyeluruh

Kelebihan
white box
• Correctness program dan kebenaran dalam

mendefinisikan algoritma dapat diketahui secara
langsung dengan pengolahan path.
• White box testing dapat dilakukan dengan follow up
performance line coverage, dengan memberikan
pihak tester list of line code yang belum dieksekusi.
• Menentukan kualitas pekerjaan coding dan
pengaruhnya untuk standar coding.
Kekurangan
white box
• Jumlah biaya untuk white box testing lebih besar

daripada biaya yang dibutuhkan untuk black box,
untuk ukuran software yang sama.
• Belum mampu melakukan tes availability, reliability,
load durability dan testing – testing lain yang
berhubungan dengan requirement faktor – faktor
untuk operasi, revisi dan transisi.
Pengujian Basis Path
Uji coba basis path adalah teknik uji coba white box yg diusulkan
Tom McCabe. Metode ini memungkinkan perancang test case
mendapatkan ukuran kekompleksan logical dari perancangan
prosedural dan menggunkan ukuran ini sbg petunjuk untuk
mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat
digunakan untuk mengerjakan basis set yg menjamin pengerjaan
setiap perintah minimal satu kali selama ujicoba.
Notasi Diagram Alir
Sebelum metode basis path dapat diperkenalkan, notasi sederhana untuk

representasi aliran kontrol yangdisebut diagram alir (atau grafik program) harus
diperkenalkan. Pada gambar dibawah ini masing-masing lingkaran disebut simpul
grafik alir, yang merepresentasikan satu atau lebih statemen prosedural. Anak
panah pada grafik alir tersebut yang disebut edges atau links, merepresentansikan
aliran kontrol dan analog dengan anak panah bagan alir. Edges harus berhenti pada
suatu simpul, meskipun bila simpul tersebut tidak merepresentasikan statemen
prosedural (seperti if-then-else). Area yang dibatasi oleh edge dan simpul disebut
region.
Notasi Diagram Alir
contoh perancangan prosedural dalam bentuk flowchart

Notasi Diagram Alir
 Lingkaran/node : menggambarkan
satu/lebih perintah prosedural. Urutan
proses dan keputusan dapat dipetakan
dalam satu node.
 Tanda panah/edge : menggambarkan
aliran kontrol. Setiap node harus
mempunyai tujuan node
 Region adalah daerah yg dibatasi oleh
edge dan node. Termasuk daerah
diluar grafik alir.
Kompleksitas Siklomatis
Kompleksitas Siklomatis adalah metric perangkat lunak yang memberikan pengukuran

kuantitaif terhadap kompleksitas logis suatu program. Kompleksitas Siklomatis
menentukan jumlah jalur independen dalam basis set suatu program dan
memberikan batas atas bagi jumlah pengujian yang harus dilakukan untuk
memastikan bahwa semua statemen telah dieksekusi sedikitnya satu kali. Jalur
independen adalah jalur yang melalui program yang mengintroduksi sedikitnya satu
rangkaian statemen proses baru atau suatu kondisi baru.
Melakukan Test Case

1. Dengan menggunakan desain atau kode sebagai dasar,
gambarkan sebuah grafik alir yang sesuai.
2. Tentukan kompleksitas siklomatis dari grafik alir resultan.
3. Tentukan sebuah basis set dari jalur independen secara linier.
4. Siapkan test case yang akan memaksa adanya eksekusi setiap
basis set.
Matrik Grafis
1. Matrik grafis adalah matriks bujur sangkar yang ukurannya
sama dengan jumlah simpul pada grafik alir.
2. Masing-masing baris dan kolom sesuai dengan yang
diidentifikasikan, dan entri matriks sesuai dengan edge di
antara simpul
Control Structure Testing
Control Structure Testing merupakan bagian dari pengujian white-box. Kondisi

pengujian :
– kasus uji metode desain.
– bekerja pada kondisi logis dalam modul program
– melibatkan pengujian dari kedua ekspresi relasional dan ekspresi aritmatika.
– Jika kondisi tidak benar, maka setidaknya satu komponen dari kondisi tidak benar.
– Jenis kesalahan dalam pengujian kondisi kesalahan operator boolean, variabel boolean
kesalahan, kesalahan kurung boolean, kesalahan operator relasional, dan kesalahan
aritmatika ekspresi.
– Kondisi Sederhana: ekspresi Boolean variabel atau relasional, kemungkinan dilanjutkan
oleh operator NOT.
– Kondisi Compound: Hal ini terdiri dari dua atau lebih kondisi sederhana, operator Boolean
dan tanda kurung.
– Ekspresi Boolean: suatu kondisi tanpa ekspresi relasional.
Testing untuk Lingkungan, Arsitektur
Aplikasi Khusus
 Pengujian Grafical User Interface (GUI)

• Pengujian GUI untuk Windows
• Pengujian GUI untuk operasi Mouse
• Pengujian GUI untuk entri data
 Pengujian Arsitektur Client Server
 Pengujian Dokumentasi dan Fasilitas Help
Testing untuk Lingkungan, Arsitektur
Aplikasi Khusus
 Pengujian Sistem Real-Time

• Pengujian tugas.
• Pengujian tingkah laku.
• Pengujian sistem
Kemudian pengujian didesain untuk menilai karakteristik sistem berikut ini:
• Apakah priortias interupsi ditetapkan dan ditangani secara tepat ?
• Apakah pemrosesan untuk masing-masing interupsi ditangani dengan
tepat ?
• Apakah kinerja (misal waktu pemrosesasn) dari masing-masing
prosedur penangan interupsi sesuai dengan persyaratan ) ?
• Apakah volume interupsi yang tinggi yang terjadi pada waktu kritis
menimbulkan masalah di dalam fungsi atau kinerja ?
PERTEMUAN 16
UJIAN AKHIR SEMESTER (UAS)

Rekayasa Perangkat Lunak PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rekayasa Perangkat Lunak PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

REKAYASA PERANGKAT LUNAK

Admin Email You must specify Admin Email e.g. root@appservnetwork.com

Copyright © by AppServNetwork All Right Reserved.

SPESIFIKASI DAN VALIDASI

Gambar Elemen Proses Perangkat Lunak

Departemen Kehakiman AS mendefenisikan SDLC sebagai sebuah proses

1. Model Penilaian Proses Perangkat Lunak

2. Metode Penilaian Proses Perangkat Lunak

3. Model Pengembangan Proses Perangkat Lunak

diperoleh dengan cara melakukan normalisasi ukuran

Aspek-aspek yang digunakan untuk mengukur kualitas sebuah perangkat lunak

5) Usabilitas yaitu usaha yang dibutuhkan untuk mempelajari, mengoperasikan,

Model proses perangkat lunak merupakan deksripsi yang

1. Model Air Terjun (Waterfall)

Gambar 1.1a Model Waterfall

Tahap-tahap utama dari model ini memetakan kegiatan-kegiatan pengembangan

Status Quo Pengembangan Teknis

Gambar 1.2a Fase lingkaran pemecahan masalah (Raccoon, 1995)

Pemodelan Sistem Informasi

Analisis Desain Kode Tes

Gambar 1.3 Model sekuensial linier

Model sekuensial linier melingkupi aktivitas-aktivitas sebagai berikut:

b) Analisis Kebutuhan Perangkat Lunak

Masalah-masalah yang kadang–kadang terjadi ketika model sekuensial linier

oMasing-masing dari masalah tersebut bersifat riil.

Gambar 1.4 Prototipe Paradigma

Secara ideal prototype berfungsi sebagai sebuah mekanisme untuk

Pengembangan evolusioner berdasarkan ide untuk

Spesifikasi Versi awal

Validasi Versi akhir

Gambar 1.5 Model Evolusioner

Definisi Transformasi Integrasi dan

Gambar 1.6 Model Sistem Formal

Spesifikasi Analisis Memodifikasi

Gambar 1.7 Model

1. Buatlah contoh sebuah sistem yang menggunakan model

Sekelompok tugas yang

 Prinsip Persiapan : Sebelum pengkodean, pastikan bahwa :

• Object Oriented Analysis (OOA)

• Object-Oriented Analysis (OOA) adalah teknik pemodelan yang

1. Abstraction and Classification

1. Konsep awal programming (Basic) dengan kekuatan GOTO statement

1. Konsep awal programming (Basic) dengan kekuatan GOTO statement

Rational Unified Process (RUP) merupakan

 Metodologi untuk pengembangan perangkat lunak

 Proses yang dicakup tidaklah sesederhana jika

Gambar : Persentase Sumber Daya Yang Diperlukan Untuk Proyek

Gambar: Hubungan Antar Aspek USDP Pada Proyek Dengan Resiko

1. Primary Tasks adalah semua penugasan yang berkontribusi

Agile Development Methods adalah sekelompok metodologi

Agile development methods terdefinisi dalam empat nilai, biasa di

1. Acceptance Test Driven Development (ATDD)

hal yang perlu diperhatikan jika menggunakan dynamic system

9. Extreme Programming (XP) 11. Graphical System Design (GSD)

Tim akan melakukan sprint secara simultan

• Menurut Rossi, dan Pastor (2008,p 159), dalam bukunya

• Analisa terhadap aplikasi Web kebutuhan fungsional

Pemodelan (modeling) adalah proses merancang piranti

• PRESENTASI TUGAS KELOMPOK

• Strategi untuk Perangkat Lunak Testing

• Test Clase Design

Untuk meningkatnya visibilitas (kemampuan) perangkat lunak

• Pada dasarnya, pengujian merupakan