Metodologi Desain

Perangkat Lunak

~ ~ Meet 03 ~ ~

Program Studi Informatika

Universitas Teknologi Yogyakarta

Donny Avianto, S.T., M.T.

Pendahuluan

– Pada pertemuan sebelumnya kita telah melihat kumpulan aktivitas yang dilakukan
ketika PL akan dibuat.
– Masing-masing aktivitas ini berada dalam kerangka kerja atau model yang
mendefinisikan hubungan mereka dengan proses lain.
– Setiap aktivitas rekayasa perangkat lunak didefinisikan dengan :
1. mengidentifikasi tugas kerja yang harus diselesaikan
2. produk kerja yang akan dihasilkan
3. poin jaminan kualitas yang akan diperlukan
4. dan milestone yang akan digunakan untuk menunjukkan kemajuan.
Pendahuluan

– Kerangka proses generik untuk rekayasa perangkat lunak mendefinisikan

lima aktivitas kerangka kerja: communication, planning, modeling,
construction, and deployment.
– Selain itu, serangkaian aktivitas payung—project tracking and control, risk
management, quality assurance, configuration management, technical
reviews, and othersdi seluruh proses.
Process Flow

– satu aspek penting dari software process adalah process flow

– process flow menjelaskan bagaimana framework activities dan tindakan serta
tugas yang terjadi dalam setiap framework activities diatur sehubungan dengan
urutan dan waktu
– 4 process flow yang terkenal:
1. Linear process flow
2. Iterative process flow
3. Evolutionary process flow
4. Parallel process flow
Linear process flow

– mengeksekusi masing-masing dari lima framework activities secara

berurutan, dimulai dengan komunikasi dan berpuncak pada penerapan
Iterative process flow

– mengulangi satu atau lebih aktivitas sebelum melanjutkan ke aktivitas

berikutnya
Evolutionary process flow

– melaksanakan kegiatan dengan cara "melingkar". Setiap sirkuit melalui lima

aktivitas mengarah ke versi perangkat lunak yang lebih lengkap
Parallel process flow

– mengeksekusi satu atau lebih aktivitas secara paralel dengan aktivitas lain
(mis., pemodelan untuk satu aspek perangkat lunak dapat dieksekusi secara
paralel dengan konstruksi aspek lain dari perangkat lunak)
Prescriptive Process
Models
Prescriptive Process Models

– Prescriptive Process Models sering disebut juga “traditional” process models

– Mendefinisikan satu set elemen proses yang telah ditentukan sebelumnya dan alur
kerja proses yang dapat diprediksi.
– Bertujuan untuk membuat struktur dan urutan dalam pengembangan perangkat lunak.
– Kegiatan dan tugas terjadi secara urut dengan pedoman yang ditetapkan untuk
kemajuan.
– Tetapi apakah model preskriptif sesuai untuk dunia perangkat lunak yang berkembang
pesat karena perubahan? Jika kita menolak model proses tradisional dan
menggantinya dengan sesuatu yang kurang terstruktur, apakah kita membuatnya
mustahil untuk mencapai koordinasi dan koherensi dalam pembuatan suatu perangkat
lunak?
Prescriptive Process Models

– Tidak ada jawaban yang mudah untuk pertanyaan-pertanyaan ini, tetapi ada
alternatif yang tersedia untuk para insinyur perangkat lunak.
– Disebut "preskriptif" karena mereka meresepkan satu set elemen proses —
aktivitas kerangka kerja, tindakan rekayasa perangkat lunak, tugas, produk
kerja, jaminan kualitas, dan mekanisme kontrol perubahan untuk setiap
proyek.
– Setiap model proses juga menentukan process flow (juga disebut work flow)
—yaitu, cara elemen proses saling terkait satu sama lain.
Prescriptive Process Models

– Semua software process models dapat mengakomodasi aktivitas kerangka

proses generik
– tetapi masing-masing menerapkan penekanan yang berbeda untuk aktivitas
ini dan mendefinisikan aliran proses yang memanggil setiap aktivitas
kerangka kerja (serta tindakan dan tugas rekayasa perangkat lunak) dengan
cara yang berbeda.
The Waterfall Model
Prototyping Process Model
Spiral Model
Unified Process Model
Process Model Pros-Cons
Process Model Pros-Cons

– Beberapa kekuatan dan kelemahan model proses yang telah kita bahas
– Kenyataannya tidak ada proses yang sempurna untuk setiap proyek.
– Biasanya tim perangkat lunak mengadaptasi satu atau lebih model proses
yang dibahas atau menggunakan agile process models.
Agile Process Models
What Is Agility

– Meluasnya perubahan adalah pendorong utama untuk kelincahan.

– Insinyur perangkat lunak harus cepat berdiri jika mereka ingin
mengakomodasi perubahan cepat yang terjadi.
What Is Agility

– Tetapi agility lebih dari sekadar respons yang efektif terhadap perubahan.
– Agility juga mendorong struktur dan sikap tim yang membuat komunikasi (antara
anggota tim, antara teknolog dan pebisnis, dan antara insinyur perangkat lunak
dan manajer mereka) lebih mudah.
– Agility menekankan pengiriman perangkat lunak yang cepat dan tidak
menekankan pentingnya produk kerja perantara (tidak selalu merupakan hal
yang baik).
– Agility menganggap pelanggan sebagai bagian dari tim pengembangan dan
bekerja untuk menghilangkan sikap "kita dan mereka" yang terus meliputi
banyak proyek perangkat lunak.
What Is Agility

