BAB 1

PENGANTAR ANALISIS DAN DESAIN SISTEM

Bab 1 memperkenalkan siklus hidup pengembangan sistem (SDLC), model

empat fase dasar (perencanaan, analisis, desain, dan implementasi) yang
umum untuk semua proyek pengembangan sistem informasi. Ini
menjelaskan evolusi metodologi pengembangan sistem dan membahas
peran serta keterampilan yang diperlukan dari seorang analis sistem. Bab ini
kemudian memberikan gambaran tentang karakteristik dasar sistem
berorientasi objek dan dasar-dasar analisis serta desain sistem berorientasi
objek, serta diakhiri dengan deskripsi Proses Terpadu dan perluasannya serta
Bahasa Pemodelan Terpadu.

TUJUAN

 Memahami siklus hidup pengembangan sistem dasar dan empat

fasenya

 Memahami evolusi metodologi pengembangan sistem

 Mengenal perbedaan peran yang dimainkan oleh dan keterampilan

seorang analis sistem

 Mengenal karakteristik dasar sistem berorientasi objek

 Mengenal prinsip-prinsip dasar analisis dan desain sistem berorientasi

objek

 Mengenal Proses Terpadu, perluasannya, dan Bahasa Pemodelan

Terpadu

PENGANTAR

Siklus hidup pengembangan sistem (SDLC) adalah proses memahami

bagaimana sebuah sistem informasi (IS) dapat mendukung kebutuhan bisnis
dengan merancang sistem, membangunnya, dan menyampaikannya kepada
pengguna. Jika Anda pernah mengikuti kelas pemrograman atau
memprogram sendiri, ini mungkin terdengar cukup sederhana. Sayangnya,
tidak demikian. Sebuah survei tahun 1996 oleh Standish Group menemukan
bahwa 42 persen dari semua proyek IS perusahaan ditinggalkan sebelum
selesai. Sebuah studi serupa yang dilakukan pada tahun 1996 oleh Kantor
Akuntabilitas Umum menemukan 53 persen dari semua proyek IS
pemerintah AS ditinggalkan. Sayangnya, banyak sistem yang tidak
ditinggalkan diserahkan kepada pengguna secara signifikan terlambat,
biayanya jauh lebih mahal dari yang direncanakan, dan memiliki fitur yang
lebih sedikit dari yang direncanakan semula. Misalnya, IAG Consulting
melaporkan bahwa 80 persen proyek terlambat, 72 persen melebihi
anggaran, dan 55 persen berisi kurang dari fungsionalitas penuh; Panorama
Consulting Solutions melaporkan bahwa 54 persen proyek ERP terlambat, 56
persen melebihi anggaran, dan 48 persen memberikan kurang dari 50
persen manfaat awal; dan sebuah studi IBM melaporkan bahwa 59 persen
proyek melewatkan satu atau lebih dari batasan waktu, anggaran, dan
kualitas.¹ Meskipun kami ingin mempromosikan buku ini sebagai peluru
perak yang akan mencegah Anda dari kegagalan IS, kami dengan senang
hati mengakui bahwa peluru perak yang menjamin kesuksesan
pengembangan IS tidak ada. Sebaliknya, buku ini memberikan beberapa
konsep dasar dan banyak teknik praktis yang dapat Anda gunakan untuk
meningkatkan probabilitas kesuksesan.

Orang kunci dalam SDLC adalah analis sistem, yang menganalisis situasi
bisnis, mengidentifikasi peluang untuk perbaikan, dan merancang sistem
informasi untuk menerapkannya. Menjadi analis sistem adalah salah satu
pekerjaan yang paling menarik, menyenangkan, dan menantang. Analis
sistem bekerja dengan berbagai orang dan belajar bagaimana mereka
menjalankan bisnis. Secara spesifik, mereka bekerja dengan tim analis
sistem, programmer, dan lainnya dalam misi bersama. Analis sistem
merasakan kepuasan melihat sistem yang mereka rancang dan kembangkan
memberikan dampak bisnis yang signifikan, mengetahui bahwa mereka
menyumbangkan keterampilan unik untuk membuat hal itu terjadi.

Namun, tujuan utama seorang analis sistem bukanlah untuk menciptakan

sistem yang luar biasa; sebaliknya, itu untuk menciptakan nilai bagi
organisasi, yang bagi kebanyakan perusahaan berarti meningkatkan
keuntungan (lembaga pemerintah dan organisasi nirlaba mengukur nilai
secara berbeda). Banyak sistem yang gagal telah ditinggalkan karena analis
mencoba membangun sistem yang luar biasa tanpa memahami dengan jelas
bagaimana sistem tersebut akan sesuai dengan tujuan organisasi, proses
bisnis saat ini, dan sistem informasi lainnya untuk memberikan nilai.
Investasi dalam sistem informasi seperti investasi lainnya. Tujuannya bukan
untuk memperoleh alat, karena alat hanyalah sarana untuk mencapai tujuan;
tujuannya adalah memungkinkan organisasi melakukan pekerjaan lebih baik
sehingga dapat memperoleh keuntungan lebih besar atau melayani
konstituennya lebih efektif.
Buku ini memperkenalkan keterampilan dasar yang dibutuhkan seorang
analis sistem. Buku pragmatis ini membahas praktik terbaik dalam
pengembangan sistem; itu tidak menyajikan survei umum tentang
pengembangan sistem yang mencakup segala sesuatu tentang topik
tersebut. Dengan definisi, analis sistem melakukan sesuatu dan menantang
cara organisasi bekerja saat ini. Untuk mendapatkan hasil maksimal dari
buku ini, Anda perlu menerapkan secara aktif pada proyek pengembangan
sistem Anda sendiri ide dan konsep dalam contoh. Buku ini memandu Anda
melalui semua langkah untuk menyampaikan sistem informasi yang sukses.
Pada saat Anda menyelesaikan buku, Anda tidak akan menjadi analis ahli,
tetapi Anda akan siap untuk mulai membangun sistem secara nyata.

SIKLUS HIDUP PENGEMBANGAN SISTEM

Dalam banyak hal, membangun sistem informasi mirip dengan membangun

rumah. Pertama, rumah (atau sistem informasi) dimulai dengan ide dasar.
Kedua, ide ini diubah menjadi gambar sederhana yang ditunjukkan kepada
pelanggan dan disempurnakan (sering melalui beberapa gambar, masing-
masing memperbaiki yang sebelumnya) hingga pelanggan setuju bahwa
gambar tersebut menggambarkan apa yang dia inginkan. Ketiga, satu set
cetak biru dirancang yang menyajikan informasi yang jauh lebih rinci tentang
rumah (misalnya, jenis keran air atau di mana jack telepon akan
ditempatkan). Akhirnya, rumah dibangun mengikuti cetak biru, sering
dengan beberapa perubahan yang diarahkan oleh pelanggan saat rumah
dibangun.

SDLC memiliki empat fase dasar yang serupa: perencanaan, analisis, desain,
dan implementasi. Proyek yang berbeda mungkin menekankan bagian yang
berbeda dari SDLC atau mendekati fase SDLC dengan cara yang berbeda,
tetapi semua proyek memiliki elemen dari empat fase ini. Setiap fase itu
sendiri terdiri dari serangkaian langkah, yang bergantung pada teknik yang
menghasilkan hasil akhir (dokumen dan file spesifik yang memberikan
pemahaman tentang proyek).

¹ Untuk informasi lebih lanjut tentang masalah tersebut, lihat Capers Jones,
Patterns of Software System Failure and Success (London: International
Thompson Computer Press, 1996); Keith Ellis, Business Analysis Benchmark:
The Impact of Business Requirements on the Success of Technology Projects
(2008). Diambil pada Mei 2014 dari IAG Consulting, [Link]; H. H.
Jorgensen, L. Owen, dan A. Neus, Making Change Work (2008). Diambil pada
Mei 2014 dari IBM, [Link]; Panorama Consulting Solutions, 2012 ERP
Report (2012). Diambil pada Mei 2014 dari [Link].
Misalnya, dalam melamar masuk ke universitas, semua siswa melalui fase
yang sama: pengumpulan informasi, melamar, dan menerima. Setiap fase ini
memiliki langkah; misalnya, pengumpulan informasi mencakup langkah
seperti mencari sekolah, meminta informasi, dan membaca brosur. Siswa
kemudian menggunakan teknik (misalnya, pencarian Internet) yang dapat
diterapkan pada langkah (misalnya, meminta informasi) untuk menciptakan
hasil akhir (misalnya, evaluasi aspek yang berbeda dari universitas).

Dalam banyak proyek, fase dan langkah SDLC berlanjut dalam jalur logis dari
awal hingga akhir. Dalam proyek lain, tim proyek bergerak melalui langkah
secara berurutan, bertahap, berulang, atau dalam pola lainnya. Dalam
bagian ini, kami menjelaskan fase, tindakan, dan beberapa teknik yang
digunakan untuk menyelesaikan langkah pada tingkat yang sangat tinggi.

Untuk saat ini, ada dua poin penting yang perlu dipahami tentang SDLC.
Pertama, Anda harus mendapatkan rasa umum tentang fase dan langkah di
mana proyek IS bergerak dan beberapa teknik yang menghasilkan hasil akhir
tertentu. Kedua, penting untuk memahami bahwa SDLC adalah proses
penyempurnaan bertahap. Hasil akhir yang dihasilkan dalam fase analisis
memberikan ide umum tentang bentuk sistem baru. Hasil akhir ini digunakan
sebagai masukan ke fase desain, yang kemudian menyempurnakannya
untuk menghasilkan satu set hasil akhir yang menjelaskan dalam istilah yang
jauh lebih rinci bagaimana tepatnya sistem akan dibangun. Hasil akhir ini,
pada gilirannya, digunakan dalam fase implementasi untuk menghasilkan
sistem sebenarnya. Setiap fase menyempurnakan dan mengelaborasi
pekerjaan yang dilakukan sebelumnya.

Perencanaan

Fase perencanaan adalah proses dasar untuk memahami mengapa sistem

informasi harus dibangun dan menentukan bagaimana tim proyek akan
membangunnya. Ini memiliki dua langkah:

1. Selama inisiasi proyek, nilai bisnis sistem bagi organisasi diidentifikasi:

Bagaimana itu akan menurunkan biaya atau meningkatkan
pendapatan? Sebagian besar ide untuk sistem baru datang dari luar
area IS (misalnya, dari departemen pemasaran, akuntansi) dalam
bentuk permintaan sistem. Permintaan sistem menyajikan ringkasan
singkat tentang kebutuhan bisnis, dan itu menjelaskan bagaimana
sistem yang mendukung kebutuhan akan menciptakan nilai bisnis.
Departemen IS bekerja bersama dengan orang atau departemen yang
 menghasilkan permintaan (disebut sponsor proyek) untuk melakukan
analisis kelayakan.

Permintaan sistem dan analisis kelayakan disajikan kepada komite

persetujuan sistem informasi (kadang-kadang disebut komite pengarah),
yang memutuskan apakah proyek tersebut harus dilakukan.

2. Setelah proyek disetujui, itu memasuki manajemen proyek. Selama

manajemen proyek, manajer proyek membuat rencana kerja,
mempekerjakan proyek, dan menempatkan teknik untuk membantu
tim proyek mengendalikan dan mengarahkan proyek melalui seluruh
SDLC. Hasil akhir untuk manajemen proyek adalah rencana proyek,
yang menjelaskan bagaimana tim proyek akan membangun sistem.

Analisis

Fase analisis menjawab pertanyaan siapa yang akan menggunakan sistem,

apa yang akan dilakukan sistem, dan di mana dan kapan itu akan digunakan.
Selama fase ini, tim proyek menyelidiki sistem yang ada, mengidentifikasi
peluang untuk perbaikan, dan mengembangkan konsep untuk sistem baru.

Fase ini memiliki tiga langkah:

1. Strategi analisis dikembangkan untuk memandu upaya tim proyek.

Strategi seperti itu biasanya mencakup analisis sistem saat ini (disebut
sistem as-is) dan masalahnya serta cara untuk merancang sistem baru
(disebut sistem to-be).

2. Langkah selanjutnya adalah pengumpulan persyaratan (misalnya,

melalui wawancara atau kuesioner). Analisis informasi ini—bersama
dengan masukan dari sponsor proyek dan banyak orang lain—
mengarah pada pengembangan konsep untuk sistem baru. Konsep
sistem kemudian digunakan sebagai dasar untuk mengembangkan
satu set model analisis bisnis, yang menjelaskan bagaimana bisnis
akan beroperasi jika sistem baru dikembangkan.

3. Analisis, konsep sistem, dan model digabungkan menjadi dokumen

yang disebut proposal sistem, yang disajikan kepada sponsor proyek
dan pembuat keputusan kunci lainnya (misalnya, anggota komite
persetujuan) yang memutuskan apakah proyek harus terus maju.

Proposal sistem adalah hasil akhir awal yang menjelaskan persyaratan bisnis
apa yang harus dipenuhi oleh sistem baru. Karena ini benar-benar langkah
pertama dalam desain sistem baru, beberapa ahli berargumen bahwa tidak
tepat menggunakan istilah "analisis" sebagai nama untuk fase ini; beberapa
berargumen nama yang lebih baik adalah "analisis dan desain awal."
Sebagian besar organisasi terus menggunakan nama analisis untuk fase ini,
namun, jadi kami menggunakannya dalam buku ini juga. Hanya ingatlah
bahwa hasil akhir dari fase analisis adalah baik analisis maupun desain
tingkat tinggi awal untuk sistem baru.

Desain

Fase desain memutuskan bagaimana sistem akan beroperasi, dalam hal

perangkat keras, perangkat lunak, dan infrastruktur jaringan; antarmuka
pengguna, formulir, dan laporan; dan program, basis data, dan file spesifik
yang akan dibutuhkan. Meskipun sebagian besar keputusan strategis
tentang sistem dibuat dalam pengembangan konsep sistem selama fase
analisis, langkah-langkah dalam fase desain menentukan secara tepat
bagaimana sistem akan beroperasi. Fase desain memiliki empat langkah:

