Proses Software

Bab 2
Tujuan
Memahami konsep proses perangkat lunak
Memperkenalkan model proses software
Menggambarkan beberapa model proses dan
kapan digunakan
Menggambarkan secara garis besar model proses
untuk rekayasa kebutuhan, pengembangan
software,testing dan evolusi
Mengenalkan teknologi CASE untuk mendukung
aktifitas proses software
Proses Software

Sekumpulan aktifitas yang saling terkait

untuk spesifikasi, desain,implementasi dan
testing perangkat lunak.
Proses Software
Sekumpulan aktifitas terstruktur yang dibutuhkan untuk
mengembangkan sistem software, yang meliputi kegiatan :
o Spesifikasi perangkat lunak : Fungsionalitas
perangkat lunak dan batasan kemampuan
operasinya harus didefinisikan
o Pengembangan (Desain&Implementasi) perangkat
lunak : Perangkat lunak yang memenuhi spesifikasi
harus di produksi
o Validasi perangkat lunak, Perangkat lunak harus
divalidasi untuk menjamin bahwa perangkat lunak
bekerja sesuai dengan apa yang diinginkan oleh
pelanggan
 Evolusi perangkat lunak : Perangkat lunak
harus berkembang kembali untuk
memenuhi kebutuhan pelanggan
Model proses software adalah representasi
abstrak dari proses. Merupakan gambaran
dari proses dari beberapa perspektif
tertentu.
Model Proses Perangkat
Lunak(1)
Model waterfall
Model ini mengambil kegiatan proses
dasar seperti spesifikasi persyaratan,
perancangan perangkat lunak,
implementasi, pengujian, pemeliharaan
dan evolusi
Model Proses Perangkat
Lunak(2)
Model Pengembangan Evolusioner
Pendekatan ini berhimpitan dengan
kegiatan spesifikasi, pengembangan, dan
validasi. Suatu sistem awal dikembangkan
dgn cepat dari spesifikasi abstrak. Sistem
ini kemudian diperbaiki dengan masukan
dari pelanggan utk menghasilkan sistem
yang memuaskan bagi kebutuhan
pelanggan.
Model Proses Perangkat
Lunak(3)
Pengembangan sistem formal
Pendekatan ini didasarkan atas
pembuatan spesifikasi sistem matematis,
dan pentransformsian spesifikasi ini,
dengan memakai metode matematis, utk
membangun program
Model Proses Perangkat
Lunak(4)
Pengembangan berdasarkan pemakaian
ulang.
Pendekatan ini didasarkan atas komponen
yang dapat dipakai ulang dalam jumlah
yang signifikan. Proses pengembangan
sistem terfokus pada integrasi komponen
ini ke dalam suatu sistem, dan bukan
mengembangkannya dari awal.
Model Waterfall(1)
Fase model Waterfall(2)
Analisa dan definisi kebutuhan(definisi
persyaratan.
Pelayanan, batasan, dan tujuan sistem
ditentukan melalui konsultasi dgn user.
Persyaratan/kebutuhan ini kmd
didefinisikan secara rinci dan berfungsi sbg
spesifikasi sistem
Fase model Waterfall(3)
Desain sistem dan software
Proses perancangan sistem membagi
kebutuhan/persyaratan dalam sistem
perangkat keras atau perangkat lunak.
Perancangan perangkat lunak melibatkan
identifikasi dan deskripsi abstraksi sistem
perangkat lunak yang mendasar dan
hubungan-hubungannya. Menentukan
arsitektur sistem secara keseluruhan.
Fase model Waterfall(4)
Implementasi dan unit testing
Pada tahap ini perancangan perangkat
lunak direalisasikan sbg serangkaian
program atau unit program. Pengujian unit
melibatkan verifikasi bahwa setiap unit
telah memenuhi spesifikasinya.
Fase model Waterfall(5)
Integrasi dan testing sistem
Unit program atau program individual
diintegrasikan dan diuji sbg sistem yg
lengkap utk menjamin bahwa persyaratan
sistem telah dipenuhi. Setelah pengujian
sistem, PL dikirim kepada pelanggan
Fase model Waterfall(6)
Operasi dan maintenance
Biasanya (walau tdk sehrsnya), ini merupakan
fase siklus yg paling lama. Sistem diinstal dan
dipakai. Pemeliharaan mencakup koreksi dari
berbagai error yg tdk ditemukan pada tahap2
sblmnya, perbaikan atas implementasi unit
sistem dan pengembangan pelayanan sistem dan
persyaratan2 baru ditambahkan
Kekurangan dari model waterfall adalah
kesulitan untuk mengakomodasi perubahan
setelah proses berjalan
Fase-fase Waterfall menurut
Pressman
Masalah dengan model
waterfall
Terjadinya pembagian proyek menjadi
tahap-tahap yang tidak fleksibel, karena
komitmen harus dilakukan pada tahap
awal proses.
Hal ini mengakibatkan sulitnya untuk
merespon perubahan kebutuhan pengguna
(user).
Model air terjun harus digunakan hanya
ketika persyaratan dipahami dengan baik.
Pengembangan Evolusioner
terdiri dari :
Pengembangan Exploratory
o Tujuannya : bekerja dengan konsumen utk
menyelidiki persyaratan mereka dan
mengirimkan sistem akhir. Pengembangan
dimulai dgn bagian2 sistem yg dipahami.
Sistem berubah dgn adanya tambahan fitur2
baru sesuai usulan pelanggan
Pengembangan Evolusioner
terdiri dari :
Throw-away prototyping(Prototipe yg dpt
dibuang)
o Tujuan : mengerti kebutuhan sistem.
Dimulai dengan kebutuhan/persyaratan
pelanggan yang tidak
dipahami/dimengerti dengan baik
Pengembangan Evolusioner
Pengembangan Evolusioner
Permasalahan
o Tidak ada visibilitas proses(proses tidak bisa
dilihat). Jika sistem dikembangkan dgn cepat, tidaklah
efektif dari segi biaya jika dihasilkan dokumen yg
merefleksikan setiap proses sistem.
o Sistem biasanya tidak terstruktur dengan baik
o Diperlukan alat bantu dan teknik khusus
o Untuk sistem interaktif berukuran kecil (100.000 baris
kode) atau medium(500.000 baris kode)
o Untuk sistem besar yg besar dan memiliki waktu hidup
lama pengembangan evolusioner menimbulkan masalah
o Untuk sistem dengan daur hidup pendek
Kelebihan model Pengembangan
Evolusioner
Lebih efektif dari pendekatan air terjun
dalam menghasilkan sistem yang
memenuhi kebutuhan langsung dari
pelanggan.
Sementara user mendapat pemahaman
yang lebih baik dari masalah mereka,
sistem perangkat lunak dapat
merefleksikannya.
Pengembangan Sistem Formal
(1)
Proses pengembangan Perangkat Lunak
didasarkan pada transformasi matematis
dari spesifikasi sistem menjadi program
yang dapat dijalankan.

Requirements Formal Formal Integrationand

definition specification transformation systemtesting
Pengembangan Sistem
Formal
Permasalahan
Pendekatan ini memerlukan keahlian
khusus dan sesungguhnya utk sebagian
besar sistem proses ini tidak memberikan
keuntungan biaya/kualitas yg signifikan
dibanding pendekatan yg lain
Pengembangan Reuse-
oriented(1)
Pada sebagian besar proyek PL, terjadi
pemakaian ulang. Hal ini biasanya terjadi
secara informal ketika orang yang bekerja
diproyek tsb mengetahui adanya
rancangan/kode yg mirip dgn yg
dibutuhkan.
Kode tersebut dicari, kmd
memodifikasinya sbgmana dibutuhkan dan
menggabungkannya dlm sistem.
Pengembangan Reuse-
oriented(2)
Berbasis systematic reuse dimana sistem
diintegrasikan dalam komponen yang
sudah ada atau kadang komponen ini
merupakan sistem juga
(COTS/Commercial-off-the shelf
system/sistem siap beli komersial)yg dpt
digunakan utk memberikan fungsionalitas
khusus seperti format teks, perhitungan
numerik, dll
Pengembangan Reuse-
oriented(3)
Tahap-tahapnya :
1. Analisakomponen
Jika diketahui spesifikasi persyaratan,
komponen2 utk implementasi spesifikasi
tsb akan dicari. Biasanya tdk ada
kesesuaian tepat dan komponen yg
dipakai hanya memberikan sebagian dari
fungsional yg dibutuhkan.
Pengembangan Reuse-
oriented(4)
2. Modifikasi kebutuhan
Pada tahap ini, persyaratan dianalisis dgn
menggunakan informasi mengenai
komponen yg telah didapat. Persyaratan
kemudian dimodifikasi utk merefleksikan
komponen yg tersedia. Jika modifikasi tdk
mungkin dilakukan, maka kegiatan analisis
komponen bisa diulang utk mencari solusi
alternatif.
Pengembangan Reuse-
oriented(5)
3. Desain sistem dengan reuse/pemakain ulang
Pada fase ini kerangka kerja sistem dirancang atau
kerangka kerja yg telah ada dipakai ulang. Beberapa
PL yg baru mungkin perlu dirancang jk komponen yg
dpt dipakai ulang tdk tersedia
4. Pengembangan dan integrasi
PL yg tdk dpt dibeli akan dikembangkan dan
komponen diintegrasikan utk membentuk sistem.
Integrasi sistem pd model ini bisa merupakan proses
pengembangan dan bukan kegiatan terpisah
Pendekatan ini menjadi lebih penting tetapi masih
terbatas penggunaannya
Pengembangan Re-Usable

Requirements Component Requirements Systemdesign

specification analysis modification withreuse

Development System
andintegration validation
Pengembangan Reuse-
oriented(7)
Keuntungan pengembangan ini adl
memperkecil biaya
Memungkinkan penyelesaian PL cepat
Iterasi Proses
Semua model proses yg ada memiliki kelebihan
dan kekurangan
Utk sistem yg besar perlu digunakan berbagai
pendekatan utk berbagai bagian sistem, shg
harus digunakan model hibrid atau model proses
iteratif
Model proses iteratif mengambarkan proses PL
sbg suatu siklus kegiatan.
Model proses iteratif mencakup 2 pendekatan :
o Pengembangan incremental
o Pengembangan spiral
Pengembangan
Incremental(1)
Diusulkan oleh Mills(1980)
Pd proses pengembangan inkremental, pelanggan
mengidentifikasi scr grs besar layanan (service)
yg akan disediakan oleh sistem.
Kmd diidentifikasi layanan mana yg paling
penting dan mana yg paling tdk penting. Bagian2
(inkrement) yg penting kmd diidentifikasi, setiap
inkrement memberikan fungsionalitas sistem.
Alokasi layanan pd inkrement bergantung pd
prioritas layanan.Layanan dgn prioritas tertinggi
dikirimkan terlebih dahulu ke pelanggan.
Pengembangan
Incremental(2)
Begitu inkrement sistem telah
teridentifikasi, persyaratan utk layanan yg
hrs diserahkan pd inkrement pertama
didefinisikan dgn rinci dan inkrement tsb
dikembangkan dgn menggunakan proses
pengembangan yg cocok.
Pd saat pengembangan, analisis
persyaratan utk inkrement berikutnya dpt
dilakukan, tetapi perubahan persyaratan
utk inkrement yg sdg dikerjakan tdk dpt
diterima
Pengembangan
Incremental(3)
Begitu satu inkrement telah selesai dan
diserahkan, maka pelanggan dpt
menggunakannya. Ini berarti pelanggan
menerima pernyerahan awal dari sebagian
fungsionalitas sistem. Demikian seterusnya hinga
seluruh inkrement selesai.
Integrasi inkrement baru dgn inkrement yg sdh
ada akan dilakukan shg fungsionalitas sistem
bertambah baik dgn ditambahkannya setiap
inkrement yg dikirimkan
Pengembangan Inkrement
Penjelasan model Inkremen
Pressman
Kombinasikan elemet-element dari waterfall dengan sifat
iterasi/perulangan.
Element-element dalam waterfall dikerjakan dengan hasil
berupa produk dengan spesifikasi tertentu, kemudian
proses dimulai dari fase pertama hingga akhir dan
menghasilkan produk dengan spesifikasi yang lebih lengkap
dari yang sebelumnya. Demikian seterusnya hingga semua
spesifikasi memenuhi kebutuhan yang ditetapkan oleh
pengguna.
Produk hasil increment pertama biasanya produk inti (core
product), yaitu produk yang memenuhi kebutuhan dasar.
Produk tersebut digunakan oleh pengguna atau menjalani
review/pengecekan detil. Hasil review tersebut menjadi
bekal untuk pembangunan pada increment berikutnya. Hal
ini terus dikerjakan sampai produk yang komplit dihasilkan.
Mampu mengakomodasi perubahan secara fleksibel.
Produk yang dihasilkan pada increment pertama bukanlah
prototype, tapi produk yang sudah bisa berfungsi dengan
spesifikasi dasar.
Model Increment
Sommerville
Defineoutline Assignrequirements Designsystem
requirements toincrements architecture

Developsystem Valida te Integrate Valida te

increment increment increment system
Final
system
Systemincomplete
Keuntungan Pengembangan
Incremental
Pelanggan tdk perlu menunggu sampai
seluruh sistem dikirimkan. Increment
pertama sdh memenuhi persyaratan
mereka yg plg kritis, shg PL dpt segera
digunakan.
increment awal berfungsi sebagai
prototype untuk membantu memperoleh
kebutuhan increment selanjutnya
Resiko kegagalan proyek lebih rendah
Layanan sistem prioritas tertinggi
cenderung menerima testing terbanyak
Pemrograman Extreme
Diusulkan oleh Beck(1999)
Pendekatan baru untuk pengembangan
berbasis pengembangan dan pelepasan
fungsional increment yang sangat kecil
Mempercayakan perbaikan konstan,
keterlibatan user dalam tim pengembang
dan pemrograman
Namun msh terlalu dini utk mengatakan
apk ini akan menjadi pendekatan yg
umum pengembangan PL
Pengembangan Spiral(1)
Diusulkan oleh Boehm(1988)
Proses direpresentasikan sebagai spiral
bukan sebagai urutan aktivitas dengan
melihat sistem sebelumnya (backtracking)
Setiap untai/loop dalam spiral
merepresentasikan fase dalam proses
Dgn demikian untai yg plg dlm berkenaan
dgn kelayakan sistem, untai berikutnya dgn
definisi persyaratan dan untai berikutnya
perancangan sistem demikian seterusnya.
Pengembangan Spiral(2)
Setiap untai pd spiral dibagi 4 sektor :
1. Penentuan tujuan. Tujuan yg spesifik
utk fase proyek,batasan dan resiko proyek
didefinisikan.
2. Penilaian dan pengurangan resiko. Misal
jika ada resiko persyaratan tdk sesuai
mungkin diperlukan pengembangan sistem
prototipe.
Pengembangan Spiral(3)
3. Pengembangan dan validasi. Setelah
evaluasi resiko, model pengembangan utk
sistem kmd dipilih. Contoh: jika resiko
interface user adl paling dominan, model
pengembangan prototipe evolusiner yg
paling cocok, jika resiko utama adl
integrasi subsistem maka model
pengembangan yg paling cocok adl
waterfall.
Pengembangan Spiral(4)
4. Perencanaan. Proyek ditinjau dan
selanjutnya dibuat keputusan apk akan
diteruskan dgn untai spiral berikutnya.
Jika diputuskan utk terus, maka dibuat
rencana fase proyek berikutnya.
Pengembangan Spiral(5)
Perbedaan penting antara model
spiral dgn model proses perangkat
lunak lainnya adalah dilakukan
pertimbangan resiko
SPIRAL MODEL
RAD (Rapid Application
Development)
RAD adalah model proses pembangunan PL yang
incremental.
RAD menekankan pada siklus pembangunan yang
pendek/singkat.
RAD mengadopsi model waterfall dan
pembangunan dalam waktu singkat dicapai dengan
menerapkan component based construction.
Waktu yang singkat adalah batasan yang penting
untuk model ini.
Jika kebutuhan lengkap dan jelas maka waktu
yang dibutuhkan untuk menyelesaikan secara
komplit software yang dibuat adalah misalnya 60
sampai 90 hari.
Kelemahan dalam model
ini:
Tidak cocok untuk proyek skala besar
Proyek bisa gagal karena waktu yang
disepakati tidak dipenuhi
Sistem yang tidak bisa dimodularisasi
tidak cocok untuk model ini
Resiko teknis yang tinggi juga kurang
cocok untuk model ini
Gambar Model RAD
 Fase-fase di atas menggambarkan proses dalam
model RAD.
Sistem dibagi-bagi menjadi beberapa modul dan
dikerjakan dalam waktu yang hampir bersamaan
dalam batasan waktu yang sudah ditentukan.
Business modelling : menjawab pertanyaan-pertanyaan:
informasi apa yang mengendalikan proses bisnis? Informasi apa
yang dihasilkan? Siapa yang menghasilkan informasi? Kemana
informasi itu diberikan? Siapa yang mengolah informasi?
kebutuhan dari sistem
Data modelling: aliran informasi yang sudah didefinisikan,
disusun menjadi sekumpulan objek data. Ditentukan
karakteristik/atribut dan hubungan antar objek-objek tersebut
analisis kebutuhan dan data
Process Modelling : objek data yang sudah didefinisikan diubah
menjadi aliran informasi yang diperlukan untukmenjalankan
fungsi-fungsi bisnis.
Application Generation: RAD menggunakan component program
yang sudah ada atau membuat component yang bisa digunakan
lagi, selama diperlukan.
Testing and Turnover: karena menggunakan component yang
sudah ada, maka kebanyakan component sudah melalui uji atau
testing. Namun component baru dan interface harus tetap diuji.
Prototyping Model
Kadang-kadang klien hanya memberikan
beberapa kebutuhan umum software tanpa
detil input, proses atau detil output.
Di lain waktu mungkin dimana tim
pembangun (developer) tidak yakin
terhadap efisiensi dari algoritma yang
digunakan, tingkat adaptasi terhadap
sistem operasi atau rancangan form user
interface.
Ketika situasi seperti ini terjadi model
prototyping sangat membantu proses
pembangunan software.
Proses pada model prototyping yang bisa
dijelaskan
sebagai berikut:
Pengumpulan kebutuhan: developer dan klien
bertemu dan menentukan tujuan umum,
kebutuhan yang diketahui dan gambaran bagian-
bagian yang akan dibutuhkan berikutnya. Detil
kebutuhan mungkin tidak dibicarakan disini, pada
awal pengumpulan kebutuhan

Perancangan : perancangan dilakukan cepat dan

rancangan mewakili semua aspek software yang
diketahui, dan rancangan ini menjadi dasar
pembuatan prototype.

Evaluasi prototype: klien mengevaluasi prototype

yang dibuat dan digunakan untuk memperjelas
kebutuhan software.
Gambar model Prototype
 Perulangan ketiga proses ini terus berlangsung
hingga semua kebutuhan terpenuhi.

Prototype-prototype dibuat untuk memuaskan

kebutuhan klien dan untuk memahami kebutuhan
klien lebih baik.

Prototype yang dibuat dapat dimanfaatkan

kembali untuk membangun software lebih cepat,
namun tidak semua prototype bisa dimanfaatkan.

Sekalipun prototype memudahkan komunikasi

antar developer dan klien, membuat klien
mendapat gambaran awal dari prototype ,
membantu mendapatkan kebutuhan detil lebih
baik namun demikian prototype juga
menimbulkan masalah.
Masalah2 yg ada pada
Prototype Model :
1. Dalam membuat prototype banyak hal yang
diabaikan seperti efisiensi, kualitas, kemudahan
dipelihara/dikembangkan, dan kecocokan
dengan lingkungan yang sebenarnya. Jika klien
merasa cocok dengan prototype yang disajikan
dan berkeras terhadap produk tersebut, maka
developer harus kerja keras untuk mewujudkan
produk tersebut menjadi lebih baik, sesuai
kualitas yang seharusnya.
2. developer biasanya melakukan kompromi dalam
beberapa hal karena harus membuat prototype
dalam waktu singkat. Mungkin sistem operasi
yang tidak sesuai, bahasa pemrograman yang
berbeda, atau algoritma yang lebih sederhana.
 Agar model ini bisa berjalan dengan baik,
perlu disepakati bersama oleh klien dan
developer bahwa prototype yang dibangun
merupakan alat untuk mendefinisikan
kebutuhan software.
Spesifikasi Perangkat
Lunak(1)
Spesfikasi PL ditujukan utk menetapkan layanan
apa yg dituntut dari sistem dan batasan pada
operasi dan pengembangan sistem
Kegiatan ini sering disebut rekayasa persyaratan
Rekayasa persyaratan adl proses pengembangan
spesifikasi PL
Kegiatan ini mencakup pengembangan spesifikasi
yg dpt dipahami oleh user sistem dan spesifikasi
yg lebih rinci bagi pengembang sistem
Spesifikasi Perangkat
Lunak(2)
Rekayasa persyaratan merupakan tahap
yg sangat kritis dari proses PL krn
kesalahan pd tahap ini pd akhirnya
menimbulkan masalah pd perancangan
dan implementasi sistem
Fase Rekayasa
Persyaratan(1)
1. Studi Kelayakan. Studi ini memutuskan
apk sistem yg diusulkan efektif dlm hal
biaya dari sudut pandang bisnis dan
apakah sistem dpt dikembangkan dgn
keterbatasan anggaran biaya
2. Perolehan dan analisa kebutuhan. Ini
merupakan proses penurunan
persyaratan sistem melalui observasi
sistem yg ada, diskusi dgn user yg akan
memakai dan yg mengadakan, analisis
pekerjaan.
Fase Rekayasa
Persyaratan(2)
3. Spesifikasi Persyaratan. Adalah kegiatan
menterjemahkan informasi yg
dikumpulkan pd kegiatan analisis menjadi
dokumen yg mendefinisikan persyaratan
user dan persyaratan sistem
4. Validasi persyaratan. Kegiatan ini
memeriksa apk persyaratan dpt
direalisasi, konsisten dan lengkap.
Kesalahan yg ada dimodifikasi utk
menyelesaikan masalah
Perancangan Dan
Implementasi PL
Merupakan proses pengubahan
spesifikasi sistem mjd sistem yg dpt
dijalankan.
Tahap ini selalu mencakup proses
perancangan dan pemrograman PL,
tetapi jika digunakan pendekatan
evolusioner, maka bisa juga melibatkan
perbaikan spesifikasi PL
 Perancangan PL merupakan deskripsi
struktur PL yg akan diimplementasikan,
data yg merupakan bagian
sistem,interface antara komponen2 sistem
dan kadang2 algoritma yg digunakan