– Agility dapat diterapkan pada proses perangkat lunak apa pun.

– Namun, untuk mencapai ini, penting bahwa proses dirancang dengan:
– memungkinkan tim proyek untuk menyesuaikan tugas dan merampingkannya
– melakukan perencanaan dengan cara yang memahami agile development
approach
– menghilangkan semua kecuali produk kerja yang paling penting dan
menjaganya tetap ramping,
– menekankan strategi pengiriman tambahan yang memberikan perangkat
lunak yang berfungsi kepada pelanggan secepat mungkin.
Scrum Process Model
Extreme Programming Process Model
Kanban Process Model
Devops Process Model
Agile Process Model Pros-Cons
Understanding
Requirements
Understanding Requirements

– Memahami kebutuhan adalah salah satu tugas paling sulit yang dihadapi seorang
insinyur perangkat lunak.
– Ketika Anda pertama kali memikirkannya, mengembangkan pemahaman yang
jelas tentang persyaratan tampaknya tidak terlalu sulit. Lagi pula, bukankah
pelanggan tahu apa yang dibutuhkan? Bukankah seharusnya pengguna akhir
memiliki pemahaman yang baik tentang fitur dan fungsi yang mereka butuhkan?
– Anehnya, dalam banyak kasus, jawaban atas pertanyaan-pertanyaan ini adalah
TIDAK.
– bahkan jika pelanggan dan pengguna akhir dapat menyatakan kebutuhan
mereka secara eksplisit, kebutuhan tersebut akan berubah sepanjang proyek.
Requirement Engineering

– Requirement Engineering adalah istilah untuk cakupan tugas dan teknik yang luas
yang mengarah pada pemahaman tentang persyaratan.
– Dari perspektif proses perangkat lunak, Requirement Engineering adalah tindakan
rekayasa perangkat lunak utama yang dimulai selama aktivitas komunikasi dan
berlanjut ke aktivitas pemodelan.
– Requirement Engineering menetapkan dasar yang kokoh untuk desain dan konstruksi.
– Tanpa RE, perangkat lunak yang dihasilkan memiliki kemungkinan besar untuk tidak
memenuhi kebutuhan pelanggan.
– Penting untuk disadari bahwa setiap tugas ini dilakukan secara berulang karena tim
proyek dan pemangku kepentingan terus berbagi informasi tentang masalah mereka
masing-masing.
Requirement Engineering

– Requirement Engineering mencakup tujuh tugas dengan batas-batas yang

terkadang tidak terlalu tegas:
1. Inception
2. Elisitasi
3. Elaborasi
4. Negosiasi
5. Spesifikasi
6. Validasi
7. Manajemen
Requirement Engineering

1. Inception
membangun pemahaman dasar tentang masalah, orang-orang yang menginginkan
solusi, dan sifat solusi yang diinginkan.
2. Elisitasi
tanyakan kepada pelanggan, pengguna, dan orang lain apa tujuan sistem atau
produk, apa yang harus dicapai, bagaimana sistem atau produk cocok dengan
kebutuhan bisnis, dan terakhir, bagaimana sistem atau produk yang akan
digunakan sehari-hari.
3. Elaborasi
berfokus pada pengembangan model refined requirements yang mengidentifikasi
berbagai aspek fungsi perangkat lunak, perilaku, dan informasi
Requirement Engineering

4. Negosiasi
Bukan hal yang aneh bagi pelanggan dan pengguna untuk meminta lebih
dari yang dapat dicapai, mengingat sumber daya bisnis yang terbatas.
5. Spesifikasi
Spesifikasi dapat berupa dokumen tertulis, satu set model grafis, model
matematika formal, kumpulan skenario penggunaan, prototipe, atau
kombinasi dari semuanya.
Requirement Engineering

6. Validasi
memeriksa spesifikasi untuk memastikan bahwa semua persyaratan
perangkat lunak telah dinyatakan dengan jelas; bahwa inkonsistensi,
kelalaian, dan kesalahan telah dideteksi dan diperbaiki; dan bahwa produk
kerja sesuai dengan standar yang ditetapkan untuk proses, proyek, dan
produk.
7. Manajemen
adalah serangkaian aktivitas yang membantu tim proyek mengidentifikasi,
mengontrol, dan melacak persyaratan dan perubahan persyaratan setiap
saat saat proyek berlangsung.
Non Functional
Requirements
Nonfunctional Requirements

– Nonfunctional Requirements (NFR) dapat digambarkan sebagai atribut

kualitas, atribut kinerja, atribut keamanan, atau kendala umum pada suatu
sistem.
– NFR seringkali tidak mudah bagi para pemangku kepentingan untuk
mengartikulasikannya.
– Aspek NFR dalam pengembagnan PL yang paling umum ditemukan adalah
security, performance, dan usability
Nonfunctional Requirements

– Security:
Confidentiality, integrity, accountability, authenticity
– Performance
Timing, resource utilization, capacity
– Usability
Appropriateness, learnability, operability, error protection, aesthetics,
accessibility
 Terima Kasih

ada pertanyaan…???