1. Strategi desain dikembangkan terlebih dahulu. Ini menjelaskan apakah

sistem akan dikembangkan oleh programmer perusahaan sendiri,
apakah sistem akan dioutsourcing ke perusahaan lain (biasanya
perusahaan konsultasi), atau apakah perusahaan akan membeli paket
perangkat lunak yang ada.

2. Ini mengarah pada pengembangan desain arsitektur dasar untuk

sistem, yang menjelaskan perangkat keras, perangkat lunak, dan
infrastruktur jaringan yang akan digunakan. Dalam kebanyakan kasus,
sistem akan menambah atau mengubah infrastruktur yang sudah ada
dalam organisasi. Desain antarmuka menentukan bagaimana
pengguna akan bergerak melalui sistem (misalnya, metode navigasi
seperti menu dan tombol di layar) dan formulir serta laporan yang
akan digunakan sistem.

3. Spesifikasi basis data dan file dikembangkan. Ini menentukan secara

tepat data apa yang akan disimpan dan di mana mereka akan
disimpan.

4. Tim analis mengembangkan desain program, yang menentukan

program yang perlu ditulis dan apa tepatnya yang akan dilakukan
setiap program.

Koleksi hasil akhir ini (desain arsitektur, desain antarmuka, spesifikasi basis
data dan file, dan desain program) adalah spesifikasi sistem yang diserahkan
kepada tim pemrograman untuk implementasi. Pada akhir fase desain,
analisis kelayakan dan rencana proyek diperiksa ulang dan direvisi, dan
keputusan lain dibuat oleh sponsor proyek dan komite persetujuan tentang
apakah akan menghentikan proyek atau melanjutkan.

Implementasi

Fase akhir dalam SDLC adalah fase implementasi, di mana sistem

sebenarnya dibangun (atau dibeli, dalam kasus desain perangkat lunak
paket). Ini adalah fase yang biasanya mendapatkan perhatian paling banyak,
karena untuk sebagian besar sistem ini adalah bagian terpanjang dan paling
mahal dari proses pengembangan. Fase ini memiliki tiga langkah:

1. Konstruksi sistem adalah langkah pertama. Sistem dibangun dan diuji

untuk memastikan bahwa itu berkinerja seperti yang dirancang.
Karena biaya bug bisa sangat besar, pengujian adalah salah satu
langkah paling penting dalam implementasi. Sebagian besar organisasi
memberikan lebih banyak waktu dan perhatian untuk pengujian
daripada menulis program di tempat pertama.

2. Sistem diinstal. Instalasi adalah proses di mana sistem lama dimatikan

dan yang baru dihidupkan. Salah satu aspek terpenting dari konversi
adalah pengembangan rencana pelatihan untuk mengajari pengguna
bagaimana menggunakan sistem baru dan membantu mengelola
perubahan yang disebabkan oleh sistem baru.

3. Tim analis menetapkan rencana dukungan untuk sistem. Rencana ini

biasanya mencakup tinjauan pasca-implementasi formal atau informal
serta cara sistematis untuk mengidentifikasi perubahan besar dan kecil
yang dibutuhkan untuk sistem.

METODOLOGI PENGEMBANGAN SISTEM

Sebuah metodologi adalah pendekatan formal untuk menerapkan SDLC

(yaitu, itu adalah daftar langkah dan hasil akhir). Ada banyak metodologi
pengembangan sistem yang berbeda, dan masing-masing unik, berdasarkan
urutan dan fokus yang ditempatkan pada setiap fase SDLC. Beberapa
metodologi adalah standar formal yang digunakan oleh lembaga pemerintah,
sedangkan yang lain telah dikembangkan oleh perusahaan konsultasi untuk
dijual kepada klien. Banyak organisasi memiliki metodologi internal yang
telah diasah selama bertahun-tahun, dan mereka menjelaskan secara tepat
bagaimana setiap fase SDLC harus dilakukan di perusahaan tersebut.

Ada banyak cara untuk mengkategorikan metodologi. Salah satu cara adalah
dengan melihat apakah mereka fokus pada proses bisnis atau data yang
mendukung bisnis. Metodologi berpusat pada proses menekankan model
proses sebagai inti dari konsep sistem. Dalam Gambar 1-1, misalnya,
metodologi berpusat pada proses akan fokus pertama pada mendefinisikan
proses (misalnya, susun bahan sandwich). Metodologi berpusat pada data
menekankan model data sebagai inti dari konsep sistem. Dalam Gambar 1-1,
metodologi berpusat pada data akan fokus pertama pada mendefinisikan isi
area penyimpanan (misalnya, lemari es) dan bagaimana isi tersebut diatur.²
Sebaliknya, metodologi berorientasi objek mencoba menyeimbangkan fokus
antara proses dan data dengan memasukkan keduanya ke dalam satu
model. Dalam Gambar 1-1, metodologi ini akan fokus pertama pada
mendefinisikan elemen utama sistem (misalnya, sandwich, makan siang) dan
melihat proses dan data yang terlibat dengan setiap elemen.

Faktor penting lainnya dalam mengkategorikan metodologi adalah urutan

fase SDLC dan jumlah waktu serta upaya yang dicurahkan untuk masing-
masing.³ Pada hari-hari awal komputasi, programmer tidak memahami
kebutuhan akan metodologi siklus hidup yang formal dan direncanakan
dengan baik. Mereka cenderung bergerak langsung dari fase perencanaan
yang sangat sederhana ke langkah konstruksi fase implementasi—dengan
kata lain, dari permintaan sistem yang sangat kabur dan tidak dipikirkan
dengan baik ke penulisan kode. Ini adalah pendekatan yang sama yang
terkadang Anda gunakan saat menulis program untuk kelas pemrograman.
Ini bisa berhasil untuk program kecil yang

² Metodologi modern klasik berpusat pada proses adalah yang oleh Edward
Yourdon, Modern Structured Analysis (Englewood Cliffs, NJ: Yourdon Press,
1989). Contoh metodologi berpusat pada data adalah rekayasa informasi;
lihat James Martin, Information Engineering, vol. 1–3 (Englewood Cliffs, NJ:
Prentice Hall, 1989). Metodologi non-berorientasi objek yang diterima secara
luas dan distandardisasi yang menyeimbangkan proses dan data adalah
IDEF; lihat FIPS 183, Integration Definition for Function Modeling, Publikasi
Standar Pengolahan Informasi Federal, Departemen Perdagangan AS, 1993.

³ Referensi yang baik untuk membandingkan metodologi pengembangan

sistem adalah Steve McConnell, Rapid Development (Redmond, WA:
Microsoft Press, 1996).

hanya memerlukan satu programmer, tetapi jika persyaratan rumit atau

tidak jelas, Anda mungkin melewatkan aspek penting dari masalah dan
harus mulai dari awal lagi, membuang sebagian program (dan waktu serta
upaya yang dihabiskan untuk menulisnya). Pendekatan ini juga membuat
kerja tim sulit karena anggota memiliki sedikit ide tentang apa yang perlu
dicapai dan bagaimana bekerja bersama untuk menghasilkan produk akhir.
Dalam bagian ini, kami menjelaskan tiga kelas metodologi pengembangan
sistem yang berbeda: desain terstruktur, pengembangan aplikasi cepat, dan
pengembangan agile.

Desain Terstruktur

Kategori pertama dari metodologi pengembangan sistem disebut desain

terstruktur. Metodologi ini menjadi dominan pada tahun 1980-an,
menggantikan pendekatan ad hoc dan tidak disiplin sebelumnya. Metodologi
desain terstruktur mengadopsi pendekatan langkah demi langkah formal
untuk SDLC yang bergerak secara logis dari satu fase ke fase berikutnya.
Banyak metodologi berpusat pada proses dan berpusat pada data mengikuti
pendekatan dasar dari dua kategori desain terstruktur yang diuraikan
selanjutnya.

Pengembangan Air Terjun Metodologi desain terstruktur asli (masih

digunakan hari ini) adalah pengembangan air terjun. Dengan metodologi
berbasis pengembangan air terjun, analis dan pengguna melanjutkan secara
berurutan dari satu fase ke fase berikutnya (lihat Gambar 1-2). Hasil akhir
kunci untuk setiap fase biasanya sangat panjang (sering ratusan halaman
panjang) dan disajikan kepada sponsor proyek untuk persetujuan saat
proyek bergerak dari fase ke fase. Setelah sponsor menyetujui pekerjaan
yang dilakukan untuk suatu fase, fase berakhir dan yang berikutnya dimulai.
Metodologi ini disebut pengembangan air terjun karena bergerak maju dari
fase ke fase dengan cara yang sama seperti air terjun. Meskipun
dimungkinkan untuk mundur dalam SDLC (misalnya, dari desain kembali ke
analisis), itu sangat sulit (bayangkan diri Anda sebagai salmon yang
mencoba berenang ke hulu melawan air terjun, seperti yang ditunjukkan
dalam Gambar 1-2).

Desain terstruktur juga memperkenalkan penggunaan teknik pemodelan

atau diagramming formal untuk menjelaskan proses bisnis dasar dan data
yang mendukungnya. Desain terstruktur tradisional menggunakan satu set
diagram untuk mewakili proses dan satu set diagram terpisah untuk
mewakili data. Karena dua set diagram digunakan, analis sistem harus
memutuskan set mana yang akan dikembangkan terlebih dahulu dan
digunakan sebagai inti sistem: diagram model proses atau diagram model
data.

Dua keuntungan kunci dari pendekatan air terjun desain terstruktur adalah
bahwa itu mengidentifikasi persyaratan sistem lama sebelum pemrograman
dimulai dan itu meminimalkan perubahan pada persyaratan saat proyek
berlangsung. Dua kerugian kunci adalah bahwa desain harus sepenuhnya
ditentukan sebelum pemrograman dimulai dan waktu yang lama berlalu
antara penyelesaian proposal sistem dalam fase analisis dan pengiriman
sistem (biasanya banyak bulan atau tahun). Jika tim proyek melewatkan
persyaratan penting, pemrograman pasca-implementasi yang mahal
mungkin diperlukan (bayangkan diri Anda mencoba merancang mobil di atas
kertas; seberapa mungkin Anda ingat lampu interior yang menyala saat
pintu terbuka atau menentukan jumlah katup yang benar pada mesin?).
Sebuah sistem juga dapat memerlukan pengerjaan ulang yang signifikan
karena lingkungan bisnis telah berubah dari waktu ketika fase analisis
terjadi.

Pengembangan Paralel Metodologi pengembangan paralel mencoba

mengatasi masalah keterlambatan panjang antara fase analisis dan
pengiriman sistem. Alih-alih melakukan desain dan implementasi secara
berurutan, itu melakukan desain umum untuk seluruh sistem dan kemudian
membagi proyek menjadi serangkaian subproyek berbeda yang dapat
dirancang dan diimplementasikan secara paralel. Setelah semua subproyek
selesai, potongan terpisah diintegrasikan dan sistem diserahkan (lihat
Gambar 1-3).

Keuntungan utama dari metodologi ini adalah bahwa itu dapat mengurangi
waktu untuk menyampaikan sistem; dengan demikian, ada lebih sedikit
kemungkinan perubahan dalam lingkungan bisnis yang menyebabkan
pengerjaan ulang. Namun, terkadang subproyek tidak sepenuhnya
independen; keputusan desain yang dibuat dalam satu subproyek dapat
memengaruhi yang lain, dan akhir proyek dapat memerlukan upaya integrasi
yang signifikan.

Pengembangan Aplikasi Cepat (RAD)

Kategori kedua dari metodologi mencakup metodologi berbasis

pengembangan aplikasi cepat (RAD). Ini adalah kelas metodologi
pengembangan sistem yang lebih baru yang muncul pada tahun 1990-an.
Metodologi berbasis RAD mencoba mengatasi kedua kelemahan metodologi
desain terstruktur dengan menyesuaikan fase SDLC untuk mendapatkan
sebagian dari sistem yang dikembangkan dengan cepat dan ke tangan
pengguna. Dengan cara ini, pengguna dapat lebih memahami sistem dan
menyarankan revisi yang membawa sistem lebih dekat dengan apa yang
dibutuhkan.⁴
Sebagian besar metodologi berbasis RAD merekomendasikan bahwa analis
menggunakan teknik khusus dan alat komputer untuk mempercepat fase
analisis, desain, dan implementasi, seperti alat rekayasa perangkat lunak
dibantu komputer (CASE), sesi desain aplikasi bersama (JAD), bahasa
pemrograman generasi keempat atau visual yang menyederhanakan dan
mempercepat pemrograman, dan generator kode yang secara otomatis
menghasilkan program dari spesifikasi desain. Kombinasi fase SDLC yang
diubah dan penggunaan alat dan teknik ini meningkatkan kecepatan dan
kualitas pengembangan sistem. Namun, ada satu masalah halus yang
mungkin dengan metodologi berbasis RAD: mengelola harapan pengguna.
Karena penggunaan alat dan teknik yang dapat meningkatkan kecepatan
dan kualitas pengembangan sistem, harapan pengguna tentang apa yang
mungkin dapat berubah secara dramatis. Saat pengguna lebih memahami
teknologi informasi (IT), persyaratan sistem cenderung berkembang. Ini
kurang menjadi masalah ketika menggunakan metodologi yang
menghabiskan banyak waktu untuk mendokumentasikan persyaratan secara
menyeluruh.

Pengembangan Bertahap Metodologi berbasis pengembangan bertahap

memecah sistem keseluruhan menjadi serangkaian versi yang
dikembangkan secara berurutan. Fase analisis mengidentifikasi konsep
sistem secara keseluruhan, dan tim proyek, pengguna, dan sponsor sistem
kemudian mengkategorikan persyaratan menjadi serangkaian versi.
Persyaratan yang paling penting dan mendasar digabungkan ke dalam versi
pertama sistem. Fase analisis kemudian mengarah ke desain dan
implementasi—tapi hanya dengan set persyaratan yang diidentifikasi untuk
versi 1 (lihat Gambar 1-4).

Setelah versi 1 diimplementasikan, kerja dimulai pada versi 2. Analisis

tambahan dilakukan berdasarkan persyaratan yang diidentifikasi
sebelumnya dan digabungkan dengan ide dan masalah baru yang muncul
dari pengalaman pengguna dengan versi 1. Versi 2 kemudian dirancang dan
diimplementasikan, dan kerja segera dimulai pada versi berikutnya. Proses
ini berlanjut hingga sistem selesai atau tidak lagi digunakan.

Metodologi berbasis pengembangan bertahap memiliki keuntungan

mendapatkan sistem yang berguna dengan cepat ke tangan pengguna.
Meskipun sistem tidak melakukan semua fungsi yang dibutuhkan pengguna
pada awalnya, itu mulai memberikan nilai bisnis lebih cepat daripada jika
sistem diserahkan setelah selesai, seperti halnya dengan metodologi air
terjun dan paralel. Demikian pula, karena pengguna mulai bekerja dengan
sistem lebih cepat, mereka lebih mungkin mengidentifikasi persyaratan
tambahan penting lebih cepat daripada dengan situasi desain terstruktur.

Kerugian utama dari pengembangan bertahap adalah bahwa pengguna

mulai bekerja dengan sistem yang sengaja tidak lengkap. Penting untuk
mengidentifikasi fitur yang paling penting dan berguna dan memasukkannya
ke dalam versi pertama serta mengelola harapan pengguna sepanjang jalan.

Prototyping Metodologi berbasis prototyping melakukan fase analisis,

desain, dan implementasi secara bersamaan, dan ketiga fase dilakukan
berulang-ulang dalam siklus hingga sistem selesai. Dengan metodologi ini,
dasar-dasar analisis dan desain dilakukan, dan kerja segera dimulai pada
prototipe sistem, program cepat dan kotor yang memberikan jumlah fitur
minimal. Prototipe pertama biasanya adalah bagian pertama dari sistem
yang digunakan. Ini ditunjukkan kepada pengguna dan sponsor proyek, yang
memberikan komentar. Komentar ini digunakan untuk menganalisis ulang,
mendesain ulang, dan mengimplementasikan ulang prototipe kedua, yang
memberikan beberapa fitur lebih banyak. Proses ini berlanjut dalam siklus
hingga analis, pengguna, dan sponsor setuju bahwa prototipe memberikan
fungsionalitas yang cukup untuk diinstal dan digunakan dalam organisasi.
Setelah prototipe (sekarang disebut "sistem") diinstal, penyempurnaan
terjadi hingga diterima sebagai sistem baru (lihat Gambar 1-5).

Keuntungan kunci dari metodologi berbasis prototyping adalah bahwa itu

sangat cepat memberikan sistem yang dapat berinteraksi dengan pengguna,
bahkan jika tidak siap untuk penggunaan organisasi yang luas pada awalnya.
Prototyping meyakinkan pengguna bahwa tim proyek sedang bekerja pada
sistem (tidak ada keterlambatan panjang di mana pengguna melihat sedikit
kemajuan), dan prototyping membantu untuk lebih cepat menyempurnakan
persyaratan nyata.

Masalah utama dengan prototyping adalah bahwa pelepasan sistem yang

cepat menantang upaya untuk melakukan analisis yang hati-hati dan
metodis. Seringkali prototipe mengalami perubahan signifikan sehingga
banyak keputusan desain awal menjadi buruk. Ini dapat menyebabkan
masalah dalam pengembangan sistem kompleks karena isu dan masalah
dasar tidak dikenali hingga jauh ke dalam proses pengembangan. Bayangkan
membangun mobil dan menemukan terlambat dalam proses prototyping
bahwa Anda harus mengeluarkan seluruh mesin untuk mengganti oli (karena
tidak ada yang memikirkan kebutuhan untuk mengganti oli hingga setelah
itu dikendarai 10.000 mil).
Prototyping Buang Metodologi berbasis prototyping buang mirip dengan
metodologi berbasis prototyping karena mencakup pengembangan prototipe;
namun, prototipe buang dilakukan pada titik yang berbeda dalam SDLC.
Prototipe ini digunakan untuk tujuan yang sangat berbeda dari yang dibahas
sebelumnya, dan mereka memiliki penampilan yang sangat berbeda (lihat
Gambar 1-6).

Metodologi berbasis prototyping buang memiliki fase analisis yang relatif

menyeluruh yang digunakan untuk mengumpulkan informasi dan
mengembangkan ide untuk konsep sistem. Namun, pengguna mungkin tidak
sepenuhnya memahami banyak fitur yang mereka sarankan, dan mungkin
ada isu teknis yang menantang untuk diselesaikan. Setiap isu ini diperiksa
dengan menganalisis, merancang, dan membangun prototipe desain.
Prototipe desain bukanlah sistem yang bekerja; itu adalah produk yang
mewakili bagian dari sistem yang membutuhkan penyempurnaan tambahan,
dan itu hanya berisi detail yang cukup untuk memungkinkan pengguna
memahami isu yang dipertimbangkan. Misalnya, anggaplah pengguna tidak
sepenuhnya jelas tentang bagaimana sistem entri pesanan harus bekerja.
Dalam hal ini, serangkaian layar tiruan tampak seperti sistem, tetapi
sebenarnya tidak melakukan apa-apa. Atau anggaplah tim proyek perlu
mengembangkan program grafik yang canggih dalam Java. Tim bisa menulis
bagian dari program dengan data pura-pura untuk memastikan bahwa
mereka bisa melakukan program lengkap dengan sukses.

Sebuah sistem yang dikembangkan menggunakan jenis metodologi ini

bergantung pada beberapa prototipe desain selama fase analisis dan desain.
Setiap prototipe digunakan untuk meminimalkan risiko yang terkait dengan
sistem dengan mengonfirmasi bahwa isu penting dipahami sebelum sistem
nyata dibangun. Setelah isu diselesaikan, proyek bergerak ke desain dan
implementasi. Pada titik ini, prototipe desain dibuang, yang merupakan
perbedaan penting antara metodologi ini dan metodologi prototyping, di
mana prototipe berevolusi menjadi sistem akhir.

Metodologi berbasis prototyping buang menyeimbangkan manfaat dari fase

analisis dan desain yang dipikirkan dengan baik dengan keuntungan
menggunakan prototipe untuk menyempurnakan isu kunci sebelum sistem
dibangun. Ini bisa memakan waktu lebih lama untuk menyampaikan sistem
akhir dibandingkan dengan metodologi berbasis prototyping, tetapi jenis
metodologi ini biasanya menghasilkan sistem yang lebih stabil dan andal.

Pengembangan Agile⁵
Kategori ketiga dari metodologi pengembangan sistem masih muncul hari
ini: pengembangan agile. Semua metodologi pengembangan agile
didasarkan pada manifesto agile dan satu set dua belas prinsip. Penekanan
manifesto adalah untuk memfokuskan pengembang pada kondisi kerja
pengembang, perangkat lunak yang bekerja, pelanggan, dan menangani
persyaratan yang berubah alih-alih memfokuskan pada proses sistem yang
rinci, alat, dokumentasi sistem lengkap, kontrak hukum, dan rencana rinci.
Metodologi yang berpusat pada pemrograman ini memiliki sedikit aturan dan
praktik, yang semuanya cukup mudah diikuti. Metodologi ini biasanya hanya
didasarkan pada dua belas prinsip perangkat lunak agile. Prinsip-prinsip ini
mencakup yang berikut:

 Perangkat lunak diserahkan lebih awal dan terus-menerus melalui

proses pengembangan, memuaskan pelanggan.

 Persyaratan yang berubah diterima terlepas dari kapan mereka terjadi

dalam proses pengembangan.

 Perangkat lunak yang bekerja diserahkan sering kepada pelanggan.

 Pelanggan dan pengembang bekerja bersama untuk memecahkan

masalah bisnis.

 Individu yang termotivasi menciptakan solusi; berikan mereka alat dan

lingkungan yang dibutuhkan, dan percayai mereka untuk
menyampaikan.

 Komunikasi tatap muka dalam tim pengembangan adalah metode

paling efisien dan efektif untuk mengumpulkan persyaratan.

 Ukuran kemajuan utama adalah perangkat lunak yang bekerja dan

berjalan.

 Baik pelanggan maupun pengembang harus bekerja pada kecepatan

yang berkelanjutan. Artinya, tingkat kerja bisa dipertahankan tanpa
batas waktu tanpa kelelahan pekerja.

 Kesederhanaan, penghindaran kerja yang tidak perlu, adalah esensial.

 Tim yang mengorganisir diri sendiri mengembangkan arsitektur,

persyaratan, dan desain terbaik.

 Tim pengembangan secara teratur merefleksikan bagaimana

meningkatkan proses pengembangan mereka.
Berdasarkan prinsip-prinsip ini, metodologi agile fokus pada
menyederhanakan proses pengembangan sistem dengan menghilangkan
banyak overhead pemodelan dan dokumentasi serta waktu yang dihabiskan
untuk tugas-tugas tersebut. Sebaliknya, proyek menekankan pengembangan
aplikasi sederhana, berulang.⁶ Semua metodologi pengembangan agile
mengikuti siklus sederhana melalui fase tradisional proses pengembangan
sistem (lihat Gambar 1-7). Hampir semua metodologi agile digunakan
bersamaan dengan teknologi berorientasi objek.

⁵ Tiga sumber informasi yang baik tentang pengembangan agile dan sistem
berorientasi objek adalah S. W. Ambler, Agile Modeling: Effective Practices
for Extreme Programming and the Unified Process (New York: Wiley, 2002);
C. Larman, Agile & Iterative Development: A Manager's Guide (Boston:
Addison-Wesley, 2004); R. C. Martin, Agile Software Development: Principles,
Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003).

⁶ Lihat Agile Alliance, [Link].

Namun, metodologi agile memang memiliki kritikus. Salah satu kritik utama
berkaitan dengan lingkungan bisnis hari ini, di mana banyak pengembangan
sistem informasi sebenarnya dioutsourcing, di-offshore, dan/atau
disubkontrak. Mengingat metodologi pengembangan agile yang memerlukan
co-location dari tim pengembangan, ini tampaknya merupakan asumsi yang
sangat tidak realistis. Kritik utama kedua adalah bahwa jika pengembangan
agile tidak dikelola dengan hati-hati, dan menurut definisi itu tidak, proses
pengembangan bisa berubah menjadi pendekatan prototyping yang pada
dasarnya menjadi lingkungan "programmer hilang kendali" di mana
programmer mencoba meretas solusi bersama. Kritik utama ketiga,
berdasarkan kurangnya dokumentasi aktual yang dibuat selama
pengembangan perangkat lunak, menimbulkan isu mengenai auditabilitas
sistem yang dibuat. Tanpa dokumentasi yang cukup, baik sistem maupun
proses pengembangan sistem tidak dapat dijamin. Kritik utama keempat
didasarkan pada apakah pendekatan agile dapat menyampaikan sistem misi-
kritis yang besar.

Meskipun dengan kritik ini, mengingat potensi pendekatan agile untuk

mengatasi backlog aplikasi dan memberikan solusi tepat waktu untuk
banyak masalah bisnis, pendekatan agile harus dipertimbangkan dalam
beberapa keadaan. Selain itu, banyak ide dan teknik yang didorong dengan
memperhatikan tujuan mendasar manifesto agile dan satu set dua belas
prinsip agile sangat berguna dalam pengembangan sistem berorientasi
objek. Dua contoh yang lebih populer dari metodologi pengembangan agile
adalah pemrograman ekstrem (XP) dan Scrum.

Pemrograman Ekstrem7 Pemrograman ekstrem (XP) didasarkan pada

empat nilai inti: komunikasi, kesederhanaan, umpan balik, dan keberanian.
Empat nilai ini memberikan fondasi yang digunakan pengembang XP untuk
menciptakan sistem apa pun. Pertama, pengembang harus memberikan
umpan balik cepat kepada pengguna akhir secara berkelanjutan. Kedua, XP
mengharuskan pengembang untuk mengikuti prinsip KISS. 8 Ketiga,
pengembang harus membuat perubahan bertahap untuk menumbuhkan
sistem, dan mereka tidak hanya menerima perubahan, mereka merangkul
perubahan. Keempat, pengembang harus memiliki mentalitas kualitas-
pertama. XP juga mendukung anggota tim dalam mengembangkan
keterampilan mereka sendiri. Tiga prinsip kunci yang digunakan XP untuk
menciptakan sistem yang sukses adalah pengujian berkelanjutan,
pengkodean sederhana yang dilakukan oleh pasangan pengembang, dan
interaksi dekat dengan pengguna akhir untuk membangun sistem dengan
sangat cepat.

Pengujian dan praktik pengkodean efisien adalah inti dari XP. Kode diuji
setiap hari dan ditempatkan ke dalam lingkungan pengujian integratif. Jika
bug ada, kode dicadangkan hingga benar-benar bebas dari kesalahan.

Proyek XP dimulai dengan cerita pengguna yang menjelaskan apa yang perlu
dilakukan sistem. Kemudian, programmer mengkode dalam modul kecil dan
sederhana dan menguji untuk memenuhi kebutuhan tersebut. Pengguna
diwajibkan untuk tersedia untuk membersihkan pertanyaan dan isu saat
mereka muncul. Standar sangat penting untuk meminimalkan kebingungan,
jadi tim XP menggunakan set umum nama, deskripsi, dan praktik
pengkodean. Proyek XP memberikan hasil lebih cepat daripada bahkan
pendekatan RAD, dan mereka jarang terjebak dalam pengumpulan
persyaratan untuk sistem.

Pendukung XP mengklaim banyak kekuatan yang terkait dengan

pengembangan perangkat lunak menggunakan XP. Programmer bekerja erat
dengan semua pemangku kepentingan, dan komunikasi di antara semua
pemangku kepentingan ditingkatkan. Pengujian berkelanjutan dari sistem
yang berevolusi didorong. Sistem dikembangkan secara evolusi dan
bertahap, yang memungkinkan persyaratan berevolusi saat pemangku
kepentingan memahami potensi yang dimiliki teknologi dalam memberikan
solusi untuk masalah mereka. Estimasi didorong oleh tugas dan dilakukan
oleh programmer yang akan menerapkan solusi untuk tugas yang sedang
dipertimbangkan. Karena semua pemrograman dilakukan secara
berpasangan, tanggung jawab bersama untuk setiap komponen perangkat
lunak berkembang di antara para programmer. Akhirnya, kualitas produk
akhir meningkat selama setiap iterasi.

Untuk proyek kecil dengan tim yang sangat termotivasi, kohesif, stabil, dan
berpengalaman, XP harus bekerja dengan baik. Namun, jika proyek bukan
kecil atau tim tidak jelled, kesuksesan upaya pengembangan XP diragukan.
Ini cenderung mempertanyakan seluruh ide membawa kontraktor luar ke
dalam lingkungan tim yang ada menggunakan XP.10 Kemungkinan orang luar
jelling dengan orang dalam mungkin terlalu optimis. XP memerlukan banyak
disiplin, jika tidak proyek akan menjadi tidak fokus dan kacau. XP
direkomendasikan hanya untuk kelompok kecil pengembang—tidak lebih dari
sepuluh pengembang—dan tidak disarankan untuk aplikasi misi-kritis yang
besar. Karena kurangnya analisis dan dokumentasi desain, hanya ada
dokumentasi kode yang terkait dengan XP, jadi memelihara sistem besar
yang dibangun dengan XP mungkin tidak mungkin. Dan karena sistem
informasi bisnis misi-kritis cenderung ada untuk waktu yang lama, utilitas XP
sebagai metodologi pengembangan sistem informasi bisnis diragukan.
Akhirnya, metodologi memerlukan banyak masukan pengguna di tempat,
sesuatu yang tidak dapat dilakukan oleh banyak unit bisnis. 11 Namun,
beberapa teknik yang terkait dengan XP berguna dalam pengembangan
sistem berorientasi objek. Misalnya, cerita pengguna, pemrograman
berpasangan, dan pengujian berkelanjutan adalah alat yang tak ternilai dari
mana pengembangan berorientasi objek bisa mendapat manfaat.

Scrum12 Scrum adalah istilah yang dikenal baik oleh penggemar rugby.
Dalam rugby, scrum digunakan untuk memulai ulang permainan. Secara
singkat, pencipta metode Scrum percaya bahwa tidak peduli seberapa
banyak Anda merencanakan, segera setelah perangkat lunak mulai
dikembangkan, kekacauan pecah dan
7
Untuk informasi lebih lanjut, lihat K. Beck, eXtreme Programming
Explained: Embrace Change (Reading, MA: Addison-Wesley, 2000); C.
Larman, Agile & Iterative Development: A Manager's Guide (Boston: Addison-
Wesley, 2004); M. Lippert, S. Roock, dan H. Wolf, eXtreme Programming in
Action: Practical Experiences from Real World Projects (New York: Wiley,
2002); [Link].
8
Keep it simple, stupid.
9
Tim yang jelled adalah tim yang memiliki turnover rendah, rasa identitas
yang kuat, rasa elit, perasaan bahwa mereka bersama-sama memiliki produk
yang dikembangkan, dan kesenangan dalam bekerja bersama. Untuk
informasi lebih lanjut mengenai tim jelled, lihat T. DeMarco dan T. Lister,
Peopleware: Productive Projects and Teams (New York: Dorset/House, 1987).
10
Mempertimbangkan kecenderungan outsourcing offshore, ini adalah
hambatan utama bagi XP untuk diatasi. Untuk informasi lebih lanjut tentang
outsourcing offshore, lihat P. Thibodeau, “TIAA Panel Debates Outsourcing
Pros, Cons,” Computerworld Morning Update (25 September 2003); S. W.
Ambler, “Chicken Little Was Right,” Software Development (Oktober 2003). 11
Banyak pengamatan tentang utilitas XP sebagai pendekatan pengembangan
didasarkan pada percakapan dengan Brian Henderson-Sellers. 12 Untuk
informasi lebih lanjut, lihat C. Larman, Agile & Iterative Development: A
Manager’s Guide (Boston: Addison-Wesley, 2004); K. Schwaber dan M.
Beedle, Agile Software Development with Scrum (Upper Saddle River, NJ:
Prentice Hall, 2001); R. Wysocki, Effective Project Management: Traditional,
Agile, Extreme, edisi ke-5 (Indianapolis, IN: Wiley Publishing, 2009).

rencana keluar dari jendela.13 Yang terbaik yang bisa Anda lakukan adalah
bereaksi ke mana bola rugby yang pepatah menyemprot keluar. Anda
kemudian berlari dengan bola hingga scrum berikutnya. Dalam kasus
metodologi Scrum, sprint berlangsung tiga puluh hari kerja. Pada akhir
sprint, sistem diserahkan kepada pelanggan.

Dari semua pendekatan pengembangan sistem, di permukaan, Scrum adalah

yang paling kacau. Untuk mengendalikan sebagian kekacauan bawaan,
pengembangan Scrum fokus pada beberapa praktik utama. Tim
mengorganisir diri sendiri dan diarahkan sendiri. Tidak seperti pendekatan
lain, tim Scrum tidak memiliki pemimpin tim yang ditunjuk. Sebaliknya, tim
mengorganisir diri mereka secara simbiotik dan menetapkan tujuan mereka
sendiri untuk setiap sprint (iterasi). Setelah sprint dimulai, tim tidak
mempertimbangkan persyaratan tambahan apa pun. Persyaratan baru apa
pun yang ditemukan ditempatkan pada backlog persyaratan yang masih
perlu diatasi. Pada awal setiap hari kerja, pertemuan Scrum berlangsung.
Pada akhir setiap sprint, tim mendemonstrasikan perangkat lunak kepada
klien. Berdasarkan hasil sprint, rencana baru dimulai untuk sprint berikutnya.

Pertemuan Scrum adalah salah satu aspek paling menarik dari proses
pengembangan Scrum. Anggota tim menghadiri pertemuan, tetapi siapa pun
bisa hadir. Namun, dengan sangat sedikit pengecualian, hanya anggota tim
yang boleh berbicara. Satu pengecualian penting adalah manajemen
memberikan umpan balik tentang relevansi bisnis dari pekerjaan yang
dilakukan oleh tim spesifik. Dalam pertemuan ini, semua anggota tim berdiri
dalam lingkaran dan melaporkan apa yang mereka capai selama hari
sebelumnya, menyatakan apa yang mereka rencanakan untuk dilakukan hari
ini, dan menjelaskan apa pun yang menghalangi kemajuan hari sebelumnya.
Untuk memungkinkan kemajuan berkelanjutan, setiap blok yang
diidentifikasi diatasi dalam satu jam. Dari perspektif Scrum, lebih baik
membuat keputusan "buruk" tentang blok pada titik ini dalam
pengembangan daripada tidak membuat keputusan. Karena pertemuan
berlangsung setiap hari, keputusan buruk bisa dengan mudah dibatalkan.
Larman14 menyarankan bahwa setiap anggota tim harus melaporkan
persyaratan tambahan apa pun yang telah ditemukan selama sprint dan apa
pun yang dipelajari anggota tim yang bisa berguna bagi anggota tim lain.

Salah satu kritik utama dari Scrum, seperti semua metodologi agile, adalah
bahwa diragukan apakah Scrum dapat ditingkatkan untuk mengembangkan
sistem misi-kritis yang sangat besar. Ukuran tim Scrum tipikal tidak lebih dari
tujuh anggota. Prinsip pengorganisasian satu-satunya yang diajukan oleh
pengikut Scrum untuk mengatasi kritik ini adalah mengorganisir scrum dari
scrum. Setiap tim bertemu setiap hari, dan setelah pertemuan tim
berlangsung, seorang perwakilan (bukan pemimpin) dari setiap tim
menghadiri pertemuan scrum-dari-scrum. Ini berlanjut hingga kemajuan
seluruh sistem telah ditentukan. Tergantung pada jumlah tim yang terlibat,
pendekatan ini untuk mengelola proyek besar diragukan. Namun, seperti di
XP dan pendekatan pengembangan agile lainnya, banyak ide dan teknik
yang terkait dengan pengembangan Scrum berguna dalam pengembangan
sistem berorientasi objek, seperti fokus pertemuan Scrum, pendekatan
evolusi dan bertahap untuk mengidentifikasi persyaratan, dan pendekatan
bertahap dan berulang untuk pengembangan sistem.

Memilih Metodologi Pengembangan yang Tepat

Karena ada banyak metodologi, tantangan pertama yang dihadapi oleh

analis adalah memilih metodologi mana yang akan digunakan. Memilih
metodologi tidak sederhana, karena tidak ada satu metodologi yang selalu
terbaik. (Jika ada, kita cukup menggunakannya di mana-mana!) Banyak
organisasi memiliki standar dan kebijakan untuk memandu pilihan
metodologi. Anda akan menemukan bahwa organisasi berkisar dari memiliki
satu metodologi "disetujui" hingga memiliki beberapa pilihan metodologi
hingga tidak memiliki kebijakan formal sama sekali.
Gambar 1-8 merangkum beberapa kriteria penting untuk memilih
metodologi. Satu item penting yang tidak dibahas dalam gambar ini adalah
tingkat pengalaman tim analis. Banyak metodologi berbasis RAD
memerlukan penggunaan alat dan teknik baru yang memiliki kurva
pembelajaran yang signifikan. Seringkali alat dan teknik ini meningkatkan
kompleksitas proyek dan memerlukan waktu ekstra untuk pembelajaran.
Namun, setelah diadopsi dan tim menjadi berpengalaman, alat dan teknik
bisa secara signifikan meningkatkan kecepatan di mana metodologi bisa
menyampaikan sistem akhir.

Kejelasan Persyaratan Pengguna Ketika persyaratan pengguna untuk

sistem tidak jelas, sulit untuk memahaminya dengan membicarakannya dan
menjelaskannya dengan laporan tertulis. Pengguna biasanya perlu
berinteraksi dengan teknologi untuk benar-benar memahami apa yang bisa
dilakukan sistem baru dan bagaimana menerapkannya terbaik untuk
kebutuhan mereka. Metodologi RAD dan agile biasanya lebih tepat ketika
persyaratan pengguna tidak jelas.

Keakraban dengan Teknologi Ketika sistem akan menggunakan teknologi

baru yang tidak familiar bagi analis dan programmer, aplikasi awal teknologi
baru dalam metodologi akan meningkatkan peluang kesuksesan. Jika sistem
dirancang tanpa beberapa keakraban dengan teknologi dasar, risiko
meningkat karena alat mungkin tidak mampu melakukan apa yang
dibutuhkan. Metodologi berbasis prototyping buang sangat tepat jika
pengguna kurang familiar dengan teknologi karena mereka secara eksplisit
mendorong pengembang untuk mengembangkan prototipe desain untuk
area dengan risiko tinggi. Metodologi berbasis pengembangan bertahap
menciptakan peluang untuk menyelidiki teknologi dalam kedalaman tertentu
sebelum desain selesai. Juga, karena sifat berpusat pada pemrograman
metodologi agile, baik XP maupun Scrum tepat. Meskipun Anda mungkin
berpikir metodologi berbasis prototyping juga tepat, mereka jauh kurang
demikian karena prototipe awal yang dibangun biasanya hanya menggores
permukaan teknologi baru. Umumnya hanya setelah beberapa prototipe dan
beberapa bulan pengembang menemukan kelemahan atau masalah dalam
teknologi baru.

Kompleksitas Sistem Sistem kompleks memerlukan analisis dan desain

yang hati-hati dan rinci. Metodologi berbasis prototyping buang sangat cocok
untuk analisis dan desain rinci seperti itu, tetapi metodologi berbasis
prototyping tidak. Terstruktur
desain-berbasis metodologi bisa menangani sistem kompleks, tapi tanpa
kemampuan untuk mendapatkan sistem atau prototipe ke tangan pengguna
lebih awal, beberapa isu kunci mungkin diabaikan. Meskipun metodologi
berbasis pengembangan bertahap memungkinkan pengguna untuk
berinteraksi dengan sistem lebih awal dalam proses, kami telah mengamati
bahwa tim proyek yang mengikuti ini cenderung mencurahkan lebih sedikit
perhatian untuk analisis domain masalah lengkap daripada yang mereka
lakukan menggunakan metodologi lain. Akhirnya, metodologi agile adalah
tas campur ketika datang ke kompleksitas sistem. Jika sistem akan menjadi
besar, metodologi agile akan berkinerja buruk. Namun, jika sistem berukuran
kecil hingga sedang, maka pendekatan agile akan sangat baik. Kami menilai
mereka baik pada kriteria ini.

Keandalan Sistem Keandalan sistem biasanya merupakan faktor penting

dalam pengembangan sistem; lagipula, siapa yang ingin sistem yang tidak
andal? Namun, keandalan hanyalah satu faktor di antara beberapa faktor.
Untuk beberapa aplikasi, keandalan benar-benar kritis (misalnya, peralatan
medis, sistem pengendalian rudal), sedangkan untuk aplikasi lain (misalnya,
permainan, video Internet) itu hanya penting. Karena metodologi prototyping
buang menggabungkan fase analisis dan desain rinci dengan kemampuan
tim proyek untuk menguji banyak pendekatan berbeda melalui prototipe
desain sebelum menyelesaikan desain, mereka tepat ketika keandalan
sistem adalah prioritas tinggi. Metodologi prototyping umumnya bukan
pilihan yang baik ketika keandalan kritis karena kurangnya fase analisis dan
desain yang hati-hati yang esensial untuk sistem yang dapat diandalkan.
Namun, karena fokus berat pada pengujian, identifikasi persyaratan evolusi
dan bertahap, dan pengembangan bertahap dan berulang, metode agile
mungkin merupakan pendekatan terbaik secara keseluruhan.

Jadwal Waktu Pendek Metodologi berbasis RAD dan agile adalah pilihan
yang sangat baik ketika jadwal waktu pendek karena mereka paling
memungkinkan tim proyek untuk menyesuaikan fungsionalitas dalam sistem
berdasarkan tanggal pengiriman spesifik, dan jika jadwal proyek mulai
tergelincir, itu bisa disesuaikan dengan menghapus fungsionalitas dari versi
atau prototipe yang sedang dikembangkan. Metodologi berbasis air terjun
adalah pilihan terburuk ketika waktu adalah premium karena mereka tidak
memungkinkan perubahan jadwal yang mudah.

Visibilitas Jadwal Salah satu tantangan terbesar dalam pengembangan

sistem adalah menentukan apakah sebuah proyek tepat waktu. Ini sangat
benar untuk metodologi desain terstruktur karena desain dan implementasi
terjadi di akhir proyek. Metodologi berbasis RAD memindahkan banyak
keputusan desain kritis lebih awal dalam proyek untuk membantu manajer
proyek mengenali dan mengatasi faktor risiko dan menjaga harapan tetap
terkendali. Namun, mengingat pertemuan kemajuan harian yang terkait
dengan pendekatan Agile, visibilitas jadwal selalu berada di atas kompor
pepatah.

PERAN DAN KETERAMPILAN ANALIS SISTEM TIPIKAL

Jelas dari berbagai fase dan langkah yang dilakukan selama SDLC bahwa tim
proyek membutuhkan berbagai keterampilan. Anggota proyek adalah agen
perubahan yang mengidentifikasi cara untuk meningkatkan organisasi,
membangun sistem informasi untuk mendukung mereka, dan melatih serta
memotivasi orang lain untuk menggunakan sistem. Memahami apa yang
harus diubah dan bagaimana mengubahnya—dan meyakinkan orang lain
tentang kebutuhan akan perubahan—memerlukan berbagai keterampilan.
Keterampilan ini dapat dibagi menjadi enam kategori utama: teknis, bisnis,
analitis, interpersonal, manajemen, dan etis.

Analis harus memiliki keterampilan teknis untuk memahami lingkungan

teknis organisasi yang ada, teknologi yang akan membentuk sistem baru,
dan cara keduanya bisa cocok ke dalam solusi teknis terintegrasi.
Keterampilan bisnis diperlukan untuk memahami bagaimana IT dapat
diterapkan pada situasi bisnis dan untuk memastikan bahwa IT memberikan
nilai bisnis nyata. Analis adalah pemecah masalah berkelanjutan baik pada
tingkat proyek maupun organisasi, dan mereka menguji keterampilan analitis
mereka secara teratur.

Analis sering perlu berkomunikasi secara efektif satu lawan satu dengan
pengguna dan manajer bisnis (yang sering memiliki sedikit pengalaman
dengan teknologi) dan dengan programmer (yang sering memiliki keahlian
teknis lebih dari analis). Mereka harus mampu memberikan presentasi
kepada kelompok besar dan kecil serta menulis laporan. Tidak hanya mereka
perlu memiliki kemampuan interpersonal yang kuat, tetapi mereka juga perlu
mengelola orang yang bekerja dengan mereka dan mereka perlu mengelola
tekanan dan risiko yang terkait dengan situasi yang tidak jelas.

Akhirnya, analis harus berurusan secara adil, jujur, dan etis dengan anggota
tim proyek lainnya, manajer, dan pengguna sistem. Analis sering berurusan
dengan informasi rahasia atau informasi yang, jika dibagikan dengan orang
lain, bisa menyebabkan kerugian (misalnya, perselisihan di antara
karyawan); penting untuk mempertahankan kepercayaan dan kepercayaan
dengan semua orang.

Selain enam set keterampilan umum ini, analis memerlukan banyak

keterampilan spesifik yang terkait dengan peran yang dilakukan pada
sebuah proyek. Pada hari-hari awal pengembangan sistem, sebagian besar
organisasi mengharapkan satu orang, analis, untuk memiliki semua
keterampilan spesifik yang diperlukan untuk melakukan proyek
pengembangan sistem. Beberapa organisasi kecil masih mengharapkan satu
orang untuk melakukan banyak peran, tetapi karena organisasi dan teknologi
telah menjadi lebih kompleks, sebagian besar organisasi besar sekarang
membangun tim proyek yang berisi beberapa individu dengan tanggung
jawab yang didefinisikan dengan jelas. Organisasi yang berbeda membagi
peran secara berbeda. Sebagian besar tim IS mencakup banyak individu lain,
seperti programmer, yang sebenarnya menulis program yang membentuk
sistem, dan penulis teknis, yang menyiapkan layar bantuan dan dokumentasi
lain (misalnya, manual pengguna dan manual sistem).

Analis Bisnis Seorang analis bisnis fokus pada isu bisnis seputar sistem. Isu-
isu ini mencakup mengidentifikasi nilai bisnis yang akan diciptakan oleh
sistem, mengembangkan ide dan saran untuk bagaimana proses bisnis dapat
ditingkatkan, dan merancang proses dan kebijakan baru bersamaan dengan
analis sistem. Individu ini kemungkinan besar memiliki pengalaman bisnis
dan beberapa jenis pelatihan profesional. Dia mewakili kepentingan sponsor
proyek dan pengguna akhir dari sistem. Seorang analis bisnis membantu
dalam fase perencanaan dan desain tetapi paling aktif dalam fase analisis.

Analis Sistem Seorang analis sistem fokus pada isu IS seputar sistem.
Orang ini mengembangkan ide dan saran untuk bagaimana teknologi
informasi dapat meningkatkan proses bisnis, merancang proses bisnis baru
dengan bantuan dari analis bisnis, merancang sistem informasi baru, dan
memastikan bahwa semua standar IS dipertahankan. Seorang analis sistem
kemungkinan besar memiliki pelatihan dan pengalaman signifikan dalam
analisis dan desain, pemrograman, dan bahkan area bisnis. Dia mewakili
kepentingan departemen IS dan bekerja secara intensif melalui proyek tetapi
mungkin kurang selama fase implementasi.

Analis Infrastruktur Seorang analis infrastruktur fokus pada isu teknis

seputar bagaimana sistem akan berinteraksi dengan infrastruktur teknis
organisasi (misalnya, perangkat keras, perangkat lunak, jaringan, dan basis
data). Tugas analis infrastruktur mencakup memastikan bahwa sistem
informasi baru sesuai dengan standar organisasi dan mengidentifikasi
perubahan infrastruktur yang diperlukan untuk mendukung sistem. Individu
ini mungkin memiliki pelatihan dan pengalaman signifikan dalam

jaringan, administrasi basis data, dan berbagai produk perangkat keras dan
perangkat lunak. Dia mewakili kepentingan organisasi dan kelompok IS yang
akhirnya harus mengoperasikan dan mendukung sistem baru setelah
diinstal. Seorang analis infrastruktur bekerja sepanjang proyek tetapi
mungkin kurang selama fase perencanaan dan analisis.

Analis Manajemen Perubahan Seorang analis manajemen perubahan

fokus pada isu orang dan manajemen seputar instalasi sistem. Peran orang
ini mencakup memastikan bahwa dokumentasi dan dukungan yang memadai
tersedia bagi pengguna, memberikan pelatihan pengguna pada sistem baru,
dan mengembangkan strategi untuk mengatasi resistensi terhadap
perubahan. Individu ini harus memiliki pelatihan dan pengalaman signifikan
dalam perilaku organisasi secara umum dan manajemen perubahan secara
khusus. Dia mewakili kepentingan sponsor proyek dan pengguna yang
untuknya sistem dirancang. Seorang analis manajemen perubahan bekerja
paling aktif selama fase implementasi tetapi mulai meletakkan dasar untuk
perubahan selama fase analisis dan desain.

Manajer Proyek Seorang manajer proyek bertanggung jawab untuk

memastikan bahwa proyek selesai tepat waktu dan dalam anggaran dan
bahwa sistem memberikan semua manfaat yang dimaksudkan oleh sponsor
proyek. Peran manajer proyek mencakup mengelola anggota tim,
mengembangkan rencana proyek, menugaskan sumber daya, dan menjadi
titik kontak utama ketika orang di luar tim memiliki pertanyaan tentang
proyek. Individu ini kemungkinan besar memiliki pengalaman signifikan
dalam manajemen proyek dan mungkin telah bekerja selama bertahun-tahun
sebagai analis sistem sebelumnya. Dia mewakili kepentingan departemen IS
dan sponsor proyek. Manajer proyek bekerja secara intensif selama semua
fase proyek.

KARAKTERISTIK DASAR SISTEM BERORIENTASI OBJEK

Sistem berorientasi objek fokus pada menangkap struktur dan perilaku

sistem informasi dalam modul kecil yang mencakup baik data maupun
proses. Modul kecil ini dikenal sebagai objek. Dalam bagian ini, kami
menjelaskan karakteristik dasar sistem berorientasi objek, yang mencakup
kelas, objek, metode, pesan, enkapsulasi, penyembunyian informasi,
pewarisan, polimorfisme, dan pengikatan dinamis. 15
Kelas dan Objek Sebuah kelas adalah templat umum yang kami gunakan
untuk mendefinisikan dan menciptakan instance spesifik, atau objek. Setiap
objek terkait dengan kelas. Misalnya, semua objek yang menangkap
informasi tentang pasien bisa jatuh ke dalam kelas yang disebut Pasien,
karena ada atribut (misalnya, nama, alamat, tanggal lahir, telepon, dan
perusahaan asuransi) dan metode (misalnya, buat janji, hitung kunjungan
terakhir, ubah status, dan berikan riwayat medis) yang dibagikan oleh semua
pasien (lihat Gambar 1-9).

Sebuah objek adalah instansiasi dari kelas. Dengan kata lain, objek adalah
orang, tempat, atau hal tentang yang kami ingin tangkap informasi. Jika kami
membangun sistem janji untuk kantor dokter, kelas mungkin mencakup
Dokter, Pasien, dan Janji. Pasien spesifik, seperti Jim Maloney, Mary Wilson,
dan Theresa Marks, dianggap sebagai instance, atau objek, dari kelas pasien
(lihat Gambar 1-9).

Setiap objek memiliki atribut yang menjelaskan informasi tentang objek,

seperti nama pasien, tanggal lahir, alamat, dan nomor telepon. Atribut juga
digunakan untuk mewakili hubungan antara objek; misalnya, bisa ada atribut
departemen dalam objek karyawan dengan nilai objek departemen yang
menangkap di departemen mana objek karyawan bekerja. Keadaan objek
didefinisikan oleh nilai atributnya dan hubungannya dengan objek lain pada
titik waktu tertentu. Misalnya, pasien mungkin memiliki keadaan baru atau
saat ini atau mantan.

Setiap objek juga memiliki perilaku. Perilaku menentukan apa yang bisa
dilakukan objek. Misalnya, objek janji mungkin bisa menjadwalkan janji baru,
menghapus janji, dan menemukan janji berikutnya yang tersedia. Dalam
pemrograman berorientasi objek, perilaku diterapkan sebagai metode (lihat
bagian berikutnya).

Salah satu aspek yang lebih membingungkan dari pengembangan sistem

berorientasi objek adalah fakta bahwa dalam kebanyakan bahasa
pemrograman berorientasi objek, baik kelas maupun instance kelas bisa
memiliki atribut dan metode. Atribut dan metode kelas cenderung digunakan
untuk memodelkan atribut (atau metode) yang berurusan dengan isu terkait
semua instance kelas. Misalnya, untuk membuat objek pasien baru, pesan
dikirim ke kelas Pasien untuk membuat instance baru dari dirinya sendiri.
Namun, dalam buku ini, kami fokus terutama pada atribut dan metode objek
dan bukan kelas.
Metode dan Pesan Metode menerapkan perilaku objek. Sebuah metode
tidak lebih dari aksi yang bisa dilakukan objek. Pesan adalah informasi yang
dikirim ke objek untuk memicu metode. Sebuah pesan pada dasarnya adalah
panggilan fungsi atau prosedur dari satu objek ke objek lain. Misalnya, jika
pasien baru ke kantor dokter, resepsionis mengirim pesan buat ke aplikasi.
Kelas pasien menerima pesan buat dan menjalankan metode buat() yang
kemudian menciptakan objek baru: aPasien (lihat Gambar 1-10).

Enkapsulasi dan Penyembunyian Informasi Ide enkapsulasi dan

penyembunyian informasi saling terkait dalam sistem berorientasi objek.
Namun, tidak ada istilah yang baru. Enkapsulasi hanyalah kombinasi proses
dan data ke dalam entitas tunggal. Penyembunyian informasi pertama kali
dipromosikan dalam pengembangan sistem terstruktur. Prinsip
penyembunyian informasi menyarankan bahwa hanya informasi yang
diperlukan untuk menggunakan modul perangkat lunak yang dipublikasikan
kepada pengguna modul. Biasanya, ini berarti bahwa informasi yang
diperlukan untuk diteruskan ke modul dan informasi yang dikembalikan dari
modul dipublikasikan. Tepat bagaimana modul menerapkan fungsionalitas
yang diperlukan tidak relevan. Kami benar-benar tidak peduli bagaimana
objek melakukan fungsinya, selama fungsi terjadi. Dalam sistem berorientasi
objek, menggabungkan enkapsulasi dengan prinsip penyembunyian
informasi mendukung memperlakukan objek sebagai kotak hitam.

Fakta bahwa kami dapat menggunakan objek dengan memanggil metode

adalah kunci untuk reusabilitas karena melindungi kerja internal objek dari
perubahan dalam sistem luar, dan itu menjaga sistem dari terpengaruh
ketika perubahan dibuat pada objek. Dalam Gambar 1-10, perhatikan
bagaimana pesan (buat) dikirim ke objek, namun algoritma internal yang
diperlukan untuk merespons pesan disembunyikan dari bagian lain sistem.
Satu-satunya informasi yang perlu diketahui objek adalah set operasi, atau
metode, yang bisa dilakukan objek lain dan pesan apa yang perlu dikirim
untuk memicunya.

Pewarisan, sebagai karakteristik pengembangan sistem informasi, diusulkan

dalam pemodelan data pada akhir 1970-an dan awal 1980-an. Literatur
pemodelan data menyarankan menggunakan pewarisan untuk
mengidentifikasi kelas objek tingkat lebih tinggi, atau lebih umum. Set umum
atribut dan metode bisa diorganisir ke dalam superkelas. Biasanya, kelas
diatur dalam hierarki di mana superkelas, atau kelas umum, berada di atas
dan subkelas, atau kelas spesifik, berada di bawah. Dalam Gambar 1-11,
Person adalah superkelas untuk kelas Doctor dan Patient. Doctor, pada
gilirannya, adalah superkelas untuk General Practitioner dan Specialist.
Perhatikan bagaimana kelas (misalnya, Doctor) bisa berfungsi sebagai
superkelas dan subkelas secara bersamaan. Hubungan antara kelas dan
superkelasnya dikenal sebagai hubungan a-kind-of. Misalnya dalam Gambar
1-11, General Practitioner adalah a-kind-of Doctor, yang adalah a-kind-of
Person.

Subkelas mewarisi atribut dan metode yang sesuai dari superkelas di

atasnya. Artinya, setiap subkelas berisi atribut dan metode dari superkelas
induknya. Misalnya, Gambar 1-11 menunjukkan bahwa baik Doctor maupun
Patient adalah subkelas dari Person dan karena itu mewarisi atribut dan
metode kelas Person. Pewarisan membuat lebih sederhana untuk
mendefinisikan kelas. Alih-alih mengulang atribut dan metode di kelas Doctor
dan Patient secara terpisah, atribut dan metode yang umum untuk keduanya
ditempatkan di kelas Person dan diwarisi oleh kelas di bawahnya. Perhatikan
betapa lebih efisien hierarki pewarisan kelas objek daripada objek yang
sama tanpa hierarki pewarisan (lihat Gambar 1-12).

Sebagian besar kelas sepanjang hierarki mengarah ke instance; kelas apa

pun yang memiliki instance disebut kelas konkret. Misalnya, jika Mary Wilson
dan Jim Maloney adalah instance dari kelas Patient, Patient akan dianggap
sebagai kelas konkret (lihat Gambar 1-9). Beberapa kelas tidak menghasilkan
instance karena mereka digunakan hanya sebagai templat untuk kelas lain
yang lebih spesifik (terutama kelas yang terletak tinggi di hierarki). Kelas-
kelas tersebut disebut sebagai kelas abstrak. Person adalah contoh dari kelas
abstrak. Alih-alih menciptakan objek dari Person, kami menciptakan instance
yang mewakili kelas Specialist dan Patient yang lebih spesifik, keduanya
jenis Person (lihat Gambar 1-11).

Polimorfisme dan Pengikatan Dinamis Polimorfisme berarti bahwa pesan

yang sama bisa ditafsirkan secara berbeda oleh kelas objek yang berbeda.
Misalnya, memasukkan pasien berarti sesuatu yang berbeda dari
memasukkan janji. Oleh karena itu, potongan informasi yang berbeda perlu
dikumpulkan dan disimpan. Beruntung, kami tidak perlu khawatir bagaimana
sesuatu dilakukan ketika menggunakan objek. Kami cukup mengirim pesan
ke objek, dan objek itu akan bertanggung jawab untuk menafsirkan pesan
dengan tepat. Misalnya, jika seorang artis mengirim pesan Gambar diri Anda
sendiri ke objek persegi, objek lingkaran, dan objek segitiga, hasilnya akan
sangat berbeda, meskipun pesan itu sama. Perhatikan dalam Gambar 1-13
bagaimana setiap objek merespons dengan tepat (dan berbeda) meskipun
pesan-pesan itu identik.
Polimorfisme dimungkinkan melalui pengikatan dinamis. Dinamis, atau
pengikatan akhir, adalah teknik yang menunda pengetikan objek hingga
waktu jalannya. Metode spesifik yang sebenarnya dipanggil tidak dipilih oleh
sistem berorientasi objek hingga sistem sedang berjalan. Ini berbeda dengan
pengikatan statis. Dalam sistem yang terikat secara statis, jenis objek
ditentukan pada waktu kompilasi. Oleh karena itu, pengembang harus
memilih metode mana yang harus dipanggil alih-alih membiarkan sistem
melakukannya. Ini adalah alasan mengapa kebanyakan bahasa
pemrograman tradisional memiliki logika keputusan rumit berdasarkan jenis
objek yang berbeda dalam sistem. Misalnya, dalam bahasa pemrograman
tradisional, alih-alih mengirim pesan Gambar diri Anda sendiri ke jenis objek
grafis yang berbeda dalam Gambar 1-13, kami harus menulis logika
keputusan menggunakan pernyataan case atau satu set pernyataan if untuk
menentukan jenis objek grafis apa yang kami inginkan untuk gambar, dan
kami harus menamai setiap fungsi gambar secara berbeda (misalnya,
gambar persegi, gambar lingkaran, atau gambar segitiga). Ini jelas membuat
sistem jauh lebih rumit dan sulit dipahami.

ANALISIS DAN DESAIN SISTEM BERORIENTASI OBJEK (OOSAD)

Pendekatan berorientasi objek untuk mengembangkan sistem informasi,

secara teknis, bisa menggunakan salah satu metodologi tradisional. Namun,
pendekatan berorientasi objek paling terkait dengan metodologi RAD
berbasis pengembangan bertahap atau agile. Perbedaan utama antara
pendekatan tradisional seperti desain terstruktur dan pendekatan
berorientasi objek adalah bagaimana masalah didekomposisi. Dalam
pendekatan tradisional, proses dekomposisi masalah baik berpusat pada
proses atau berpusat pada data. Namun, proses dan data sangat terkait
sehingga sulit memilih salah satu atau yang lain sebagai fokus utama.
Berdasarkan kurangnya kesesuaian ini dengan dunia nyata, metodologi
berorientasi objek baru telah muncul yang menggunakan urutan berbasis
RAD dari fase SDLC tetapi mencoba menyeimbangkan penekanan antara
proses dan data dengan memfokuskan dekomposisi masalah pada objek
yang berisi baik data maupun proses.

Menurut pencipta Bahasa Pemodelan Terpadu (UML), Grady Booch, Ivar

Jacobson, dan James Rumbaugh,16 pendekatan berorientasi objek modern
untuk mengembangkan sistem informasi harus didorong oleh kasus
pengguna, berpusat pada arsitektur, dan berulang serta bertahap.

Didorong oleh Kasus Pengguna

Didorong oleh kasus pengguna berarti bahwa kasus pengguna adalah alat
pemodelan utama yang mendefinisikan perilaku sistem. Sebuah kasus
pengguna menjelaskan bagaimana pengguna berinteraksi dengan sistem
untuk melakukan suatu aktivitas, seperti memesan, membuat reservasi, atau
mencari informasi. Kasus pengguna digunakan untuk mengidentifikasi dan
mengomunikasikan persyaratan untuk sistem kepada programmer yang
harus menulis sistem. Kasus pengguna secara inheren sederhana karena
fokus hanya pada satu proses bisnis pada satu waktu. Sebaliknya, diagram
model proses yang digunakan oleh metodologi terstruktur tradisional dan
RAD jauh lebih kompleks karena memerlukan analis sistem dan pengguna
untuk mengembangkan model dari seluruh sistem. Dengan metodologi
tradisional, setiap sistem didekomposisi menjadi satu set subsistem, yang,
pada gilirannya, didekomposisi lebih lanjut menjadi subsistem lebih lanjut,
dan seterusnya. Ini berlanjut hingga tidak ada dekomposisi proses lebih
lanjut yang masuk akal, dan sering memerlukan lusinan halaman diagram
yang saling terkait. Sebaliknya, kasus pengguna fokus hanya pada satu
proses bisnis pada satu waktu, jadi mengembangkan model jauh lebih
sederhana.17

Berpusat pada Arsitektur

Pendekatan modern apa pun untuk analisis dan desain sistem harus
berpusat pada arsitektur. Berpusat pada arsitektur berarti bahwa arsitektur
perangkat lunak mendasar dari spesifikasi sistem yang berevolusi
mendorong spesifikasi, konstruksi, dan dokumentasi sistem. Pendekatan
analisis dan desain sistem berorientasi objek modern harus mendukung
setidaknya tiga tampilan arsitektur terpisah tetapi saling terkait dari sistem:
fungsional, statis, dan dinamis. Tampilan fungsional, atau eksternal,
menjelaskan perilaku sistem dari perspektif pengguna. Tampilan struktural,
atau statis, menjelaskan sistem dalam hal atribut, metode, kelas, dan
hubungan. Tampilan perilaku, atau dinamis, menjelaskan perilaku sistem
dalam hal pesan yang diteruskan di antara objek dan perubahan keadaan
dalam objek.

Berulang dan Bertahap

Pendekatan analisis dan desain sistem berorientasi objek modern

menekankan pengembangan berulang dan bertahap yang mengalami
pengujian dan penyempurnaan berkelanjutan sepanjang hidup proyek. Ini
berarti bahwa analis sistem mengembangkan pemahaman mereka tentang
masalah pengguna dengan membangun tiga tampilan arsitektur sedikit demi
sedikit. Analis melakukan ini dengan bekerja dengan pengguna untuk
menciptakan representasi fungsional dari sistem yang sedang dipelajari.
Selanjutnya, analis mencoba membangun representasi struktural dari sistem
yang berevolusi. Menggunakan representasi struktural dari sistem, analis
mendistribusikan fungsionalitas sistem di atas struktur yang berevolusi untuk
menciptakan representasi perilaku dari sistem yang berevolusi. Saat analis
bekerja dengan pengguna dalam mengembangkan tiga tampilan arsitektur
dari sistem yang berevolusi, analis mengiterasi melalui masing-masing dan
di antara tampilan. Artinya, saat analis lebih memahami tampilan struktural
dan perilaku, analis menemukan persyaratan yang hilang atau salah
representasi dalam tampilan fungsional. Ini, pada gilirannya, bisa
menyebabkan perubahan untuk
16
Grady Booch, Ivar Jacobson, dan James Rumbaugh, The Unified Modeling
Language User Guide (Reading, MA: Addison-Wesley, 1999). 17 Bagi Anda
yang memiliki pengalaman dengan analisis dan desain terstruktur
tradisional, ini adalah salah satu aspek paling tidak biasa dari analisis dan
desain berorientasi objek menggunakan UML. Tidak seperti pendekatan
terstruktur, pendekatan berorientasi objek menekankan fokus pada hanya
satu kasus pengguna pada satu waktu dan mendistribusikan satu kasus
pengguna itu di atas satu set objek yang berkomunikasi dan berkolaborasi.

dikaskad kembali melalui tampilan struktural dan perilaku. Ketiga tampilan

arsitektur sistem saling terkait dan bergantung satu sama lain (lihat Gambar
1-14). Saat setiap increment dan iterasi selesai, representasi yang lebih
lengkap dari persyaratan fungsional nyata pengguna ditemukan.

Manfaat Analisis dan Desain Sistem Berorientasi Objek

Konsep dalam pendekatan berorientasi objek memungkinkan analis untuk

memecah sistem kompleks menjadi modul yang lebih kecil, lebih mudah
dikelola, bekerja pada modul secara individu, dan dengan mudah
menyatukan modul untuk membentuk sistem informasi. Modularitas ini
membuat pengembangan sistem lebih mudah dipahami, lebih mudah
dibagikan di antara anggota tim proyek, dan lebih mudah dikomunikasikan
kepada pengguna, yang diperlukan untuk memberikan persyaratan dan
mengonfirmasi seberapa baik sistem memenuhi persyaratan sepanjang
proses pengembangan sistem. Dengan memodularisasi pengembangan
sistem, tim proyek sebenarnya menciptakan potongan yang dapat digunakan
kembali yang bisa dicolokkan ke upaya sistem lain atau digunakan sebagai
titik awal untuk proyek lain. Akhirnya, ini bisa menghemat waktu karena
proyek baru tidak harus dimulai sepenuhnya dari awal.
PROSES TERPADU

Proses Terpadu adalah metodologi spesifik yang memetakan kapan dan

bagaimana menggunakan berbagai teknik Bahasa Pemodelan Terpadu (UML)
untuk analisis dan desain berorientasi objek. Kontributor utama adalah Grady
Booch, Ivar Jacobson, dan James Rumbaugh. Sedangkan UML memberikan
dukungan struktural untuk mengembangkan struktur dan perilaku sistem
informasi, Proses Terpadu memberikan dukungan perilaku. Proses Terpadu,
tentu saja, didorong oleh kasus pengguna, berpusat pada arsitektur, dan
berulang serta bertahap. Selain itu, Proses Terpadu adalah proses
pengembangan sistem dua dimensi yang dijelaskan oleh satu set fase dan
alur kerja. Fase-fasenya adalah inisiasi, elaborasi, konstruksi, dan transisi.
Alur kerja mencakup pemodelan bisnis, persyaratan, analisis, desain,
implementasi, pengujian, penerapan, konfigurasi dan manajemen
perubahan, manajemen proyek, dan lingkungan. 18 Gambar 1-15
menggambarkan Proses Terpadu.
18
Bahan dalam bagian ini didasarkan pada Ivar Jacobson, Grady Booch, dan
James Rumbaugh, The Unified Software Development Process (Reading, MA:
Addison-Wesley, 1999); Phillipe Krutchten, The Rational Unified Process: An
Introduction, edisi ke-2 (Boston, MA: Addison-Wesley, 2000); “Rational Unified
Process: Best Practices for Software Development Teams,” Makalah Putih
Rational Software, TP026B, Rev 11/01.

Fase Fase-fase Proses Terpadu mendukung analis dalam mengembangkan

sistem informasi secara berulang dan bertahap. Fase-fase menjelaskan
bagaimana sistem informasi berevolusi seiring waktu. Tergantung pada fase
pengembangan mana sistem yang berevolusi saat ini berada, tingkat
aktivitas bervariasi di atas alur kerja. Kurva dalam Gambar 1-15 yang terkait
dengan setiap alur kerja mendekati jumlah aktivitas yang berlangsung
selama fase spesifik. Misalnya, fase inisiasi terutama melibatkan alur kerja
pemodelan bisnis dan persyaratan, sementara hampir mengabaikan alur
kerja pengujian dan penerapan. Setiap fase berisi satu set iterasi, dan setiap
iterasi menggunakan berbagai alur kerja untuk menciptakan versi bertahap
dari sistem yang berevolusi. Saat sistem berevolusi melalui fase, itu
meningkat dan menjadi lebih lengkap. Setiap fase memiliki tujuan, fokus
aktivitas di atas alur kerja, dan hasil akhir bertahap. Setiap fase dijelaskan
selanjutnya.

Inisiasi Dalam banyak cara, fase inisiasi sangat mirip dengan fase
perencanaan pendekatan SDLC tradisional. Dalam fase ini, kasus bisnis
dibuat untuk sistem yang diusulkan. Ini mencakup analisis kelayakan yang
harus menjawab pertanyaan seperti berikut:

Apakah kami memiliki kemampuan teknis untuk membangunnya (kelayakan

teknis)?

Jika kami membangunnya, apakah itu akan memberikan nilai bisnis

(kelayakan ekonomi)?

Jika kami membangunnya, apakah itu akan digunakan oleh organisasi

(kelayakan organisasi)?

Untuk menjawab pertanyaan ini, tim pengembangan melakukan pekerjaan

terkait terutama dengan alur kerja pemodelan bisnis, persyaratan, dan
analisis. Dalam beberapa kasus, tergantung pada kesulitan teknis yang bisa
ditemui selama pengembangan sistem, prototipe buang dikembangkan. Ini
berarti bahwa alur kerja desain, implementasi, dan pengujian juga bisa
terlibat. Alur kerja pendukung manajemen proyek dan lingkungan sangat
relevan untuk fase ini. Hasil akhir utama dari fase inisiasi adalah dokumen
visi yang menetapkan ruang lingkup proyek; mengidentifikasi persyaratan
dan kendala utama; menyiapkan rencana proyek awal; dan menjelaskan
kelayakan dan risiko terkait dengan proyek, adopsi lingkungan yang
diperlukan untuk mengembangkan sistem, dan beberapa aspek kelas
domain masalah yang diimplementasikan dan diuji.

Elaborasi Saat kami biasanya memikirkan analisis dan desain sistem

berorientasi objek, aktivitas terkait dengan fase elaborasi Proses Terpadu
adalah yang paling relevan. Alur kerja analisis dan desain adalah fokus
utama selama fase ini. Fase elaborasi berlanjut dengan mengembangkan
dokumen visi, termasuk menyelesaikan kasus bisnis, merevisi penilaian
risiko, dan menyelesaikan rencana proyek dalam detail yang cukup untuk
memungkinkan pemangku kepentingan setuju dengan membangun sistem
akhir yang sebenarnya. Ini berurusan dengan pengumpulan persyaratan,
membangun model UML struktural dan perilaku domain masalah, dan
merinci bagaimana model domain masalah sesuai dengan arsitektur sistem
yang berevolusi. Pengembang terlibat dengan semua kecuali alur kerja
rekayasa penerapan dalam fase ini. Saat pengembang mengiterasi alur
kerja, pentingnya menangani konfigurasi dan manajemen perubahan
menjadi jelas. Juga, alat pengembangan yang diperoleh selama fase inisiasi
menjadi kritis untuk kesuksesan proyek selama fase ini. 19 Hasil akhir utama
fase ini mencakup diagram struktur dan perilaku UML dan eksekusi dari versi
baseline sistem informasi yang berevolusi. Versi baseline berfungsi sebagai
fondasi untuk semua iterasi kemudian. Dengan menyediakan fondasi yang
solid pada titik ini, pengembang memiliki dasar untuk menyelesaikan sistem
dalam fase konstruksi dan transisi.

Konstruksi Fase konstruksi fokus berat pada pemrograman sistem informasi

yang berevolusi. Fase ini terutama berkaitan dengan alur kerja implementasi.
Namun, alur kerja persyaratan dan analisis dan desain juga terlibat dengan
fase ini. Ini adalah selama fase ini bahwa persyaratan yang hilang
diidentifikasi dan model analisis dan desain akhirnya diselesaikan. Biasanya,
ada iterasi alur kerja selama fase ini, dan selama iterasi terakhir, alur kerja
penerapan mulai bergerak cepat. Alur kerja konfigurasi dan manajemen
perubahan, dengan aktivitas kontrol versinya, menjadi sangat penting
selama fase konstruksi. Kadang-kadang, iterasi alur kerja harus digulung
kembali. Tanpa kontrol versi yang baik, menggulung kembali ke versi
sebelumnya (implementasi bertahap) dari sistem hampir tidak mungkin.
Hasil akhir utama fase ini adalah implementasi sistem yang bisa dirilis untuk
pengujian beta dan penerimaan.

Transisi Seperti fase konstruksi, fase transisi menangani aspek yang

biasanya terkait dengan fase implementasi pendekatan SDLC tradisional.
Fokus utamanya adalah pada alur kerja pengujian dan penerapan. Pada
dasarnya, alur kerja pemodelan bisnis, persyaratan, dan analisis seharusnya
telah selesai dalam iterasi sebelumnya dari sistem informasi yang
berevolusi. Selain itu, alur kerja pengujian telah
19
Dengan UML terdiri dari lima belas teknik diagramming yang berbeda dan
terkait, menjaga diagram terkoordinasi dan versi sistem yang berevolusi
yang berbeda tersinkronisasi biasanya di luar kemampuan pengembang
sistem biasa. Alat-alat ini biasanya mencakup manajemen proyek dan alat
CASE. Kami menjelaskan penggunaan alat ini di Bab 2.

berjalan selama fase sebelumnya dari sistem yang berevolusi. Tergantung

pada hasil dari alur kerja pengujian, beberapa redesain dan pemrograman
pada alur kerja desain dan implementasi bisa diperlukan, tapi harus minimal
pada titik ini. Dari perspektif manajerial, manajemen proyek, konfigurasi dan
manajemen perubahan, dan lingkungan terlibat. Beberapa aktivitas yang
berlangsung adalah pengujian beta dan penerimaan, penyempurnaan desain
dan implementasi, pelatihan pengguna, dan peluncuran produk akhir ke
platform produksi. Jelas, hasil akhir utama adalah sistem informasi eksekusi
yang sebenarnya. Hasil akhir lainnya mencakup manual pengguna, rencana
untuk mendukung pengguna, dan rencana untuk meningkatkan sistem
informasi di masa depan.
Alur Kerja

Alur kerja menjelaskan tugas atau aktivitas yang dilakukan pengembang

untuk mengembangkan sistem informasi seiring waktu. Alur kerja Proses
Terpadu dikelompokkan menjadi dua kategori luas: rekayasa dan pendukung.

Alur Kerja Rekayasa Alur kerja rekayasa mencakup alur kerja pemodelan
bisnis, persyaratan, analisis, desain, implementasi, pengujian, dan
penerapan. Alur kerja rekayasa berurusan dengan aktivitas yang
menghasilkan produk teknis (yaitu, sistem informasi).

Alur Kerja Pemodelan Bisnis Alur kerja pemodelan bisnis menemukan

masalah dan mengidentifikasi proyek potensial dalam organisasi pengguna.
Alur kerja ini membantu manajemen dalam memahami ruang lingkup proyek
yang dapat meningkatkan efisiensi dan efektivitas organisasi pengguna.
Tujuan utama pemodelan bisnis adalah untuk memastikan bahwa baik
organisasi pengembang maupun pengguna memahami di mana dan
bagaimana sistem informasi yang akan dikembangkan sesuai dengan proses
bisnis organisasi pengguna. Alur kerja ini terutama dijalankan selama fase
inisiasi untuk memastikan bahwa kami mengembangkan sistem informasi
yang masuk akal bisnis. Aktivitas yang berlangsung pada alur kerja ini paling
terkait dengan fase perencanaan SDLC tradisional; namun, pengumpulan
persyaratan, dan teknik pemodelan kasus pengguna dan proses bisnis juga
membantu kami memahami situasi bisnis.

Alur Kerja Persyaratan Dalam Proses Terpadu, alur kerja persyaratan

mencakup mengumpulkan baik persyaratan fungsional maupun
nonfungsional. Biasanya, persyaratan dikumpulkan dari pemangku
kepentingan proyek, seperti pengguna akhir, manajer dalam organisasi
pengguna akhir, dan bahkan pelanggan. Alur kerja persyaratan digunakan
paling banyak selama fase inisiasi dan elaborasi. Persyaratan yang
diidentifikasi sangat membantu untuk mengembangkan dokumen visi dan
kasus pengguna yang digunakan sepanjang proses pengembangan.
Persyaratan tambahan cenderung ditemukan sepanjang proses
pengembangan. Pada kenyataannya, hanya fase transisi yang cenderung
memiliki sedikit, jika ada, persyaratan tambahan yang diidentifikasi.

Alur Kerja Analisis Alur kerja analisis terutama menangani penciptaan

model analisis domain masalah. Dalam Proses Terpadu, analis mulai
merancang arsitektur terkait dengan domain masalah; menggunakan UML,
analis menciptakan diagram struktural dan perilaku yang menggambarkan
deskripsi kelas domain masalah dan interaksinya. Tujuan utama alur kerja
analisis adalah untuk memastikan bahwa baik organisasi pengembang
maupun pengguna memahami masalah mendasar dan domainnya tanpa
overanalisis. Jika mereka tidak hati-hati, analis bisa menciptakan paralisis
analisis, yang terjadi ketika proyek begitu terjebak dengan analisis sehingga
sistem tidak pernah benar-benar dirancang atau diimplementasikan. Tujuan
kedua dari alur kerja analisis adalah mengidentifikasi kelas yang berguna
untuk perpustakaan kelas. Dengan menggunakan kembali kelas yang telah
didefinisikan, analis bisa menghindari menemukan kembali roda

saat menciptakan diagram struktural dan perilaku. Alur kerja analisis

terutama terkait dengan fase elaborasi, tapi seperti alur kerja persyaratan,
mungkin saja analisis tambahan diperlukan sepanjang proses
pengembangan.

Alur Kerja Desain Alur kerja desain mentransisikan model analisis ke dalam
bentuk yang bisa digunakan untuk menerapkan sistem: model desain.
Sedangkan alur kerja analisis berkonsentrasi pada memahami domain
masalah, alur kerja desain fokus pada mengembangkan solusi yang akan
berjalan dalam lingkungan spesifik. Pada dasarnya, alur kerja desain hanya
meningkatkan deskripsi sistem yang berevolusi dengan menambahkan kelas
yang menangani lingkungan sistem ke model analisis yang berevolusi. Alur
kerja desain menggunakan aktivitas seperti desain kelas domain masalah
rinci, optimasi sistem informasi yang berevolusi, desain basis data, desain
antarmuka pengguna, dan desain arsitektur fisik. Alur kerja desain terkait
terutama dengan fase elaborasi dan konstruksi Proses Terpadu.

Alur Kerja Implementasi Tujuan utama alur kerja implementasi adalah

menciptakan solusi eksekusi berdasarkan model desain (yaitu,
pemrograman). Ini mencakup tidak hanya menulis kelas baru tetapi juga
memasukkan kelas yang dapat digunakan kembali dari perpustakaan kelas
eksekusi ke dalam solusi yang berevolusi. Saat dengan aktivitas
pemrograman apa pun, kelas baru dan interaksinya dengan kelas yang dapat
digunakan kembali yang dimasukkan harus diuji. Akhirnya, dalam kasus
kelompok multiple melakukan implementasi sistem informasi, implementer
juga harus mengintegrasikan modul yang terpisah, yang diuji secara
individual untuk menciptakan versi eksekusi dari sistem. Alur kerja
implementasi terkait terutama dengan fase elaborasi dan konstruksi.

Alur Kerja Pengujian Tujuan utama dari alur kerja pengujian adalah
meningkatkan kualitas sistem yang berevolusi. Pengujian melampaui
pengujian unit sederhana yang terkait dengan alur kerja implementasi.
Dalam hal ini, pengujian juga mencakup pengujian integrasi semua modul
yang digunakan untuk menerapkan sistem, pengujian penerimaan
pengguna, dan pengujian alfa aktual dari perangkat lunak. Secara praktis,
pengujian harus berlangsung sepanjang pengembangan sistem; pengujian
model analisis dan desain terjadi selama elaborasi dan konstruksi,
sedangkan pengujian implementasi dilakukan terutama selama konstruksi
dan, hingga tingkat tertentu, fase transisi. Pada dasarnya, pada akhir setiap
iterasi selama pengembangan sistem informasi, beberapa jenis pengujian
harus dilakukan.

Alur Kerja Penerapan Alur kerja penerapan paling terkait dengan fase
transisi Proses Terpadu. Alur kerja penerapan mencakup aktivitas seperti
pengemasan perangkat lunak, distribusi, instalasi, dan pengujian beta. Saat
sebenarnya menerapkan sistem baru ke dalam organisasi pengguna,
pengembang mungkin harus mengonversi data saat ini, menghubungkan
perangkat lunak baru dengan perangkat lunak yang ada, dan melatih
pengguna akhir untuk menggunakan sistem baru.

Alur Kerja Pendukung Alur kerja pendukung mencakup manajemen

proyek, konfigurasi dan manajemen perubahan, dan alur kerja lingkungan.
Alur kerja pendukung fokus pada aspek manajerial pengembangan sistem
informasi.

Alur Kerja Manajemen Proyek Sedangkan alur kerja lainnya yang terkait
dengan Proses Terpadu secara teknis aktif selama semua empat fase, alur
kerja manajemen proyek adalah satu-satunya alur kerja lintas-fase yang
benar. Proses pengembangan mendukung pengembangan bertahap dan
berulang, jadi sistem informasi cenderung tumbuh atau berevolusi seiring
waktu. Pada akhir setiap iterasi, versi bertahap baru dari sistem siap untuk
dikirim. Alur kerja manajemen proyek cukup penting karena kompleksitas
model pengembangan dua dimensi

Proses Terpadu (alur kerja dan fase). Aktivitas alur kerja ini mencakup
mengidentifikasi dan mengelola risiko, mengelola ruang lingkup,
memperkirakan waktu untuk menyelesaikan setiap iterasi dan seluruh
proyek, memperkirakan biaya iterasi individu dan seluruh proyek, dan
melacak kemajuan yang dibuat menuju versi akhir dari sistem informasi
yang berevolusi.

Alur Kerja Konfigurasi dan Manajemen Perubahan Tujuan utama dari

alur kerja konfigurasi dan manajemen perubahan adalah melacak keadaan
sistem yang berevolusi. Secara singkat, sistem informasi yang berevolusi
terdiri dari satu set artefak (misalnya, diagram, kode sumber, dan eksekusi).
Selama proses pengembangan, artefak ini dimodifikasi. Jumlah pekerjaan
yang substansial—dan, karenanya, uang—terlibat dalam mengembangkan
artefak. Artefak itu sendiri harus ditangani seperti aset mahal apa pun—
kontrol akses harus ditempatkan untuk melindungi artefak dari dicuri atau
dihancurkan. Selain itu, karena artefak dimodifikasi secara reguler, jika tidak
kontinu, mekanisme kontrol versi yang baik harus dibangun. Akhirnya,
banyak informasi manajemen proyek perlu ditangkap (misalnya, penulis,
waktu, dan lokasi setiap modifikasi). Alur kerja konfigurasi dan manajemen
perubahan terkait terutama dengan fase konstruksi dan transisi.

Alur Kerja Lingkungan Selama pengembangan sistem informasi, tim

pengembangan perlu menggunakan alat dan proses yang berbeda. Alur kerja
lingkungan menangani kebutuhan ini. Misalnya, alat CASE yang mendukung
pengembangan sistem informasi berorientasi objek melalui UML bisa
diperlukan. Alat lain yang diperlukan mencakup lingkungan pemrograman,
alat manajemen proyek, dan alat manajemen konfigurasi. Alur kerja
lingkungan melibatkan memperoleh dan menginstal alat ini. Meskipun alur
kerja ini bisa aktif selama semua fase Proses Terpadu, itu harus terlibat
terutama dengan fase inisiasi.

Perluasan Proses Terpadu

Sebesar dan serumit Proses Terpadu, banyak penulis telah menunjukkan satu
set kelemahan kritis. Pertama, Proses Terpadu tidak menangani
kepegawaian, penganggaran, atau isu manajemen kontrak. Aktivitas ini
secara eksplisit ditinggalkan dari Proses Terpadu. Kedua, Proses Terpadu
tidak menangani isu terkait pemeliharaan, operasi, atau dukungan produk
setelah dikirim. Dengan demikian, itu bukan proses perangkat lunak lengkap;
itu hanya proses pengembangan. Ketiga, Proses Terpadu tidak menangani isu
lintas- atau antar-proyek. Mempertimbangkan pentingnya reuse dalam
pengembangan sistem berorientasi objek dan fakta bahwa dalam banyak
organisasi karyawan bekerja pada banyak proyek berbeda pada waktu yang
sama, meninggalkan isu antar-proyek adalah kelalaian besar.

Untuk menangani kelalaian ini, Ambler dan Constantine menyarankan

menambahkan fase produksi dan dua alur kerja: alur kerja operasi dan
dukungan serta alur kerja manajemen infrastruktur (lihat Gambar 1-16). 20
Selain alur kerja baru ini, alur kerja pengujian, penerapan, dan lingkungan
dimodifikasi, dan alur kerja manajemen proyek dan konfigurasi dan
manajemen perubahan diperpanjang ke dalam fase produksi. Perluasan ini
20
S. W. Ambler dan L. L. Constantine, The Unified Process Inception Phase:
Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S.
W. Ambler dan L. L. Constantine, The Unified Process Elaboration Phase: Best
Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W.
Ambler dan L. L. Constantine, The Unified Process Construction Phase: Best
Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W.
Ambler dan L. L. Constantine, The Unified Process Transition and Production
Phases: Best Practices in Implementing the UP (Lawrence, KS: CMP Books,
2002).

didasarkan pada proses perangkat lunak berorientasi objek alternatif: proses

OPEN (Proses Berorientasi Objek, Lingkungan, dan Notasi) dan Proses
Perangkat Lunak Berorientasi Objek.21

Fase Produksi Fase produksi terutama berkaitan dengan isu terkait produk
perangkat lunak setelah berhasil diterapkan. Fase ini fokus pada isu terkait
memperbarui, memelihara, dan mengoperasikan perangkat lunak. Tidak
seperti fase sebelumnya, tidak ada iterasi atau hasil akhir bertahap. Jika rilis
baru dari perangkat lunak akan dikembangkan,
21
S. W. Ambler, Process Patterns—Building Large-Scale Systems Using
Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press,
1998); S. W. Ambler, More Process Patterns—Delivering Large-Scale Systems
Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University
Press, 1999); I. Graham, B. Henderson-Sellers, dan H. Younessi, The OPEN
Process Specification (Harlow, UK: Addison-Wesley, 1997); B. Henderson-
Sellers dan B. Unhelkar, OPEN Modeling with UML (Harlow, UK: Addison-
Wesley, 2000).

maka pengembang harus mulai run baru melalui empat fase pertama.
Berdasarkan aktivitas yang berlangsung selama fase ini, tidak ada alur kerja
rekayasa yang relevan. Alur kerja pendukung yang aktif selama fase ini
mencakup alur kerja konfigurasi dan manajemen perubahan, alur kerja
manajemen proyek, alur kerja operasi dan dukungan baru, dan alur kerja
manajemen infrastruktur.

Alur Kerja Operasi dan Dukungan Alur kerja operasi dan dukungan,
seperti yang mungkin Anda tebak, menangani isu terkait mendukung versi
saat ini dari perangkat lunak dan mengoperasikan perangkat lunak secara
harian. Aktivitas mencakup membuat rencana untuk operasi dan dukungan
produk perangkat lunak setelah diterapkan, membuat pelatihan dan
dokumentasi pengguna, menempatkan prosedur cadangan yang diperlukan,
memantau dan mengoptimalkan kinerja perangkat lunak, dan melakukan
pemeliharaan korektif pada perangkat lunak. Alur kerja ini menjadi aktif
selama fase konstruksi; tingkat aktivitasnya meningkat sepanjang transisi
dan, akhirnya, fase produksi. Alur kerja akhirnya menurun ketika versi saat
ini dari perangkat lunak diganti oleh versi baru. Banyak pengembang berada
di bawah kesan salah bahwa setelah perangkat lunak diserahkan kepada
pelanggan, pekerjaan mereka selesai. Dalam kebanyakan kasus, pekerjaan
mendukung produk perangkat lunak jauh lebih mahal dan memakan waktu
daripada pengembangan asli. Pada titik itu, pekerjaan pengembang mungkin
baru saja dimulai.

Alur Kerja Manajemen Infrastruktur Tujuan utama dari alur kerja

manajemen infrastruktur adalah mendukung pengembangan infrastruktur
yang diperlukan untuk mengembangkan sistem berorientasi objek. Aktivitas
seperti pengembangan dan modifikasi perpustakaan, standar, dan model
perusahaan sangat penting. Ketika pengembangan dan pemeliharaan model
arsitektur domain masalah melampaui ruang lingkup proyek tunggal dan
reuse akan terjadi, alur kerja manajemen infrastruktur esensial. Satu set
aktivitas lintas-proyek yang sangat penting lainnya adalah perbaikan proses
pengembangan perangkat lunak. Karena aktivitas pada alur kerja ini
cenderung memengaruhi banyak proyek dan Proses Terpadu fokus hanya
pada proyek spesifik, Proses Terpadu cenderung mengabaikan aktivitas ini
(yaitu, mereka hanya di luar ruang lingkup dan tujuan Proses Terpadu).

Modifikasi dan Perpanjangan Alur Kerja yang Ada Selain alur kerja
yang ditambahkan untuk menangani kekurangan yang terkandung dalam
Proses Terpadu, alur kerja yang ada harus dimodifikasi dan/atau
diperpanjang ke dalam fase produksi baru. Alur kerja ini mencakup alur kerja
pengujian, penerapan, lingkungan, manajemen proyek, dan konfigurasi dan
manajemen perubahan.

Alur Kerja Pengujian Untuk sistem informasi berkualitas tinggi

dikembangkan, pengujian harus dilakukan pada setiap hasil akhir, termasuk
yang dibuat selama fase inisiasi. Jika tidak, sistem berkualitas rendah akan
diserahkan kepada pelanggan.

Alur Kerja Penerapan Sistem legacy ada di sebagian besar perusahaan

hari ini, dan sistem ini memiliki basis data terkait dengan mereka yang harus
dikonversi untuk berinteraksi dengan sistem baru. Karena kompleksitas
menerapkan sistem baru, konversi memerlukan perencanaan yang
signifikan. Oleh karena itu, aktivitas pada alur kerja penerapan perlu dimulai
pada fase inisiasi alih-alih menunggu hingga akhir fase konstruksi, seperti
yang disarankan oleh Proses Terpadu.

Alur Kerja Lingkungan Alur kerja lingkungan perlu dimodifikasi untuk

mencakup aktivitas terkait dengan pengaturan lingkungan operasi dan
produksi. Pekerjaan aktual yang dilakukan mirip dengan pekerjaan terkait
dengan pengaturan lingkungan pengembangan yang dilakukan selama fase
inisiasi. Dalam hal ini, pekerjaan tambahan dilakukan selama fase transisi.

Alur Kerja Manajemen Proyek Meskipun alur kerja manajemen proyek

tidak mencakup kepegawaian proyek, mengelola kontrak di antara
pelanggan dan vendor, dan mengelola anggaran proyek, aktivitas ini sangat
penting untuk kesuksesan proyek pengembangan perangkat lunak apa pun.
Kami sarankan memperpanjang manajemen proyek untuk mencakup
aktivitas ini. Alur kerja ini harus tambahan terjadi dalam fase produksi untuk
menangani isu seperti pelatihan, manajemen staf, dan manajemen
hubungan klien.

Alur Kerja Konfigurasi dan Manajemen Perubahan Alur kerja

konfigurasi dan manajemen perubahan diperpanjang ke dalam fase produksi
baru. Aktivitas yang dilakukan selama fase produksi mencakup
mengidentifikasi perbaikan potensial pada sistem operasional dan menilai
dampak potensial dari perubahan yang diusulkan. Setelah pengembang
mengidentifikasi perubahan ini dan memahami dampaknya, mereka bisa
menjadwalkan perubahan untuk dibuat dan diterapkan dengan rilis masa
depan.

Gambar 1-17 menunjukkan bab di mana fase dan alur kerja Proses Terpadu
yang Ditingkatkan dibahas. Mengingat outsourcing offshore dan otomatisasi
informasi

teknologi,22 dalam buku teks ini, kami fokus terutama pada fase elaborasi
dan alur kerja pemodelan bisnis, persyaratan, analisis, desain, dan
manajemen proyek dari Proses Terpadu yang Ditingkatkan. Namun, seperti
yang ditunjukkan Gambar 1-17, fase dan alur kerja lainnya dibahas. Dalam
banyak lingkungan pengembangan sistem berorientasi objek hari ini,
generasi kode didukung. Dengan demikian, dari perspektif bisnis, kami
percaya aktivitas yang terkait dengan alur kerja ini adalah yang paling
penting.

BAHASA PEMODELAN TERPADU

Hingga 1995, konsep objek populer tapi diimplementasikan dalam banyak
cara berbeda oleh pengembang yang berbeda. Setiap pengembang memiliki
metodologi dan notasinya sendiri (misalnya, Booch, Coad, Moses, OMT,
OOSE, SOMA).23 Kemudian pada 1995, Rational Software menyatukan tiga
pemimpin industri untuk menciptakan pendekatan tunggal untuk
pengembangan sistem berorientasi objek. Grady Booch, Ivar Jacobson, dan
James Rumbaugh bekerja dengan orang lain untuk menciptakan satu set
teknik diagramming standar yang dikenal sebagai Bahasa Pemodelan
Terpadu (UML). Tujuan UML adalah memberikan kosakata umum istilah
berorientasi objek dan teknik diagramming yang cukup kaya untuk
memodelkan proyek pengembangan sistem apa pun dari analisis melalui
implementasi. Pada November 1997, Object Management Group (OMG)
secara formal menerima UML sebagai standar untuk semua pengembang
objek. Selama tahun-tahun berikutnya, UML telah melalui beberapa revisi
kecil. Versi saat ini dari UML adalah Versi 2.5.

Versi 2.5 dari UML mendefinisikan satu set lima belas teknik diagramming
yang digunakan untuk memodelkan sistem. Diagram-diagram dibagi menjadi
dua kelompok utama: satu untuk memodelkan struktur sistem dan satu
untuk memodelkan perilaku. Diagram struktur memberikan cara untuk
mewakili data dan hubungan statis dalam sistem informasi. Diagram struktur
mencakup kelas, objek, paket, penerapan, komponen, struktur komposit, dan
diagram profil. Diagram perilaku memberikan analis dengan cara untuk
menggambarkan hubungan dinamis di antara instance atau objek yang
mewakili sistem informasi bisnis. Mereka juga memungkinkan pemodelan
perilaku dinamis dari objek individu sepanjang masa hidupnya. Diagram
pemodelan perilaku mendukung analis dalam memodelkan persyaratan
fungsional dari sistem informasi yang berevolusi. Diagram pemodelan
perilaku mencakup aktivitas, urutan, komunikasi, gambaran interaksi, waktu,
mesin keadaan perilaku, mesin keadaan protokol, dan diagram kasus
pengguna.24 Gambar 1-18 memberikan gamb