Ads CH 6 Id

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.
com
BAB 6
Pemodelan Agile
dan Prototipe
Lpenghasilan HAItujuan
Setelah Anda menguasai materi dalam bab ini, Anda akan dapat:
1. Memahami akar dari pemodelan tangkas dalam pembuatan prototipe dan empat jenis utama pembuatan prototipe.
2. Gunakan prototyping untuk pengumpulan kebutuhan informasi manusia.
3. Memahami pemodelan tangkas dan praktik inti yang membedakannya dari metodologi
pengembangan lainnya.
4. Pelajari pentingnya nilai-nilai penting untuk pemodelan tangkas.
5. Memahami cara meningkatkan efisiensi bagi pengguna yang merupakan pekerja pengetahuan menggunakan metode
terstruktur atau pemodelan tangkas.
Bab ini mengeksplorasi pemodelan tangkas, yang merupakan kumpulan

pendekatan inovatif yang berpusat pada pengguna untuk pengembangan sistem.
Anda akan mempelajari nilai dan prinsip, aktivitas, sumber daya, praktik, proses, dan
alat yang terkait dengan metodologi tangkas. Pendekatan Agile berakar pada
pembuatan prototipe, jadi bab ini dimulai dengan pembuatan prototipe untuk
memberikan konteks yang tepat untuk pemahaman, dan kemudian mengambil
pendekatan tangkas di paruh terakhir bab ini.
Pembuatan prototipe sistem informasi adalah teknik yang bermanfaat untuk mengumpulkan
informasi spesifik dengan cepat tentang kebutuhan informasi pengguna. Secara umum, prototyping
yang efektif harus datang lebih awal di SDLC, selama fase penentuan persyaratan.
Prototyping disertakan pada titik ini dalam teks untuk menggarisbawahi pentingnya sebagai teknik
pengumpulan informasi. Saat menggunakan prototipe dengan cara ini, seorang analis sistem mencari reaksi
awal dari pengguna dan manajemen terhadap prototipe, saran pengguna tentang mengubah atau
membersihkan sistem prototipe, kemungkinan inovasi untuknya, dan rencana revisi yang merinci bagian
mana dari sistem yang perlu diperbaiki. dilakukan terlebih dahulu atau cabang organisasi mana yang akan
dibuat prototipe selanjutnya.
150
Bab 6 • Pemodelan dan pembuatan prototipe yang gesit 151
Pembuatan prototipe
Sebagai analis sistem yang menyajikan prototipe sistem informasi, Anda sangat tertarik dengan reaksi
pengguna dan manajemen terhadap prototipe. Anda ingin mengetahui secara rinci bagaimana mereka
bereaksi terhadap bekerja dengan prototipe dan seberapa baik kesesuaian antara kebutuhan mereka dan
fitur prototipe sistem. Anda mengumpulkan reaksi melalui observasi, wawancara, dan lembar umpan balik
(mungkin kuesioner) yang dirancang untuk mendapatkan pendapat setiap orang tentang prototipe saat dia
berinteraksi dengannya.
Informasi yang dikumpulkan dalam fase prototyping memungkinkan seorang analis untuk menetapkan prioritas dan
mengarahkan rencana secara murah, dengan gangguan minimal. Oleh karena itu, pembuatan prototipe dan perencanaan
berjalan seiring.
Jenis Prototipe
kata prototipe digunakan dalam banyak cara yang berbeda. Daripada mencoba untuk mensintesis semua penggunaan ini ke
dalam satu definisi atau mencoba untuk mengamanatkan satu pendekatan yang benar untuk topik prototyping yang agak
kontroversial, kami menggambarkan bagaimana masing-masing dari beberapa konsepsi prototyping dapat berguna
diterapkan dalam situasi tertentu, seperti yang ditunjukkan pada Gambar 6.1.
PROTOTIPE PATCH-UP. Jenis pertama prototyping berkaitan dengan membangun sebuah sistem yang
bekerja tetapi ditambal atau ditambal bersama-sama. Dalam rekayasa, pendekatan ini disebut
sebagai breadboarding: menciptakan model kerja yang ditambal-bersama dari sirkuit terpadu (jika
tidak mikroskopis).
Contoh dalam sistem informasi adalah model kerja yang memiliki semua fitur yang diperlukan
tetapi tidak efisien. Dalam contoh pembuatan prototipe ini, pengguna dapat berinteraksi dengan
sistem, membiasakan diri dengan antarmuka dan jenis keluaran yang tersedia. Pengambilan dan
penyimpanan informasi mungkin tidak efisien, karena program ditulis dengan cepat, dengan tujuan:
menjadi bisa diterapkan daripada efisien.
Gambar 6.1
Empat jenis prototipe.
Memasukkan Proses Keluaran
Prototipe yang Ditambal Prototipe Nonoperasional
Fasilitas 3
Fasilitas 2
Fasilitas 1
Fitur 1
Fitur 3
Fitur 5
Prototipe Seri Pertama Prototipe Fitur yang Dipilih

152
PELUANG KONSULTASI 6.1
Apakah Prototyping Raja?
"A Anda tahu, kami adalah grup yang antusias. Kami belum menjadi dinasti,
tetapi kami sedang mengerjakannya,” kata Paul LeGon kepada Anda. Paul
Saat Anda merumuskan tanggapan kepada Paul, Anda memikirkan
kembali beberapa minggu Anda bekerja dengan Pyramid, Inc. Anda
(diperkenalkan dalam Consulting Opportunity 2.3), pada usia 24 tahun, adalah "raja berpikir bahwa masalah bisnis yang harus diselesaikan oleh sistem
laki-laki" dari Pyramid, Inc., sebuah perusahaan penerbitan buku independen kecil informasinya sangat mudah. Anda juga tahu bahwa orang-orang di
namun sukses yang mengkhususkan diri dalam buku-buku paperback di luar arus perusahaan memiliki anggaran terbatas dan tidak mampu
utama penerbitan. Sebagai analis sistem, Anda telah dipekerjakan oleh Pyramid, Inc., menghabiskan seperti raja. Sebenarnya, seluruh proyek ini cukup kecil.
untuk membantu mengembangkan inventaris gudang dan sistem informasi Ceil, berdasarkan apa yang telah dikatakan Paul, memberi tahu
distribusi yang terkomputerisasi. Anda, “Kami tidak bermaksud terlalu terikat dengannya, tetapi kami
"Kami mempekerjakan banyak pekerja," lanjut Paul, seolah merasa membuat prototipe mewakili dunia baru. Dan di situlah kita
meyakinkan Anda tentang luasnya usaha Pyramid. “Dan kami merasa semua ingin berada. Kami tahu kami membutuhkan prototipe. Sudahkah
Piramida diposisikan dengan sempurna sejauh menyangkut pasar kami kami meyakinkan Anda?"
di utara, selatan, timur, dan barat. Berdasarkan antusiasme Paul dan Ceil untuk membuat prototipe dan apa
“Asisten saya, Ceil Toom, dan saya telah bekerja keras, memikirkan yang Anda ketahui tentang kebutuhan Piramida, apakah Anda akan
sistem baru. Dan kami telah menyimpulkan bahwa yang benar-benar mendukung pembuatan prototipe? Mengapa atau mengapa tidak? Rumuskan
kami butuhkan adalah sebuah prototipe. Faktanya, kami telah menggali keputusan dan tanggapan Anda dalam sebuah surat kepada Paul LeGon dan
banyak materi. Ketertarikan kami dengan seluruh ide telah benar-benar Ceil Toom. Sajikan pembenaran untuk keputusan Anda berdasarkan kriteria
piramida.” keseluruhan yang harus dipenuhi untuk membenarkan pembuatan prototipe.
PROTOTIPE NONOPERASIONAL. Konsepsi kedua dari prototipe adalah model skala non-kerja yang
disiapkan untuk menguji aspek-aspek tertentu dari desain. Contoh pendekatan ini adalah
model skala penuh mobil yang digunakan dalam uji terowongan angin. Ukuran dan bentuk
mobil tepat, tetapi mobil tidak beroperasi. Dalam hal ini, hanya fitur mobil yang penting untuk
pengujian terowongan angin yang disertakan.
Sebuah model skala nonworking dari sistem informasi mungkin diproduksi ketika pengkodean yang
dibutuhkan oleh aplikasi terlalu luas untuk prototipe tetapi ketika ide yang berguna dari sistem dapat
diperoleh melalui prototipe input dan output saja. Dalam hal ini, pemrosesan, karena biaya dan waktu yang
tidak semestinya, tidak akan dibuat prototipe. Pengguna masih dapat membuat keputusan tentang utilitas
sistem, berdasarkan penggunaan input dan output prototipe.
PROTOTIPE SERI PERTAMA. Konsepsi ketiga dari prototyping melibatkan pembuatan model skala penuh pertama dari suatu
sistem, sering disebut pilot. Contohnya adalah membuat prototipe pesawat pertama dari seri dan kemudian melihat apakah
pesawat itu terbang sebelum membangun yang kedua. Prototipe ini sepenuhnya beroperasi dan merupakan realisasi dari
apa yang diharapkan oleh perancangnya adalah serangkaian pesawat dengan fitur yang identik.
Jenis prototyping ini berguna ketika banyak instalasi dari sistem informasi yang sama direncanakan.
Model kerja skala penuh memungkinkan pengguna untuk mengalami interaksi yang realistis dengan sistem
baru, tetapi meminimalkan biaya untuk mengatasi masalah yang ada. Misalnya, ketika rantai toko grosir
bermaksud menggunakan pertukaran data elektronik (EDI) untuk memeriksa pengiriman pemasok di
sejumlah outlet, model skala penuh mungkin dipasang di satu toko sehingga pengguna dapat mengatasi
masalah apa pun sebelum sistem diimplementasikan di semua yang lain.
PROTOTIPE FITUR TERPILIH. Konsepsi keempat dari prototyping menyangkut membangun model
operasional yang mencakup beberapa, tetapi tidak semua, fitur yang akan dimiliki sistem akhir.
Sebuah analogi akan menjadi pusat perbelanjaan ritel baru yang dibuka sebelum pembangunan
semua toko selesai.
Saat membuat prototipe sistem informasi dengan cara ini, beberapa, tetapi tidak semua, fitur penting disertakan.
Misalnya, pengguna dapat melihat menu sistem pada layar yang mencantumkan enam fitur: menambahkan catatan,
memperbarui catatan, menghapus catatan, mencari catatan untuk kata kunci, membuat daftar catatan, atau memindai
catatan. Dalam sistem prototipe, bagaimanapun, hanya tiga dari enam mungkin tersedia untuk digunakan, sehingga
pengguna dapat menambahkan catatan (fitur 1), menghapus catatan (fitur 3), dan daftar catatan (fitur 5).
Umpan balik pengguna dapat membantu analis memahami apa yang berhasil dan apa yang tidak. Itu juga dapat membantu dengan saran tentang
fitur apa yang akan ditambahkan selanjutnya.
Ketika prototyping semacam ini dilakukan, sistem diselesaikan dalam modul sehingga jika fitur yang
diprototipe dievaluasi oleh pengguna sebagai berhasil, mereka dapat dimasukkan ke dalam sistem final yang lebih
besar tanpa melakukan pekerjaan besar dalam antarmuka. Prototipe yang dilakukan dengan cara ini adalah bagian
dari sistem yang sebenarnya. Merekabukan hanya tiruan, seperti dalam pembuatan prototipe nonoperasional, yang
dipertimbangkan sebelumnya. Kecuali disebutkan sebaliknya, semua referensi lebih lanjut untuk pembuatan
prototipe dalam bab ini mengacu pada prototipe fitur yang dipilih.
Prototyping sebagai Alternatif untuk SDLC

Beberapa analis berpendapat bahwa prototyping harus dipertimbangkan sebagai alternatif SDLC. Ingatlah
bahwa Siklus Hidup Pengembangan Sistem, yang diperkenalkan di Bab 1, adalah pendekatan logis dan
sistematis untuk diikuti dalam pengembangan sistem informasi.
Keluhan tentang melalui pusat proses SDLC pada dua masalah yang saling terkait. Perhatian pertama
adalah perpanjangan waktu yang dibutuhkan untuk menjalani siklus hidup pengembangan. Ketika investasi
waktu analis meningkat, biaya sistem yang dikirimkan meningkat secara proporsional.
Kekhawatiran kedua tentang penggunaan SDLC adalah bahwa persyaratan pengguna berubah dari
waktu ke waktu. Selama interval panjang antara waktu kebutuhan pengguna dianalisis dan waktu sistem
yang telah selesai dikirimkan, persyaratan pengguna berkembang. Jadi, karena siklus pengembangan yang
diperpanjang, sistem yang dihasilkan dapat dikritik karena tidak memenuhi kebutuhan informasi pengguna
saat ini.
Akibat wajar dari masalah menjaga persyaratan informasi pengguna adalah saran bahwa pengguna tidak dapat benar-
benar tahu apa yang mereka lakukan atau tidak inginkan sampai mereka melihat sesuatu yang nyata. Dalam SDLC
tradisional, seringkali sudah terlambat untuk mengubah sistem yang tidak diinginkan setelah dikirimkan.
Untuk mengatasi masalah ini, beberapa analis mengusulkan agar prototyping digunakan sebagai
alternatif SDLC. Ketika prototyping digunakan dengan cara ini, seorang analis secara efektif mempersingkat
waktu antara pemastian kebutuhan informasi manusia dan pengiriman sistem yang bisa diterapkan. Selain
itu, menggunakan prototyping sebagai pengganti SDLC tradisional dapat mengatasi beberapa masalah
dalam mengidentifikasi kebutuhan informasi pengguna secara akurat.
Kelemahan untuk menggantikan SDLC dengan pembuatan prototipe termasuk pembentukan sistem secara
prematur sebelum masalah atau peluang yang ditangani dipahami secara menyeluruh. Juga, menggunakan
prototyping sebagai alternatif dapat menghasilkan sistem yang diterima oleh kelompok pengguna tertentu tetapi
tidak memadai untuk kebutuhan sistem secara keseluruhan.
Pendekatan yang kami anjurkan di sini adalah menggunakan prototyping sebagai bagian dari SDLC tradisional.
Dalam pandangan ini, prototyping dianggap sebagai tambahan, metode khusus untuk memastikan kebutuhan
informasi pengguna saat mereka berinteraksi dengan prototipe dan memberikan umpan balik untuk analis.
Mengembangkan Prototipe
Prototyping adalah cara yang luar biasa untuk mendapatkan umpan balik tentang sistem yang diusulkan dan
tentang seberapa mudah memenuhi kebutuhan informasi penggunanya, seperti yang digambarkan pada Gambar
6.2. Langkah pertama pembuatan prototipe adalah memperkirakan biaya yang diperlukan untuk membangun
modul sistem. Jika biaya waktu programmer dan analis serta biaya peralatan berada dalam anggaran,
pembangunan prototipe dapat dilanjutkan. Prototyping adalah cara terbaik untuk memfasilitasi integrasi sistem
informasi ke dalam sistem dan budaya organisasi yang lebih besar.
Pedoman untuk Mengembangkan Prototipe

Setelah keputusan untuk prototipe telah dibuat, empat pedoman utama harus diperhatikan
ketika mengintegrasikan prototipe ke dalam fase penentuan persyaratan SDLC:
1. Bekerja dalam modul yang dapat dikelola.

2. Bangun prototipe dengan cepat.
3. Memodifikasi prototipe dalam iterasi yang berurutan.
4. Tekankan antarmuka pengguna.
Seperti yang Anda lihat, pedoman menyarankan cara melanjutkan dengan prototipe yang tentu
saling terkait. Setiap pedoman dijelaskan dalam subbagian berikut.
154 bagian 2 • analisis kebutuhan informasi
Gambar 6.2
Analis harus memodifikasi desain
layar asli mereka berdasarkan reaksi
pengguna terhadap prototipe.
in Anda
Ubah desa
n reaksi
berdasarka
pr ot ot ip e Anda.
ke
BEKERJA DALAM MODUL TERKELOLA. Ketika membuat prototipe beberapa fitur sistem ke dalam model yang bisa
diterapkan, sangat penting bahwa seorang analis bekerja dalam modul yang dapat dikelola. Salah satu keuntungan
yang berbeda dari prototyping adalah bahwa tidak perlu atau diinginkan untuk membangun seluruh sistem kerja
untuk tujuan prototipe.
Modul yang dapat dikelola adalah modul yang memungkinkan pengguna untuk berinteraksi dengan fitur-fitur
utamanya tetapi dapat dibangun secara terpisah dari modul sistem lainnya. Fitur modul yang dianggap kurang
penting sengaja dihilangkan dari prototipe awal. Seperti yang akan Anda lihat nanti di bab ini, ini sangat mirip
dengan pendekatan tangkas yang menekankan rilis kecil.
MEMBANGUN PROTOTIPE DENGAN CEPAT. Kecepatan sangat penting untuk keberhasilan pembuatan prototipe sistem
informasi. Ingatlah bahwa satu keluhan yang disuarakan terhadap mengikuti SDLC tradisional adalah bahwa interval
antara penentuan persyaratan dan pengiriman sistem yang lengkap terlalu lama untuk mengatasi kebutuhan
pengguna yang berkembang secara efektif.
Analis dapat menggunakan prototyping untuk memperpendek kesenjangan ini dengan menggunakan teknik
pengumpulan informasi tradisional untuk menentukan kebutuhan informasi yang menonjol, dan kemudian dengan cepat
membuat keputusan yang menghasilkan model kerja. Akibatnya pengguna melihat dan menggunakan sistem sangat awal di
SDLC alih-alih menunggu sistem selesai untuk mendapatkan pengalaman langsung.
Menyusun prototipe operasional baik secara cepat dan awal di SDLC memungkinkan seorang analis untuk
mendapatkan wawasan berharga tentang bagaimana sisa proyek harus berjalan. Dengan menunjukkan kepada
pengguna di awal proses bagaimana kinerja bagian-bagian sistem sebenarnya, penjaga prototyping cepat
Membersihkan Jalan untuk Tautan Pelanggan
W Orld's Trend (lihat Bab 7 untuk deskripsi perusahaan yang

terperinci) sedang membangun situs web untuk menjual barang
dan membiarkan pelanggan mengklik tombol untuk meminta informasi lebih
lanjut, atau selengkap mungkin pada satu halaman? Jika saya menggunakan
dagangan yang biasanya dijual melalui Web dan melalui operasi metode penautan, maka saya dapat memuat lebih banyak item di layar. . . tapi
katalognya. Sebagai konsultan Web yang baru direkrut, Lincoln Cerf mungkin terlalu teratur. Pelanggan menyukai tampilan dan nuansa penjualan
mendapati dirinya berada di kota yang sangat dingin dan dingin, di mana barang dagangan dicampur bersama-sama.”
berjuang melewati beberapa inci salju untuk bertemu dengan salah satu Linc melanjutkan pemikirannya, mengatakan, “Ya, saya ingin tahu bagaimana
anggota tim sistem, Mary Maye, di markas World's Trend. pelanggan menginginkan informasi yang terorganisir. Apakah Anda benar-benar
Mary menyambut Lincoln, dengan mengatakan, “Setidaknya cuaca melihat mereka menggunakan Web? Maksud saya, apakah mereka mencari sepatu
tampaknya tidak mempengaruhi penjualan Web kami! Mereka cepat tidak saat membeli jas? Jika demikian, haruskah sepatu muncul di halaman setelan atau
peduli apa. ” Lincoln mengerang menghargai upayanya yang lemah dalam dihubungkan dengan cara tertentu?"
humor, tersenyum, dan berkata, "Saya mengumpulkan dari email Anda Mary berkomentar, “Itu juga pertanyaan saya. Lalu saya bertanya-tanya
minggu lalu bahwa Anda mencoba menentukan jenis informasi yang perlu apakah kita harus mencoba pendekatan ini untuk pakaian pria terlebih dahulu,
ditampilkan di situs web izin Anda." sebelum kita menerapkannya untuk pakaian wanita. Bagaimana jika
Mary menjawab, “Ya, saya mencoba mengaturnya dengan cara sebaik pendekatan pria dan wanita dalam berbelanja di Web berbeda?"
mungkin. Pelanggan kami semua sangat sibuk. Saya tahu foto semua barang Sebagai anggota ketiga dari grup pengembangan situs web Trend
dagangan kami bisa memakan waktu lama untuk muncul di halaman jika pelanggan Dunia, tanggapi dalam laporan tertulis singkat kepada Lincoln dan Mary
mengakses Web melalui modem yang lebih lambat dari rumah.” Mary melanjutkan, tentang apakah Anda harus menggunakan prototipe untuk
dengan mengatakan, “Linc, saya bahkan tidak begitu peduli tentang bagaimana mendapatkan rekomendasi dari calon pelanggan tentang situs web yang
merancang lokasi pembersihan kami saat ini. Namun, saya khawatir tentang berapa diusulkan. Apa jenis prototipe yang sesuai? Pertimbangkan setiap
banyak informasi yang perlu kita sertakan pada sebuah halaman. Misalnya, saat bentuk prototipe dan jelaskan mengapa setiap jenis akan berlaku (atau
barang sedang dalam proses clearance, tidak semua warna dan ukuran tersedia. tidak akan berlaku) untuk masalah ini. Berikan satu paragraf untuk
Mana yang menurut Anda lebih baik, untuk memasukkan beberapa informasi dasar setiap penjelasan.
terhadap komitmen sumber daya yang berlebihan untuk sebuah proyek yang pada akhirnya mungkin menjadi tidak bisa dijalankan.
Selain itu, pemodelan tangkas juga didasarkan pada waktu penyelesaian yang cepat.
MENGUBAH PROTOTIPE. Pedoman ketiga untuk mengembangkan prototipe adalah bahwa konstruksinya
harus mendukung modifikasi. Membuat prototipe yang dapat dimodifikasi berarti membuatnya dalam
modul yang tidak terlalu saling bergantung. Jika pedoman ini dipatuhi, lebih sedikit hambatan yang dihadapi
ketika modifikasi dalam prototipe diperlukan.
Prototipe umumnya dimodifikasi beberapa kali, melalui beberapa iterasi. Perubahan dalam prototipe
harus menggerakkan sistem lebih dekat dengan apa yang menurut pengguna penting. Setiap modifikasi
memerlukan evaluasi lain oleh pengguna.
Prototipe bukanlah sistem yang sudah jadi. Memasuki fase pembuatan prototipe dengan gagasan bahwa
prototipe akan memerlukan modifikasi adalah sikap membantu yang menunjukkan kepada pengguna betapa
perlunya umpan balik mereka jika sistem ingin ditingkatkan.
MENEGASKAN ANTARMUKA PENGGUNA. Antarmuka pengguna untuk prototipe (dan akhirnya sistem) sangat penting.
Apa yang ingin Anda capai dengan prototipe adalah membuat pengguna mengartikulasikan lebih lanjut persyaratan
informasi mereka, sehingga mereka harus dapat berinteraksi dengan mudah dengan prototipe sistem. Mereka
harus dapat melihat bagaimana prototipe akan memungkinkan mereka untuk menyelesaikan tugas-tugas mereka.
Bagi banyak pengguna, antarmuka adalah sistem. Seharusnya tidak menjadi batu sandungan.
Meskipun banyak aspek sistem akan tetap tidak dikembangkan dalam prototipe, antarmuka pengguna
harus cukup berkembang dengan baik untuk memungkinkan pengguna mengambil sistem dengan cepat
dan tidak menunda. Online, sistem interaktif menggunakan antarmuka GUI sangat cocok untuk prototipe.
Bab 14 menjelaskan secara rinci pertimbangan yang penting dalam merancang HCI.
Kekurangan dari Prototyping

Seperti halnya teknik pengumpulan informasi lainnya, ada beberapa kelemahan pembuatan prototipe. Yang
pertama adalah bisa sangat sulit untuk mengelola prototyping sebagai proyek di skala yang lebih besar
upaya sistem. Kerugian kedua adalah bahwa pengguna dan analis dapat mengadopsi prototipe sebagai sistem yang
lengkap padahal sebenarnya tidak memadai dan tidak pernah dimaksudkan untuk berfungsi sebagai sistem yang
sudah jadi. Analis perlu bekerja untuk memastikan bahwa komunikasi dengan pengguna jelas mengenai jadwal
untuk berinteraksi dengan dan meningkatkan prototipe.
Seorang analis perlu mempertimbangkan kelemahan ini terhadap keuntungan yang diketahui ketika memutuskan apakah akan
membuat prototipe, kapan harus membuat prototipe, dan berapa banyak sistem yang akan dibuat prototipe.
Keuntungan dari Prototyping

Prototyping tidak diperlukan atau sesuai di setiap proyek sistem, seperti yang telah kita lihat. Keuntungan,
bagaimanapun, juga harus dipertimbangkan ketika memutuskan apakah akan membuat prototipe. Tiga
keuntungan utama dari prototyping adalah potensi untuk mengubah sistem di awal pengembangannya,
kesempatan untuk menghentikan pengembangan pada sistem yang tidak bekerja, dan kemungkinan
mengembangkan sistem yang lebih dekat dengan kebutuhan dan harapan pengguna.
Prototyping yang berhasil tergantung pada umpan balik pengguna awal dan sering, yang dapat digunakan analis untuk
memodifikasi sistem dan membuatnya lebih responsif terhadap kebutuhan aktual. Seperti halnya upaya sistem lainnya,
perubahan awal lebih murah daripada perubahan yang dilakukan di akhir pengembangan proyek. Di bagian akhir bab ini,
Anda akan melihat bagaimana pendekatan agile untuk pengembangan menggunakan bentuk prototyping ekstrem yang
membutuhkan pelanggan di tempat untuk memberikan umpan balik selama semua iterasi.
Membuat Prototipe Menggunakan Perangkat Lunak COTS
Terkadang cara tercepat untuk membuat prototipe adalah melalui instalasi modular perangkat lunak COTS.
Meskipun konsep perangkat lunak COTS dapat dengan mudah dipahami dengan melihat paket yang sudah
dikenal dan relatif murah seperti produk Microsoft Office, beberapa perangkat lunak COTS rumit dan mahal
tetapi sangat berguna.
Peran Pengguna dalam Pembuatan Prototipe

Peran pengguna dalam pembuatan prototipe dapat diringkas dalam dua kata: keterlibatan yang jujur. Tanpa
keterlibatan pengguna, hanya ada sedikit alasan untuk membuat prototipe. Perilaku yang tepat yang diperlukan
untuk berinteraksi dengan prototipe dapat bervariasi, tetapi jelas bahwa pengguna sangat penting untuk proses
pembuatan prototipe. Menyadari pentingnya pengguna untuk keberhasilan proses, anggota tim analisis sistem
harus mendorong dan menyambut masukan dan menjaga ketahanan alami mereka sendiri untuk mengubah
prototipe.
Ada tiga cara utama yang dapat membantu pengguna dalam membuat prototipe:
1. Bereksperimen dengan prototipe

2. Memberikan reaksi terbuka terhadap prototipe
3. Menyarankan penambahan atau penghapusan dari prototipe
Pengguna harus bebas bereksperimen dengan prototipe. Berbeda dengan daftar fitur sistem belaka,
prototipe memungkinkan pengguna realitas interaksi langsung. Memasang prototipe di situs web interaktif
adalah salah satu cara untuk memfasilitasi interaksi ini.
Aspek lain dari peran pengguna dalam pembuatan prototipe mengharuskan mereka memberikan reaksi
terbuka terhadap prototipe. Analis harus hadir setidaknya sebagian dari waktu ketika eksperimen terjadi. Mereka
kemudian dapat mengamati interaksi pengguna dengan sistem, dan mereka terikat untuk melihat interaksi yang
tidak pernah mereka rencanakan. Formulir yang diisi untuk mengamati eksperimen pengguna dengan prototipe
ditunjukkan pada Gambar 6.3. Beberapa variabel yang harus Anda amati termasuk reaksi pengguna terhadap
prototipe, saran pengguna untuk mengubah atau memperluas prototipe, inovasi pengguna untuk menggunakan
sistem dengan cara yang benar-benar baru, dan rencana revisi untuk prototipe yang membantu dalam menetapkan
prioritas.
Aspek ketiga dari peran pengguna dalam pembuatan prototipe adalah kesediaan mereka untuk menyarankan
penambahan atau penghapusan dari fitur yang dicoba. Peran analis adalah untuk mendapatkan saran tersebut dengan
meyakinkan pengguna bahwa umpan balik yang mereka berikan dianggap serius, dengan mengamati pengguna saat
mereka berinteraksi dengan sistem, dan dengan melakukan wawancara singkat dan spesifik dengan pengguna mengenai
pengalaman mereka dengan prototipe. Meskipun pengguna akan diminta untuk mengartikulasikan saran dan inovasi untuk
prototipe, pada akhirnya adalah tanggung jawab analis untuk mempertimbangkan umpan balik ini dan menerjemahkannya
ke dalam perubahan yang dapat diterapkan jika diperlukan. Untuk memfasilitasi proses pembuatan prototipe, analis harus
dengan jelas mengomunikasikan tujuan pembuatan prototipe kepada pengguna, bersama dengan gagasan bahwa
pembuatan prototipe hanya berharga ketika pengguna terlibat secara bermakna.
Gambar 6.3
Langkah penting dalam pembuatan prototipe
adalah merekam pengguna dengan benar

Formulir Evalua
Nama Pengamat si Prototipe reaksi, saran pengguna,
Michael Cerveris
Nama Sistem ata
inovasi, dan rencana revisi.
u Proyek Tanggal
1/06/2013
Pusat Data Komp Perusahaan ata
utasi Awan u Lokasi
Nama atau Nomo
r Program Filter Air Aquariu
sebelumnya Perta
hankan.
s
Versi: kapan
Nama pengguna
Pengguna 1
Pengguna 2
1
Andi H. Pengguna 3
Periode Diamati Pam H. Pengguna 4
1/06/2013
Reaksi Pengguna 1/06/2013
Umumnya
Bagus sekali!
baik,
menjadi bersema
ngat
tentang proyek
Saran Penggun
a Tambahkan tang
gal
Tempatkan form
ulir
ketika nomor pem
eliharaan di ata
dilakukan. s
sebagai referen
si.
Tempat kata
MINGGUAN dala
m judu
Inovasi l.
Rencana Revisi
Ubah aktif
1/08/2013
Tinjau dengan
Andy dan Pam.
Pemodelan Agile
Metode tangkas adalah kumpulan pendekatan inovatif yang berpusat pada pengguna untuk pengembangan
sistem. Anda akan mempelajari nilai dan prinsip, aktivitas, sumber daya, praktik, proses, dan alat yang
terkait dengan metodologi tangkas di bagian mendatang. Metode tangkas dapat dikreditkan dengan banyak
proyek pengembangan sistem yang sukses dan, dalam banyak kasus, bahkan dikreditkan dengan
menyelamatkan perusahaan dari sistem yang gagal yang dirancang menggunakan metodologi terstruktur.
Nilai dan Prinsip Pemodelan Agile

Pendekatan tangkas tidak hanya didasarkan pada hasil. Ini didasarkan pada nilai, prinsip, dan praktik.
Penting untuk pemrograman tangkas adalah nilai dan prinsip yang dinyatakan yang menciptakan konteks
untuk kolaborasi antara programmer dan pelanggan. Untuk menjadi analis yang gesit, Anda harus
mematuhi nilai dan prinsip berikut seperti yang dikembangkan oleh Beck (2000) dalam karyanya tentang
pemodelan gesit yang ia sebut "pemrograman ekstrem," atau "XP."
EMPAT NILAI PEMODELAN TANGGUH. Ada empat nilai yang menciptakan lingkungan di mana pengembang dan bisnis
dapat dilayani secara memadai. Karena sering ada ketegangan antara apa yang dilakukan pengembang dalam
jangka pendek dan apa yang diinginkan secara komersial dalam jangka panjang, penting bagi Anda untuk secara
sadar mendukung nilai-nilai yang akan membentuk dasar untuk bertindak bersama dalam sebuah proyek perangkat
lunak. Keempat nilai tersebut adalah komunikasi, kesederhanaan, umpan balik, dan keberanian, seperti yang
ditunjukkan pada Gambar 6.4.
Mari kita mulai dengan komunikasi. Setiap usaha manusia penuh dengan kemungkinan miskomunikasi.
Proyek sistem yang memerlukan pembaruan terus-menerus dan desain teknis sangat rentan terhadap
kesalahan tersebut. Tambahkan ke tenggat waktu proyek yang ketat ini, jargon khusus, dan stereotip bahwa
programmer lebih suka berbicara dengan mesin daripada orang, dan Anda memiliki potensi untuk beberapa
masalah komunikasi yang serius. Proyek dapat ditunda, masalah yang salah dapat diselesaikan, pemrogram
dapat dihukum bahkan karena membawa masalah kepada manajer, orang dapat meninggalkan atau
bergabung dengan proyek di tengah jalan tanpa pembaruan yang tepat, dan begitulah litaninya.
Gambar 6.4
SSaya
MPaSC
kaSu
Tya
kay
aamu
Nilai sangat penting untuk ia
uSaHanay
CaAyT
naSm
pendekatan tangkas. Mk
M
ai
CH
h
Linca
Nilai k
AC
DB
Fee
CHkaR
aA
im
Geu
Praktik tangkas yang umum seperti pemrograman berpasangan (di mana dua pemrogram berkolaborasi,
dijelaskan nanti dalam bab ini), estimasi tugas, dan pengujian unit sangat bergantung pada komunikasi yang baik.
Masalah diperbaiki dengan cepat, lubang ditutup, dan pemikiran yang lemah dengan cepat diperkuat melalui
interaksi dengan orang lain dalam tim.
Nilai kedua dari pendekatan tangkas adalah kesederhanaan. Saat kami mengerjakan proyek pengembangan
perangkat lunak, kecenderungan pertama kami adalah menjadi kewalahan dengan kompleksitas dan besarnya
tugas. Namun, Anda tidak bisa berlari sampai Anda tahu cara berjalan, atau berjalan sampai Anda tahu cara berdiri.
Kesederhanaan untuk pengembangan perangkat lunak berarti memulai dengan hal paling sederhana yang dapat
kita lakukan.
Kesederhanaan nilai tangkas meminta kita untuk melakukan hal yang paling sederhana hari ini, dengan
pemahaman bahwa itu mungkin harus diubah sedikit besok. Ini membutuhkan fokus yang jelas pada tujuan proyek
dan benar-benar merupakan nilai dasar.
Umpan balik adalah nilai dasar ketiga yang penting ketika mengambil pendekatan pemrograman ekstrim.
Ketika Anda memikirkan umpan balik dalam konteks ini, ada baiknya untuk mempertimbangkan bahwa umpan balik
dibungkus dengan konsep waktu. Umpan balik yang baik dan konkret yang berguna bagi programmer, analis, dan
pelanggan dapat terjadi dalam hitungan detik, menit, hari, minggu, atau bulan, tergantung pada apa yang
dibutuhkan, siapa yang berkomunikasi, dan apa yang akan dilakukan dengan umpan balik tersebut. Rekan
programmer mungkin memberikan Anda sebuah test case yang memecahkan kode yang Anda tulis hanya beberapa
jam sebelumnya, tetapi umpan balik itu hampir tak ternilai harganya dalam hal mampu mengubah apa yang tidak
berfungsi sebelum diterima dan lebih jauh tertanam dalam sistem.
Umpan balik terjadi ketika pelanggan membuat tes fungsional untuk semua cerita yang kemudian
diimplementasikan oleh programmer. (Lihat lebih lanjut tentang cerita pengguna nanti di bab ini.) Umpan
balik kritis tentang jadwal datang dari pelanggan yang membandingkan tujuan rencana dengan kemajuan
yang telah dibuat. Umpan balik membantu pemrogram melakukan penyesuaian dan memungkinkan bisnis
mulai mengalami sangat awal tentang seperti apa sistem baru setelah berfungsi penuh.
Keberanian adalah nilai keempat dalam pemrograman tangkas. Keberanian berkaitan dengan tingkat
kepercayaan dan kenyamanan yang harus ada dalam sebuah tim pengembangan. Itu berarti tidak takut untuk
membuang program sore atau hari dan memulai lagi jika semuanya tidak benar. Ini berarti mampu tetap
berhubungan dengan naluri seseorang (dan hasil tes) mengenai apa yang berhasil dan apa yang tidak.
Keberanian juga berarti menanggapi umpan balik yang nyata, bertindak berdasarkan firasat rekan tim Anda ketika
mereka percaya bahwa mereka memiliki cara yang lebih sederhana dan lebih baik untuk mencapai suatu tujuan. Keberanian
adalah nilai risiko tinggi dan imbalan tinggi yang mendorong eksperimen yang dapat membawa tim ke tujuannya lebih cepat,
dengan cara yang inovatif. Keberanian berarti bahwa Anda dan rekan tim Anda cukup percaya satu sama lain dan pelanggan
Anda untuk bertindak dengan cara yang akan terus meningkatkan apa yang sedang dilakukan pada proyek, bahkan jika
mereka perlu membuang kode, memikirkan kembali solusi, atau pendekatan penyederhanaan lebih lanjut. Keberanian juga
menyiratkan bahwa Anda, sebagai analis sistem, dengan penuh semangat menerapkan praktik pendekatan tangkas.
Analis dapat mencerminkan keempat nilai terbaik melalui sikap kerendahan hati. Secara historis, perangkat
lunak komputer dikembangkan oleh para ahli yang sering berpikir bahwa mereka tahu cara menjalankan bisnis
lebih baik daripada pelanggan lokal yang merupakan pakar domain sejati. Pakar komputer sering disebut sebagai
"guru." Beberapa guru menunjukkan ego yang besar dan bersikeras pada kesempurnaan mereka, bahkan ketika
pelanggan tidak mempercayainya. Banyak guru tidak memiliki kebajikan kerendahan hati.
Namun, mempertahankan sikap rendah hati selama pengembangan sistem sangat penting. Anda
harus terus menerima gagasan bahwa jika pengguna mengungkapkan kesulitan, maka kesulitan itu harus
diatasi. Itu tidak bisa diabaikan. Pemodel tangkas adalah analis sistem yang membuat saran, menyuarakan
pendapat, tetapi tidak pernah bersikeras bahwa mereka benar 100 persen setiap saat. Pemodel gesit
Untuk Menetas Ikan
"J kita harus sedikit bersabar. Saya pikir kita perlu menambahkan
beberapa fitur lagi sebelum kita menyerahkannya kepada mereka. Jika tidak,
Wally menimpali, “Ya. Mengapa menunjukkan kesalahan kita kepada semua
orang? Selain itu, ketika mereka melihat prototipe, mereka akan melupakan keluhan
seluruh prototipe ini akan tenggelam, bukan berenang,” kata Sam Monroe, yang mereka miliki. Mereka akan menyukainya.”
anggota tim analisis sistem Anda. Keempat anggota tim duduk bersama Belle menemukan memo di buku catatannya dari pertemuan
dalam rapat yang disebut terburu-buru, dan mereka mendiskusikan prototipe terakhir mereka dengan manajer tempat penetasan dan membacanya
yang mereka kembangkan untuk sistem informasi untuk membantu manajer keras-keras. “Agenda pertemuan 22 September. 'Prototyping—
memantau dan mengontrol suhu air, jumlah ikan yang dilepaskan, dan faktor pentingnya pengembangan cepat, menyusun tim analis pengguna,
lainnya secara luas, pembenihan ikan komersial. mendapatkan umpan balik cepat untuk modifikasi. . . .'” Suara Belle
“Mereka sudah punya banyak yang harus dilakukan. Mengapa, sistem dimulai dengan menghilang, menghilangkan beberapa item agenda terakhir. Setelah
empat fitur dan kami sudah sampai sembilan. Saya merasa seperti kita berenang ke hulu komentarnya, Monroe dan Wally saling memandang dengan sedih.
yang satu ini. Mereka tidak membutuhkan semua itu. Mereka bahkan tidak Monroe berbicara lebih dulu: "Saya kira kami memang mencoba membuat
menginginkannya,” bantah Belle Uga, anggota kedua dari tim analisis sistem. “Saya tidak semua orang siap untuk menerima prototipe dengan cepat dan untuk terlibat sejak
bermaksud menggoreng, tetapi hanya memberi mereka dasar-dasarnya. Kami punya cukup hari pertama." Memperhatikan keheningan Anda sampai sekarang, Monroe
banyak untuk ditangani sebagaimana adanya.” melanjutkan, “Tetapi air tetap mengalir dalam. Menurutmu apa yang harus kita
“Saya pikir Monroe lebih tepat sasaran,” sukarelawan Wally Ide, anggota lakukan selanjutnya?” dia bertanya padamu.
ketiga tim, sedikit memancing Belle. “Kami harus menunjukkan yang terbaik Sebagai anggota keempat dari tim analisis sistem, menurut
kepada mereka, bahkan jika itu berarti beberapa minggu kemudian dalam Anda tindakan apa yang harus diambil? Dalam pesan email satu
menetaskan prototipe kami dari yang kami janjikan.” atau dua paragraf kepada rekan tim Anda, jawab pertanyaan
"Oke," kata Belle hati-hati, "tapi aku ingin kalian berdua memberi tahu berikut: Haruskah lebih banyak fitur ditambahkan ke prototipe
manajer di tempat penetasan mengapa kami tidak mengirimkan prototipe. sistem penetasan sebelum memberikannya kepada manajer
aku tidak mau. Dan aku tidak yakin mereka akan melepaskanmu semudah itu.” penetasan untuk bereksperimen? Seberapa penting
pengembangan prototipe yang cepat? Apa pertukaran yang terlibat
Monroe menjawab, “Yah, saya kira kita bisa, tetapi kita mungkin tidak dalam menambahkan lebih banyak fitur ke prototipe versus
perlu mempermasalahkan keterlambatan dari yang kita inginkan. Saya tidak mendapatkan prototipe yang lebih mendasar kepada klien ketika
ingin mengguncang perahu.” dijanjikan? Lengkapi pesan Anda dengan rekomendasi.
memiliki kepercayaan diri untuk memungkinkan pelanggan mereka bertanya, mengkritik, dan terkadang mengeluh
tentang sistem yang sedang dikembangkan. Analis belajar dari pelanggan mereka, yang telah lama berkecimpung
dalam bisnis.
PRINSIP DASAR PEMODELAN AGILE. Di dunia yang sempurna, pelanggan dan tim pengembangan perangkat lunak akan
saling berhadapan, dan komunikasi tidak diperlukan. Kita semua akan setuju setiap saat. Tapi kita tahu bahwa dunia
yang ideal itu tidak ada. Jadi bagaimana kita bisa membawa proyek pengembangan perangkat lunak kita lebih dekat
ke ideal? Bagian dari mengapa hal ini tidak akan terjadi adalah bahwa sejauh ini kami mencoba untuk beroperasi
pada sistem nilai-nilai bersama yang tidak jelas. Mereka adalah awal yang baik, tetapi mereka benar-benar tidak
dioperasionalkan ke titik di mana kita dapat mengukur kesuksesan kita dengan cara apa pun yang berarti. Jadi kami
bekerja untuk mendapatkan prinsip dasar yang dapat membantu kami memeriksa apakah apa yang kami lakukan
dalam proyek perangkat lunak kami benar-benar sesuai dengan nilai yang kami bagikan.
Prinsip Agile adalah cerminan dan spesifikasi dari nilai Agile. Mereka berfungsi sebagai pedoman bagi
pengembang untuk diikuti ketika mengembangkan sistem. Mereka juga berfungsi untuk mengatur
metodologi tangkas selain dari metodologi berbasis rencana yang lebih tradisional seperti SDLC serta
metodologi berorientasi objek.
Prinsip Agile pertama kali dijelaskan oleh Beck dan telah berkembang sejak saat itu. Prinsip-prinsip ini dapat
diungkapkan dalam serangkaian ucapan seperti:
1. Memuaskan pelanggan melalui pengiriman perangkat lunak yang berfungsi.

2. Merangkul perubahan, bahkan jika diperkenalkan terlambat dalam pengembangan.
3. Terus memberikan perangkat lunak yang berfungsi secara bertahap dan sering.
4. Dorong pelanggan dan analis untuk bekerja sama setiap hari.
5. Percayai individu yang termotivasi untuk menyelesaikan pekerjaan.
6. Promosikan percakapan tatap muka.

7. Berkonsentrasilah untuk membuat perangkat lunak berfungsi.
8. Mendorong pembangunan yang berkesinambungan, teratur, dan berkelanjutan.
9. Mengadopsi kelincahan dengan memperhatikan desain yang penuh perhatian.
10. Mendukung tim yang mengatur diri sendiri.
11. Memberikan umpan balik yang cepat.
12. Mendorong kualitas.

13. Tinjau dan sesuaikan perilaku sesekali.
14. Mengadopsi kesederhanaan.
Seringkali Anda akan mendengar pengembang yang gesit mengomunikasikan poin mereka melalui ucapan
seperti ini atau bahkan frasa yang lebih sederhana, seperti "model dengan tujuan", "perangkat lunak adalah tujuan
utama Anda", dan "ringan perjalanan", cara untuk mengatakan sedikit dokumentasi itu baik. cukup. Dengarkan ini
dengan seksama. Ucapan-ucapan ini (beberapa menyebutnya peribahasa) dibahas lebih lanjut dalam Bab 16. Frase
yang menarik mudah dipahami, mudah dihafal, dan mudah diulang. Mereka sangat efektif.
Aktivitas, Sumber Daya, dan Praktik Pemodelan Agile

Pemodelan tangkas melibatkan sejumlah kegiatan yang perlu diselesaikan selama proses
pengembangan tangkas. Bagian ini membahas aktivitas ini, sumber daya, dan praktik
yang unik untuk pendekatan tangkas.
EMPAT AKTIVITAS DASAR PENGEMBANGAN AGILE. Metode tangkas menggunakan empat aktivitas dasar:
pengembangan: pengkodean, pengujian, mendengarkan, dan merancang. Seorang analis tangkas perlu mengidentifikasi
jumlah usaha yang akan masuk ke setiap aktivitas dan menyeimbangkannya dengan sumber daya yang dibutuhkan untuk
menyelesaikan proyek.
Pengkodean ditetapkan sebagai satu-satunya aktivitas yang tidak mungkin dilakukan tanpanya. Seorang
penulis menyatakan bahwa hal paling berharga yang kami terima dari kode adalah “belajar.” Prosesnya pada
dasarnya adalah ini: Pikirkan, beri kode, uji, dan lihat apakah pemikiran itu logis. Kode juga dapat digunakan untuk
mengkomunikasikan ide-ide yang akan tetap kabur atau tidak berbentuk. Ketika saya melihat kode Anda, saya
mungkin mendapatkan pemikiran baru. Kode sumber adalah dasar untuk sistem yang hidup. Hal ini penting untuk
pembangunan.
Pengujian adalah kegiatan dasar kedua pengembangan. Pendekatan tangkas memandang pengujian otomatis
sebagai hal yang penting. Pendekatan tangkas menganjurkan tes menulis untuk memeriksa pengkodean,
fungsionalitas, kinerja, dan kesesuaian. Pemodelan tangkas bergantung pada pengujian otomatis, dan
perpustakaan pengujian yang besar tersedia untuk sebagian besar bahasa pemrograman. Tes ini perlu diperbarui
seperlunya selama kemajuan proyek.
Ada alasan jangka panjang dan jangka pendek untuk pengujian. Pengujian dalam jangka pendek memberi Anda
kepercayaan diri yang luar biasa pada apa yang Anda bangun. Jika tes berjalan dengan sempurna, Anda dapat melanjutkan
dengan keyakinan baru. Dalam jangka panjang, pengujian membuat sistem tetap hidup dan memungkinkan Anda membuat
perubahan lebih lama daripada yang mungkin jika tidak ada pengujian yang ditulis atau dijalankan.
Kegiatan dasar perkembangan yang ketiga adalah mendengarkan. Dalam Bab 4, kita belajar tentang pentingnya
mendengarkan selama wawancara. Dalam pendekatan tangkas, mendengarkan dilakukan secara ekstrim. Pengembang
menggunakan mendengarkan aktif untuk mendengar mitra pemrograman mereka. Dalam pemodelan tangkas, ada sedikit
ketergantungan pada komunikasi formal dan tertulis, sehingga mendengarkan menjadi keterampilan yang terpenting.
Pengembang juga menggunakan mendengarkan aktif dengan pelanggan. Pengembang berasumsi bahwa mereka
tidak tahu apa-apa tentang bisnis yang mereka bantu, sehingga mereka harus mendengarkan dengan cermat para pebisnis
untuk mendapatkan jawaban atas pertanyaan mereka. Seorang pengembang perlu memahami apa itu mendengarkan yang
efektif. Jika Anda tidak mendengarkan, Anda tidak akan tahu apa yang harus Anda kode atau apa yang harus Anda uji.
Kegiatan dasar keempat dalam pengembangan adalah merancang, yaitu cara membuat struktur untuk
mengatur semua logika dalam sistem. Merancang adalah evolusi, dan sistem yang dirancang menggunakan
pendekatan tangkas dikonseptualisasikan sebagai berkembang, selalu dirancang.
Desain yang baik seringkali sederhana. Desain harus memungkinkan fleksibilitas juga. Merancang dengan baik
memungkinkan Anda untuk membuat ekstensi ke sistem dengan membuat perubahan hanya di satu tempat. Desain
yang efektif menempatkan logika di dekat data yang akan dioperasikan. Di atas segalanya, desain harus berguna
bagi semua orang yang akan membutuhkannya saat upaya pengembangan berlangsung, termasuk pelanggan dan
pemrogram.
EMPAT VARIABEL KONTROL SUMBER DAYA PEMODELAN AGILE. Menyelesaikan semua kegiatan di
sebuah proyek tepat waktu dalam semua kendala adalah mengagumkan, tetapi, seperti yang mungkin telah Anda
sadari sekarang, untuk mencapai ini, manajemen proyek sangat penting. Mengelola proyek tidak berarti hanya
mengumpulkan semua tugas dan sumber daya. Ini juga berarti bahwa analis dihadapkan pada sejumlah trade-off.
Kadang-kadang biaya dapat ditentukan sebelumnya, dan pada saat-saat lain waktu mungkin menjadi faktor yang
paling penting. Variabel kontrol sumber daya ini (waktu, biaya, kualitas, dan ruang lingkup) dibahas selanjutnya.
WAKTU. Anda perlu memberikan waktu yang cukup untuk menyelesaikan proyek. Waktu, bagaimanapun, dibagi menjadi banyak bagian yang
terpisah. Anda perlu waktu untuk mendengarkan pelanggan, waktu untuk mendesain, waktu untuk membuat kode, dan waktu untuk menguji.
Salah satu teman kami adalah pemilik restoran Cina. Baru-baru ini, ia mendapati dirinya kekurangan staf
karena salah satu anggota kru andalnya kembali ke Hong Kong untuk menikah. Pemiliknya menempatkan dirinya di
dapur sehingga makanan disajikan tepat waktu, tetapi dia berhenti menyapa pelanggannya di depan dengan cara
biasa. Dia mengorbankan aktivitas mendengarkan untuk mencapai aktivitas lain, tetapi dalam kasus ini dia
menemukan bahwa itu merugikan bisnisnya. Pelanggan menginginkan perhatian.
Demikian pula dalam pengembangan sistem. Anda dapat membuat perangkat lunak berkualitas tetapi gagal mendengarkan.
Anda dapat merancang sistem yang sempurna tetapi tidak memberikan cukup waktu untuk mengujinya. Waktu sulit diatur. Jika Anda
menemukan diri Anda kehabisan waktu, apa yang Anda lakukan?
Pendekatan tangkas menantang gagasan bahwa lebih banyak waktu akan memberi Anda hasil yang Anda
inginkan. Mungkin pelanggan lebih suka Anda menyelesaikan tepat waktu daripada memperpanjang tenggat waktu
untuk menambahkan fitur lain. Pelanggan, kami sering menemukan, senang jika beberapa fungsi aktif dan berjalan
tepat waktu. Pengalaman kami menunjukkan bahwa seringkali pelanggan 80 persen puas dengan 20 persen
fungsionalitas pertama. Ini berarti bahwa ketika Anda menyelesaikan 80 persen akhir proyek, pelanggan mungkin
hanya sedikit lebih bahagia daripada dia setelah Anda menyelesaikan 20 persen pertama. Pesan di sini adalah
berhati-hatilah untuk tidak memperpanjang tenggat waktu Anda. Pendekatan tangkas bersikeras menyelesaikan
tepat waktu.
BIAYA. Biaya adalah variabel kedua yang dapat kita pertimbangkan untuk disesuaikan. Misalkan aktivitas pengkodean,
perancangan, pengujian, dan mendengarkan membebani proyek, dan sumber daya yang kita masukkan ke dalam waktu,
ruang lingkup, dan kualitas tidak cukup, bahkan dengan jumlah normal yang dikhususkan untuk biaya, untuk
menyeimbangkan proyek. Pada dasarnya kita mungkin diminta untuk menyumbangkan lebih banyak sumber daya yang
membutuhkan uang untuk menyeimbangkan proyek.
Cara termudah untuk meningkatkan pengeluaran (dan karenanya biaya) adalah dengan mempekerjakan lebih banyak
orang. Ini mungkin tampak sebagai solusi sempurna. Jika kami mempekerjakan lebih banyak programmer, kami akan
menyelesaikan lebih cepat. Benar? Belum tentu. Bayangkan mempekerjakan dua orang untuk memperbaiki atap dan
menambah jumlah itu menjadi empat. Tak lama kemudian, orang-orang saling berbenturan. Selanjutnya, mereka perlu
saling bertanya apa yang masih perlu dilakukan. Dan jika ada badai petir, tidak ada yang akan bekerja. Pergi dari dua ke
empat tidak berarti itu akan memakan waktu setengah. Pertimbangkan peningkatan yang diperlukan dalam komunikasi dan
biaya tidak berwujud lainnya ketika Anda mempertimbangkan untuk mempekerjakan lebih banyak orang. Ingatlah bahwa
ketika orang baru bergabung dengan sebuah tim, mereka tidak mengetahui proyek atau tim tersebut. Mereka akan
memperlambat anggota asli karena anggota asli harus mencurahkan waktu untuk mempercepat anggota baru.
Lembur juga tidak banyak membantu. Ini meningkatkan biaya, tetapi produktivitas tidak selalu mengikuti. Pemrogram
yang lelah kurang efektif daripada pemrogram yang waspada. Pemrogram yang lelah membutuhkan waktu lama untuk
menyelesaikan tugas, dan mereka juga membuat kesalahan yang bahkan lebih memakan waktu untuk diperbaiki.
Apakah ada hal lain yang dapat kami gunakan untuk memfasilitasi penyelesaian proyek? Mungkin. Di bab lain,
Anda akan membaca tentang berbagai alat yang mendukung analis dan pemrogram. Alat-alat ini seringkali
merupakan investasi yang bijaksana. Analis, misalnya, menggunakan paket grafis seperti Microsoft Visio untuk
mengkomunikasikan ide tentang proyek kepada orang lain, dan alat CASE seperti Analis Terlihat juga membantu
mempercepat proyek.
Bahkan perangkat keras baru bisa menjadi pengeluaran yang berharga. Laptop dan smartphone
meningkatkan produktivitas jauh dari kantor. Tampilan visual yang lebih besar, keyboard dan mouse
berkemampuan Bluetooth, serta kartu grafis yang lebih kuat juga dapat meningkatkan produktivitas.
KUALITAS. Variabel kontrol sumber daya ketiga adalah kualitas. Jika sistem ideal itu sempurna, mengapa begitu banyak usaha
yang dilakukan untuk memelihara sistem? Apakah kita sudah mempraktikkan pengembangan tangkas dengan
mengorbankan kualitas dalam pengembangan perangkat lunak? Dalam Bab 16 kita akan melihat pentingnya kualitas dan
metode (seperti TQM dan Six Sigma) yang membantu memastikan bahwa kualitas perangkat lunak tinggi.
Filosofi tangkas, bagaimanapun, memungkinkan seorang analis untuk menyesuaikan sumber daya kualitas dan
mungkin menempatkan lebih sedikit usaha untuk mempertahankan kualitas daripada yang diharapkan. Kualitas dapat
disesuaikan baik secara internal maupun eksternal. Kualitas internal melibatkan pengujian perangkat lunak untuk faktor-
faktor seperti fungsionalitas (Apakah suatu program melakukan apa yang seharusnya dilakukan?) dan kesesuaian (Apakah
perangkat lunak memenuhi standar kesesuaian tertentu, dan apakah dapat dipelihara?). Biasanya tidak ada gunanya
mengotak-atik kualitas internal.
Itu meninggalkan kita dengan kualitas eksternal, atau bagaimana pelanggan memandang sistem. Pelanggan tertarik
pada kinerja. Beberapa pertanyaan yang mungkin diajukan pelanggan adalah: Apakah program bekerja dengan andal (atau
apakah bug perangkat lunak masih ada)? Apakah outputnya efektif? Apakah output mencapai saya tepat waktu? Apakah
perangkat lunak berjalan dengan mudah? Apakah antarmuka pengguna mudah dipahami dan digunakan?
Filosofi ekstrim dari pengembangan tangkas memungkinkan beberapa masalah kualitas eksternal
dikorbankan. Agar sistem dapat dirilis tepat waktu, pelanggan mungkin harus menghadapi beberapa bug perangkat
lunak. Jika kami ingin memenuhi tenggat waktu kami, antarmuka pengguna mungkin tidak sempurna. Kami dapat
membuatnya lebih baik dalam versi lanjutan.
Produsen perangkat lunak komersial yang siap pakai memang mengorbankan kualitas, dan masih bisa
diperdebatkan apakah ini pendekatan yang baik. Pengembang mungkin menggunakan pemrograman ekstrem
sebagai salah satu praktik gesit mereka, jadi jangan heran ketika aplikasi perangkat lunak PC Anda (belum lagi
sistem operasi dan browser Web Anda) sering diperbarui.
CAKUPAN. Akhirnya, ada ruang lingkup. Dalam pendekatan tangkas, ruang lingkup ditentukan dengan
mendengarkan pelanggan dan membuat mereka menuliskan cerita mereka. Kemudian cerita diperiksa untuk
melihat berapa banyak yang bisa dilakukan dalam waktu tertentu untuk memuaskan pelanggan. Cerita harus
singkat dan mudah dipahami. Cerita akan dijelaskan lebih rinci nanti dalam bab ini, tetapi berikut adalah contoh
singkat yang menunjukkan empat cerita pendek dari sistem perjalanan udara online. Setiap cerita ditampilkan
dalam huruf tebal:
Tampilkan penerbangan alternatif.
Siapkan daftar lima penerbangan termurah.
Menawarkan alternatif yang lebih murah.
Sarankan kepada pelanggan agar mereka bepergian di hari lain, menginap di akhir pekan, mengikuti promosi khusus,
atau menggunakan bandara alternatif.
Beli tiket.
Izinkan pelanggan untuk membeli tiket secara langsung menggunakan kartu kredit (periksa validitasnya).
Biarkan pelanggan memilih tempat duduknya.

Arahkan pelanggan ke tampilan visual pesawat dan minta pelanggan untuk memilih tempat
duduk.
Idealnya, analis akan dapat menentukan berapa banyak waktu dan uang yang dibutuhkan untuk
menyelesaikan setiap cerita ini dan akan dapat menetapkan tingkat kualitas untuk mereka juga. Jelas bahwa
sistem ini tidak boleh mengorbankan kualitas, atau pembelian kartu kredit mungkin tidak valid atau
pelanggan dapat muncul di bandara tanpa reservasi.
Sekali lagi, praktik tangkas memungkinkan tindakan ekstrem, jadi untuk menjaga kualitas, mengelola
biaya, dan menyelesaikan proyek tepat waktu, analis tangkas mungkin ingin menyesuaikan ruang lingkup
proyek. Ini dapat dicapai dengan menyetujui dengan pelanggan bahwa satu atau lebih cerita dapat ditunda
hingga versi perangkat lunak berikutnya. Misalnya, mungkin fungsi mengizinkan pelanggan untuk memilih
kursi mereka sendiri dapat ditunda untuk lain waktu.
Singkatnya, seorang analis tangkas dapat mengontrol salah satu dari empat variabel sumber daya waktu,
biaya, kualitas, dan ruang lingkup. Kelincahan membutuhkan tindakan ekstrem dan sangat mementingkan
penyelesaian proyek tepat waktu. Dalam melakukannya, pengorbanan harus dilakukan dan analis yang gesit akan
menemukan bahwa pertukaran yang tersedia melibatkan keputusan yang sulit.
EMPAT PRAKTIK TANGGUH INTI. Empat praktik inti secara nyata membedakan pendekatan tangkas dari
pendekatan lain: rilis singkat, minggu kerja 40 jam, menjamu pelanggan di tempat, dan menggunakan
pemrograman berpasangan:
1. Rilis singkat berarti bahwa tim pengembangan memampatkan waktu antara rilis
produk. Daripada merilis versi lengkap dalam setahun, menggunakan rilis pendek
KESEMPATAN KONSULTASI 6.4
Prototipe Ini Semua Basah
"SAYA
t dapat diubah. Ini bukan produk jadi, ingat,” tegas Sandy Lather telah mengatakan kepadanya bahwa itu benar. Mereka membutuhkan laporan, dan mereka tidak
Beach, analis sistem untuk RainFall, produsen besar bak mandi mendapatkannya.
fiberglass dan penutup pancuran untuk kamar mandi. Beach Kemudian di minggu ini Sandy mendekati Lather tentang
dengan cemas meyakinkan Will Lather, penjadwal produksi untuk merutekan ulang output serta mengubah beberapa fitur sistem.
RainFall, yang sedang meneliti output hard-copy pertama yang Modifikasi ini akan memungkinkan Lather mendapatkan jawaban di
diproduksi untuknya oleh prototipe sistem informasi baru. layar mengenai skenario bagaimana-jika tentang perubahan harga yang
"Yah, tidak apa-apa," kata Lather pelan. “Aku tidak ingin mengganggumu dibebankan pemasok atau perubahan peringkat kualitas bahan baku
dengan apa pun. Ayo lihat, . . . Ya,di sini mereka,” katanya saat dia akhirnya yang tersedia dari pemasok (atau keduanya), serta memungkinkannya
menemukan laporan bulanan yang merangkum bahan baku yang dibeli, untuk melihat apa yang akan terjadi jika pengiriman terlambat.
bahan baku yang digunakan, dan bahan baku dalam persediaan. Lather tampak kesal dengan saran Sandy untuk mengubah
Busa melanjutkan paging melalui cetakan komputer yang berat. "Ini akan prototipe dan outputnya. “Oh, jangan lakukan itu di akunku. Tidak apa-
baik-baik saja." Berhenti sejenak di sebuah laporan, dia berkomentar, "Saya apa kok. Saya tidak keberatan mengambil tanggung jawab untuk
akan meminta Nona Fawcett menyalin bagian ini untuk orang-orang di merutekan informasi kepada orang-orang. Aku selalu menghujani
Akuntansi." Membalik beberapa halaman lagi, dia berkata, “Dan orang di mereka dengan barang-barang. Sungguh, ini bekerja dengan cukup
Quality Assurance harus benar-benar melihat kolom angka ini, meskipun baik. Saya tidak suka Anda mengambilnya dari kami saat ini. Biarkan saja
sisanya tidak terlalu menarik baginya. Saya akan melingkari dan membuat di tempatnya. ”
salinannya untuknya. Mungkin saya harus menelepon bagian ini ke gudang Sandy senang bahwa Lather tampak sangat puas dengan hasil prototipe,
juga. ” tetapi dia prihatin dengan keengganan Lather untuk mengubah prototipe,
Saat Sandy bersiap untuk pergi, Lather menyatukan halaman-halaman laporan, karena dia telah mendorong pengguna untuk menganggapnya sebagai
berkomentar, “Sistem baru akan sangat membantu. Saya akan memastikan semua produk yang berkembang, bukan produk yang sudah jadi.
orang tahu tentang itu. Bagaimanapun, apa pun akan lebih baik daripada 'monster Tulis laporan singkat kepada Sandy yang mencantumkan perubahan
tua'. Saya senang kami memiliki sesuatu yang baru.” pada prototipe yang dipicu oleh reaksi Lather. Dalam sebuah paragraf,
Sandy meninggalkan kantor Will Lather dengan perasaan sedikit tersesat di diskusikan cara Sandy dapat menenangkan ketakutan Lather tentang
laut. Memikirkannya, dia mulai bertanya-tanya mengapa Akuntansi, Jaminan prototipe yang "diambil". Diskusikan dalam sebuah paragraf beberapa
Kualitas, dan gudang tidak mendapatkan apa yang menurut Will seharusnya. Sandy tindakan yang dapat dilakukansebelum prototipe dicoba untuk
menelepon beberapa orang, dan dia menegaskan bahwa apa— mempersiapkan pengguna untuk sifat evolusionernya.
praktiknya, mereka akan mempersingkat waktu rilis dengan menangani fitur yang paling penting terlebih dahulu, merilis
sistem atau produk tersebut, dan kemudian memperbaikinya nanti.
2. Empat puluh jam kerja dalam seminggu berarti bahwa tim pengembangan yang gesit dengan sengaja
mendukung praktik inti budaya di mana tim bekerja sama secara intens selama 40 jam kerja dalam seminggu.
Sebagai akibat wajar dari praktik ini, budaya tersebut memperkuat gagasan bahwa bekerja lembur selama
lebih dari seminggu berturut-turut sangat buruk bagi kesehatan proyek dan pengembang. Latihan inti ini
mencoba memotivasi anggota tim untuk bekerja secara intens di tempat kerja, dan kemudian mengambil cuti
sehingga ketika mereka kembali, mereka santai dan tidak terlalu stres. Ini membantu anggota tim
menemukan masalah dengan lebih mudah, dan mencegah kesalahan dan kelalaian yang mahal karena kinerja
yang tidak efektif atau kelelahan.
3. Pelanggan di tempat berarti bahwa pengguna yang ahli dalam aspek bisnis dari pekerjaan pengembangan sistem
berada di tempat selama proses pengembangan. Orang ini merupakan bagian integral dari proses, menulis cerita
pengguna, berkomunikasi dengan anggota tim, membantu memprioritaskan dan menyeimbangkan kebutuhan bisnis
jangka panjang, dan membuat keputusan tentang fitur mana yang harus ditangani terlebih dahulu.
4. Pemrograman berpasangan adalah praktik inti yang penting. Ini berarti Anda bekerja dengan programmer lain
yang Anda pilih sendiri. Anda berdua melakukan pengkodean, Anda berdua menjalankan tes. Seringkali orang
senior akan memimpin pengkodean pada awalnya, tetapi ketika orang junior terlibat, siapa pun yang memiliki
visi yang jelas tentang tujuan biasanya akan melakukan pengkodean untuk saat ini. Ketika Anda meminta
orang lain untuk bekerja dengan Anda, protokol pemrograman berpasangan mengatakan bahwa dia
berkewajiban untuk menyetujui. Bekerja dengan programmer lain membantu Anda memperjelas pemikiran
Anda. Pasangan sering berubah, terutama selama tahap eksplorasi perkembangan
Gambar 6.5 Latihan Inti Agile
Praktik inti saling terkait dengan kamu

RWHRa
40-HHai kiW
ee
sumber daya, aktivitas, dan nilai Se k
kAu
eae
pemodelan tangkas. aTiR
HR
SH
aui
R
Me
SaTH
m
STe
a yCak
PA
SRaPyR HnASI
aHGaRA nG a
i MMSay
TeSTSa
nGya
a
iaGy
CHSaTi DaSn
CH
a
aey
TSM ya
SnaG
Teyna
u LSSa
m DeS
uaya SGanySa
naGya
STkak
Aaam
Qk
SCHPae
i
Aktivitas Agile
Sumber Daya Agile
SSaya
MPaSC
kaSu
Tyk
aaa
yamu
yia
uSaHana
CaAyT
Sm
kna
M
i
Ma
CH
k
AC
DB
Fee
CHkaR
aAGeu
im
Nilai Agile
proses. Pemrograman berpasangan menghemat waktu, mengurangi pemikiran yang ceroboh, memicu kreativitas, dan merupakan cara
yang menyenangkan untuk memprogram.
Bagaimana praktik agile inti saling terkait dan mendukung aktivitas, sumber daya, dan nilai pengembangan
agile ditunjukkan pada Gambar 6.5.
Proses Pengembangan Agile

Pemodelan adalah kata kunci dalam metode tangkas. Pemodelan tangkas memanfaatkan
kesempatan untuk membuat model. Ini dapat berupa model logis seperti gambar sistem, atau tiruan
seperti prototipe yang dijelaskan sebelumnya dalam bab ini. Proses pemodelan tangkas yang khas
akan berjalan seperti ini:
1. Dengarkan cerita pengguna dari pelanggan.

2. Gambarkan model alur kerja logis untuk mendapatkan apresiasi atas keputusan bisnis yang
direpresentasikan dalam cerita pengguna.
3. Buat cerita pengguna baru berdasarkan model logis.
4. Mengembangkan beberapa prototipe tampilan. Dengan melakukan itu, tunjukkan kepada pelanggan jenis antarmuka apa yang akan
mereka miliki.
5. Menggunakan umpan balik dari prototipe dan diagram alur kerja logis, kembangkan sistem
hingga Anda membuat model data fisik.
Agile adalah kata kunci lain dalam pemodelan tangkas. Agile menyiratkan kemampuan manuver. Sistem saat
ini, terutama yang berbasis Web, mengajukan tuntutan ganda: merilis perangkat lunak sesegera mungkin dan terus
meningkatkan perangkat lunak untuk menambahkan fitur baru. Seorang analis sistem harus memiliki kemampuan
dan metode untuk membuat aplikasi yang dinamis, peka konteks, skalabel, dan evolusioner. Oleh karena itu,
pemodelan tangkas adalah metode yang merangkul perubahan.
MENULIS CERITA PENGGUNA. Meskipun judul bagian ini adalah "Menulis Cerita Pengguna", penekanan dalam
pembuatan cerita pengguna adalah pada interaksi lisan antara pengembang dan pengguna, bukan komunikasi
tertulis. Dalam cerita pengguna, pengembang mencari yang pertama dan terutama untuk mengidentifikasi
kebutuhan pengguna bisnis yang berharga. Pengguna biasanya akan terlibat dalam percakapan setiap hari dengan
pengembang tentang arti cerita pengguna yang mereka tulis. Percakapan yang sering terjadi ini adalah interaksi
yang bertujuan yang bertujuan untuk mencegah kesalahpahaman atau salah tafsir tentang kebutuhan pengguna.
Oleh karena itu, cerita pengguna berfungsi sebagai pengingat bagi pengembang bahwa mereka harus mengadakan
percakapan yang ditujukan untuk persyaratan tersebut.
Berikut ini adalah contoh rangkaian cerita yang ditulis untuk aplikasi e-commerce untuk pedagang online
buku, CD, dan produk media lainnya. Cerita-cerita tersebut memberikan gambaran yang cukup lengkap tentang apa
yang dibutuhkan pada setiap tahapan dalam proses pembelian, tetapi cerita-cerita tersebut sangat singkat dan
mudah dipahami. Intinya di sini adalah untuk mendapatkan semua kebutuhan dan kekhawatiran toko online di
tempat terbuka. Meskipun tidak ada cukup cerita untuk memulai pemrograman, pengembang yang gesit mungkin
mulai melihat gambaran keseluruhan dengan cukup jelas untuk mulai memperkirakan apa yang diperlukan untuk
menyelesaikan proyek. Cerita-ceritanya adalah sebagai berikut:
Selamat datang pelanggan.
Jika pelanggan telah berada di situs ini sebelum menggunakan komputer yang sama, sambut
pelanggan kembali ke toko online.
Tampilkan spesial di beranda.
Tampilkan buku terbaru atau produk lain yang baru saja diperkenalkan. Jika pelanggan
diidentifikasi, sesuaikan rekomendasi untuk pelanggan tertentu itu.
Cari produk yang diinginkan.
Sertakan mesin pencari yang efektif yang akan menemukan produk tertentu dan produk serupa.
Tampilkan judul dan ketersediaan yang cocok.
Menampilkan hasil pencarian di halaman web baru.

Izinkan pelanggan untuk meminta detail yang lebih besar.
Tawarkan lebih banyak detail produk kepada pelanggan, seperti halaman contoh dalam buku, lebih banyak foto
produk, atau untuk memutar sebagian trek dari CD.
Menampilkan ulasan produk.

Bagikan komentar yang dimiliki pelanggan lain tentang produk.
Tempatkan produk ke dalam keranjang belanja.
Permudah pelanggan untuk mengklik tombol yang menempatkan produk ke dalam keranjang
belanja pembelian yang dimaksud.
Simpan riwayat pembelian di file.
Simpan detail tentang pelanggan dan pembeliannya dalam cookie di komputer pelanggan. Juga
menyimpan informasi kartu kredit untuk checkout lebih cepat.
Sarankan buku lain yang serupa.
Sertakan foto buku lain yang memiliki tema serupa atau ditulis oleh penulis yang sama.
Lanjutkan ke pembayaran.
Konfirmasi identitas pelanggan.

Tinjau pembelian.
Izinkan pelanggan untuk meninjau pembelian.
Lanjutkan Belanja.
Menawarkan pelanggan kesempatan untuk melakukan pembelian lebih lanjut pada waktu yang sama.
Terapkan metode pintasan untuk checkout lebih cepat.
Jika identitas pelanggan diketahui dan alamat pengiriman cocok, percepat

transaksi dengan menerima kartu kredit di file dan sisa preferensi pelanggan,
seperti metode pengiriman.
Tambahkan nama dan alamat pengiriman.
Jika pembelian adalah hadiah, izinkan pelanggan untuk memasukkan nama dan alamat penerima.
Kebutuhan atau Pelu

ang: Terapkan metode pint
asan untuk checkout lebih
cepat.
Cerita:
Jika identitas pelanggan
diketahui dan alama
transaksi dengan me t pengiriman cocok,
nerima kartu kredit di percepat
seperti metode pengirim file dan sisa preferens
an. i pelanggan
Di bawah ini Dibawah rata-rata
Kegiatan: Rata-rata Diatas rata-rata
Pengkodean Diatas rata rata
Pengujian
Mendengarkan
Merancang
Sumber daya:
Waktu
Biaya
Kualitas
Cakupan
Gambar 6.6
Cerita pengguna dapat direkam pada
kartu. Kisah pengguna harus cukup
Menawarkan pilihan untuk pengiriman.
singkat bagi seorang analis untuk
Memungkinkan pelanggan untuk memilih metode pengiriman berdasarkan biaya.
menentukan fitur sistem apa yang
dibutuhkan. Selesaikan transaksi.
Selesaikan transaksi. Mintalah konfirmasi kartu kredit jika alamat pengiriman berbeda dengan
alamat pelanggan yang tercatat.
Seperti yang dapat Anda lihat dengan mudah, tidak ada kekurangan cerita. Analis yang gesit perlu
memilih beberapa cerita, menyelesaikan pemrograman, dan merilis produk. Setelah ini selesai, lebih banyak
cerita dipilih dan versi baru dirilis sampai semua cerita dimasukkan ke dalam sistem (atau analis dan
pelanggan setuju bahwa cerita tertentu kurang bermanfaat atau tidak mendesak sehingga tidak perlu
disertakan).
Contoh cerita pengguna yang mungkin tampak bagi pengembang yang gesit ditunjukkan pada Gambar 6.6.
Pada kartu kertas (atau secara elektronik), seorang analis mungkin pertama-tama mengidentifikasi kebutuhan atau
peluang dan kemudian mengikutinya dengan deskripsi cerita singkat. Analis mungkin mengambil kesempatan
untuk mulai berpikir luas tentang kegiatan yang perlu diselesaikan serta sumber daya yang diperlukan untuk
menyelesaikan proyek. Dalam contoh dari pedagang online ini, analis menunjukkan bahwa aktivitas perancangan
akan membutuhkan upaya di atas rata-rata, dan waktu serta sumber daya berkualitas diperlukan untuk naik di atas
rata-rata. Perhatikan bahwa analis tidak mencoba untuk menjadi lebih tepat dari perkiraan saat ini, tetapi ini masih
merupakan latihan yang berguna.
SCRUM. Pendekatan tangkas lainnya bernama scrum. katascrum diambil dari posisi awal dalam rugby
di mana tim rugby membentuk kerumunan dan berjuang untuk menguasai bola. Scrum sebenarnya
tentang kerja sama tim, mirip dengan apa yang dibutuhkan dalam bermain rugby.
Sama seperti tim rugby akan datang ke permainan dengan strategi keseluruhan, tim pengembangan memulai
proyek dengan rencana tingkat tinggi yang dapat diubah dengan cepat saat "permainan" berlangsung. Anggota tim
pengembangan sistem menyadari bahwa keberhasilan proyek adalah yang paling penting, dan keberhasilan
individu mereka adalah yang kedua. Pemimpin proyek memiliki beberapa, tetapi tidak banyak, pengaruh pada
detail. Sebaliknya, permainan taktis diserahkan kepada anggota tim, seolah-olah mereka berada di lapangan. Tim
sistem bekerja dalam kerangka waktu yang ketat (30 hari untuk pengembangan), seperti halnya tim rugby akan
bermain dalam batasan waktu yang ketat dalam sebuah permainan.
Kami dapat menggambarkan komponen metodologi scrum sebagai:
1. Product backlog, di mana daftar berasal dari spesifikasi produk.

2. Sprint backlog, daftar tugas yang berubah secara dinamis untuk diselesaikan pada sprint berikutnya.
3. Sprint, periode 30 hari di mana tim pengembangan mengubah backlog menjadi perangkat lunak
yang dapat didemonstrasikan.
Gambar 6.7
Ada enam pelajaran penting yang dapat
Rilis singkat diambil dari pendekatan sistem yang
memungkinkan sistem
tangkas.
berkembang
Nilai tangkas adalah Pemrograman pasangan
penting untuk meningkatkan secara keseluruhan
kesuksesan kualitas
Pelajaran yang Didapat
dari Mengadopsi
Metode Agile
Sumber daya yang seimbang Pelanggan di tempat

dan kegiatan pendukung saling
tujuan proyek bermanfaat
40 jam
minggu kerja membaik
efektivitas
4. Daily scrum, pertemuan singkat di mana komunikasi adalah aturan nomor satu. Anggota tim perlu
menjelaskan apa yang mereka lakukan sejak pertemuan terakhir, apakah mereka menemui kendala,
dan apa yang mereka rencanakan sebelum scrum harian berikutnya.
5. Demo, software yang berfungsi yang dapat didemonstrasikan kepada pelanggan.
Scrum memang merupakan metodologi berintensitas tinggi. Ini hanyalah salah satu pendekatan yang
mengadopsi filosofi pemodelan tangkas.
Pelajaran yang Dipetik dari Pemodelan Agile

Sering diajukan sebagai cara alternatif untuk mengembangkan sistem, pendekatan tangkas berusaha
untuk mengatasi keluhan umum yang timbul tentang pendekatan SDLC tradisional (misalnya, terlalu
memakan waktu, berfokus pada data daripada manusia, terlalu mahal) dengan menjadi cepat,
berulang, fleksibel, dan partisipatif dalam menanggapi perubahan kebutuhan informasi manusia,
kondisi bisnis, dan lingkungan.
Beberapa proyek pengembangan tangkas telah dicatat dalam buku, artikel, dan di situs web.
Banyak dari mereka berhasil, beberapa gagal, tetapi kita dapat belajar banyak dari mempelajarinya,
serta nilai-nilai, prinsip, dan praktik inti yang tangkas. Berikut ini adalah enam pelajaran utama yang
kami ambil dari pemeriksaan model gesit kami. Gambar 6.7 menggambarkan enam pelajaran.
Pelajaran pertama adalah bahwa rilis singkat memungkinkan sistem untuk berevolusi. Pembaruan
produk sering dilakukan, dan perubahan dimasukkan dengan cepat. Dengan cara ini sistem diizinkan untuk
tumbuh dan berkembang dengan cara yang menurut pelanggan berguna. Melalui penggunaan rilis pendek,
tim pengembangan memampatkan waktu antara rilis produk mereka, meningkatkan produk nanti sesuai
tuntutan situasi dinamis.
Pelajaran kedua adalah bahwa pemrograman berpasangan meningkatkan kualitas secara keseluruhan. Meskipun
pemrograman berpasangan kontroversial, ini jelas mendorong kegiatan positif lainnya yang diperlukan dalam
pengembangan sistem seperti komunikasi yang baik, mengidentifikasi dengan pelanggan, berfokus pada aspek proyek yang
paling berharga terlebih dahulu, menguji semua kode saat dikembangkan, dan mengintegrasikan kode baru setelah berhasil
melewati pengujiannya.
Pelajaran ketiga adalah bahwa pelanggan di tempat saling menguntungkan bagi bisnis dan tim
pengembangan yang gesit. Pelanggan berfungsi sebagai referensi dan pemeriksaan realitas yang siap
pakai, dan fokus desain sistem akan selalu dipertahankan melalui kehadiran mereka: pelanggan menjadi
lebih seperti pengembang dan pengembang lebih berempati dengan pelanggan.
Pelajaran keempat yang kami ambil dari pendekatan tangkas adalah bahwa 40 jam kerja seminggu
meningkatkan efektivitas. Bahkan pengembang yang paling terpukul sekalipun rentan terhadap kesalahan dan
kelelahan jika mereka bekerja terlalu keras untuk waktu yang terlalu lama. Namun, ketika tim pengembangan
bersama, setiap momen penting. Bekerja dengan kecepatan yang berkelanjutan jauh lebih diinginkan untuk
kehidupan proyek, kehidupan sistem, dan kehidupan pengembang! Kita semua tahu perumpamaan kelinci dan kura-
kura.
Pelajaran kelima yang kami ambil dari mengambil pendekatan tangkas adalah bahwa sumber daya dan
aktivitas yang seimbang mendukung tujuan proyek. Mengelola proyek tidak berarti hanya mengumpulkan semua
sumber daya dan tugas. Ini juga berarti bahwa analis dihadapkan pada sejumlah trade-off. Kadang-kadang biaya
dapat ditentukan sebelumnya, pada saat-saat lain waktu mungkin menjadi faktor yang paling penting. Variabel
kontrol sumber daya waktu, biaya, kualitas, dan ruang lingkup harus benar-benar seimbang dengan aktivitas
pengkodean, perancangan, pengujian, dan mendengarkan.
Pelajaran terakhir yang kita ambil dari pendekatan pemodelan tangkas adalah bahwa nilai-nilai tangkas sangat penting
untuk kesuksesan. Sangat penting untuk keberhasilan keseluruhan proyek bahwa analis dengan sepenuh hati merangkul
nilai-nilai komunikasi, kesederhanaan, umpan balik, dan keberanian dalam semua pekerjaan yang mereka lakukan. Jenis
komitmen pribadi dan tim memungkinkan analis untuk berhasil di mana orang lain, yang memiliki kompetensi teknis yang
sama tetapi tidak memiliki nilai, akan gagal. Dedikasi sejati terhadap nilai-nilai ini merupakan dasar bagi keberhasilan
pembangunan.
Membandingkan Pemodelan Agile dan Metode Terstruktur

Seperti yang Anda lihat, metode tangkas dikembangkan dengan cepat, dilaporkan berhasil, dan pengguna adalah pelanggan
yang terlibat langsung. Meskipun benar bahwa proyek yang dikembangkan dengan menggunakan metode tangkas sering
kali memerlukan penyesuaian agar berfungsi dengan baik, pengembang tangkas mengakui bahwa penyesuaian adalah
bagian dari proses. Pendekatan tangkas menyiratkan banyak rilis pendek, dengan fitur yang ditambahkan di sepanjang jalan.
Meningkatkan Efisiensi dalam Pekerjaan Pengetahuan: SDLC Versus Agile

Peneliti Davis dan Naumann (1999) mengembangkan daftar tujuh strategi yang dapat meningkatkan
efisiensi kerja pengetahuan: mengurangi waktu antarmuka dan kesalahan, mengurangi waktu belajar
proses dan kerugian pemrosesan ganda, mengurangi waktu dan upaya untuk menyusun tugas dan
memformat output, mengurangi nonproduktif perluasan pekerjaan, mengurangi waktu dan biaya pencarian
dan penyimpanan data dan pengetahuan, mengurangi waktu dan biaya komunikasi dan koordinasi, dan
mengurangi kerugian akibat kelebihan informasi manusia. Para peneliti ini percaya ini penting karena,
berdasarkan studi mereka terhadap sekelompok programmer, mereka mengklaim bahwa programmer
terbaik 5 sampai 10 kali lebih produktif daripada yang terburuk. Mereka lebih lanjut menunjukkan rasio ini
hanya 2:1 untuk pekerja dalam tugas-tugas administrasi atau fisik. Saran mereka adalah bahwa perangkat
lunak dapat membantu memperbaiki banyak situasi.
Kami menggunakan standar, pendekatan pengembangan sistem tradisional metode terstruktur untuk
membandingkan dan kontras bagaimana pendekatan terstruktur versus metode tangkas akan menerapkan tujuh
strategi yang diusulkan untuk meningkatkan efisiensi pekerja pengetahuan.
Meskipun mengadopsi lebih banyak perangkat lunak memang dapat meningkatkan kinerja, masuk akal
untuk menyarankan bahwa mengubah pendekatan atau metodologi juga dapat meningkatkan kinerja.
Akibatnya, kami akan memeriksa setiap aspek produktivitas kerja pengetahuan melalui lensa dari
metodologi terstruktur dan tangkas. Gambar 6.8 mencantumkan tujuh strategi asli untuk peningkatan
produktivitas dan menjelaskan metode apa yang digunakan untuk meningkatkan efisiensi pengembangan
sistem untuk metodologi terstruktur dan tangkas.
Di bagian yang akan datang kita akan membandingkan dan membedakan pendekatan terstruktur dengan
pendekatan tangkas. Pengamatan menyeluruh tentang metodologi tangkas adalah bahwa itu adalah pendekatan
berorientasi manusia yang memungkinkan orang untuk membuat solusi bernuansa yang tidak mungkin dibuat
melalui spesifikasi proses formal.
MENGURANGI WAKTU DAN KESALAHAN ANTARMUKA. Analis dan pemrogram sistem perlu menganalisis, merancang, dan
mengembangkan sistem menggunakan alat kerja pengetahuan yang berkisar dari Microsoft Office hingga alat CASE
yang canggih dan mahal. Mereka juga perlu mendokumentasikan saat mereka mengembangkan sistem. Adalah
penting bahwa analis dan pemrogram mampu memahami antarmuka yang mereka gunakan. Mereka perlu tahu
bagaimana mengklasifikasikan, membuat kode, menyimpan, dan menulis tentang data yang mereka kumpulkan.
Strategi untuk Meningkatkan Implementasi Menggunakan Implementasi Menggunakan
Efisiensi dalam Pekerjaan Pengetahuan Metodologi Terstruktur Metodologi Agile
Kurangi waktu dan kesalahan antarmuka Mengadopsi standar organisasi untuk pengkodean, Mengadopsi pasangan
penamaan, dll.; menggunakan formulir pemrograman
Kurangi waktu pembelajaran proses dan Mengelola kapan pembaruan dirilis sehingga Pembuatan prototipe ad hoc
kerugian pemrosesan ganda pengguna tidak perlu mempelajari dan dan perkembangan pesat
menggunakan perangkat lunak secara bersamaan
Kurangi waktu dan upaya untuk menyusun Menggunakan alat dan diagram CASE; menggunakan Mendorong pendek
tugas dan memformat output kode yang ditulis oleh programmer lain rilis
Kurangi perluasan pekerjaan yang tidak Mengelola proyek; menetapkan Membatasi cakupan di
produktif tenggat waktu setiap rilis
Kurangi waktu dan biaya pencarian dan Menggunakan teknik pengumpulan Memungkinkan untuk
penyimpanan data dan pengetahuan data terstruktur, seperti wawancara, pelanggan di tempat
observasi, sampling
Mengurangi waktu dan biaya Memisahkan proyek menjadi tugas yang Timeboxing
komunikasi dan koordinasi lebih kecil; membangun hambatan
Mengurangi kerugian dari informasi Menerapkan teknik penyaringan untuk Berpegang teguh pada 40 jam
manusia yang berlebihan melindungi analis dan pemrogram pekan kerja
Gambar 6.8
Pengembang sistem juga perlu mengakses program dengan cepat, memasukkan informasi yang diperlukan, dan Bagaimana strategi Davis dan Naumann
mengambilnya kembali saat dibutuhkan lagi. untuk meningkatkan efisiensi
Pendekatan terstruktur mendorong adopsi standar untuk semuanya. Aturan yang ditetapkan termasuk dapat diimplementasikan menggunakan dua
item seperti "Google Chrome akan menjadi default di desktop kantor untuk menjelajah daripada Firefox." Mereka pendekatan pembangunan yang berbeda.
mungkin instruksi yang lebih rinci untuk memastikan data yang bersih, seperti "Selalu gunakan M untuk Pria dan F
untuk Wanita," sehingga memastikan bahwa analis tidak sembarangan memilih kode mereka sendiri, seperti 0
untuk Pria dan 1 untuk Wanita. Aturan-aturan ini kemudian menjadi bagian dari penyimpanan data. Formulir juga
berguna, mengharuskan semua personel untuk mendokumentasikan prosedur mereka sehingga pemrogram lain
mungkin dapat mengambil alih jika perlu.
Dalam pendekatan tangkas, formulir dan prosedur juga berfungsi dengan baik, tetapi elemen lain
ditambahkan. Latihan tambahan pemrograman berpasangan memastikan bahwa satu programmer akan
memeriksa pekerjaan yang lain, sehingga mengurangi jumlah kesalahan. Pemrograman berpasangan
berarti bahwa kepemilikan desain atau perangkat lunak itu sendiri dibagi dalam kemitraan. Kedua mitra
(biasanya satu programmer, seringkali senior) akan mengatakan bahwa mereka memilih mitra
pemrograman yang ingin memiliki produk berkualitas yang bebas dari kesalahan. Karena dua orang
mengerjakan desain dan kode yang sama, waktu antarmuka tidak menjadi masalah; merupakan bagian
integral dari proses. Davis dan Naumann telah mencatat bahwa programmer cukup emosional ketika topik
pemrograman pasangan dibahas.
MENGURANGI WAKTU PEMBELAJARAN PROSES DAN KERUGIAN DUAL PROCESSING. Analis dan
pemrogram mempelajari teknik khusus dan bahasa perangkat lunak yang diperlukan untuk penyelesaian proyek
saat ini. Inefisiensi sering terjadi ketika beberapa analis dan pemrogram sudah mengetahui produk yang digunakan
sementara yang lain masih perlu mempelajarinya. Sayangnya, perusahaan sering meminta pengembang sistem
untuk mempelajari aplikasi baru pada saat yang sama mereka menggunakan aplikasi ini untuk membangun sistem.
Pelatihan di tempat kerja ini sangat memperlambat keseluruhan proyek pengembangan sistem.
Sebuah proyek tradisional yang terstruktur membutuhkan lebih banyak pembelajaran. Jika alat CASE digunakan,
seorang analis mungkin perlu mempelajari alat CASE berpemilik yang digunakan dalam organisasi. Hal yang sama berlaku
untuk penggunaan bahasa komputer tertentu. Dokumentasi juga menjadi perhatian.
Menggunakan filosofi tangkas, kemampuan untuk meluncurkan proyek tanpa menggunakan alat CASE dan
dokumentasi terperinci memungkinkan analis dan pemrogram menghabiskan sebagian besar waktu mereka untuk
pengembangan sistem daripada mempelajari alat tertentu.
MENGURANGI WAKTU DAN UPAYA UNTUK STRUKTUR TUGAS DAN FORMAT OUTPUT. Kapanpun
proyek dimulai, pengembang perlu menentukan batas-batasnya. Dengan kata lain, para pengembang
170 bagian 2 • kebutuhan informasi
BANDING MAC
Sama seperti metodologi tangkas adalah alternatif untuk SDLC, OmniFocus adalah alternatif untuk Microsoft Project
dan pendekatan diagram Gantt atau diagram PERT lainnya.
Pengamat biasa mungkin berpikir bahwa metode tangkas tidak terstruktur karena sistem dibangun tanpa spesifikasi dan
dokumentasi yang terperinci. Seorang siswa metode tangkas menyadari bahwa sebenarnya ada sedikit struktur dalam
pendekatan tangkas. Prinsip-prinsipnya termasuk berpegang teguh pada 40 jam kerja seminggu dan koordinasi melalui
pemrograman berpasangan. Seorang analis yang mengadopsi teknik tangkas membutuhkan cara untuk menetapkan tujuan,
tetap dalam anggaran, menetapkan prioritas untuk fitur, dan menemukan cara untuk menyelesaikan sesuatu.
OmniFocus didasarkan pada sistem manajemen tugas alternatif oleh David Allen, yang disebut Getting Things Done.
Prinsip utamanya adalah membebaskan pikiran Anda dari mengingat hal-hal, sehingga Anda dapat berkonsentrasi untuk
menyelesaikannya. Seorang analis yang menggunakan sistem ini melewati lima tindakan: mengumpulkan, memproses,
mengatur, meninjau, dan melakukan.
Seorang analis sistem yang menggunakan OmniFocus mengumpulkan item dari browser Web-nya, buku alamat atau kalender, dan
sebagian besar aplikasi lain di Mac. Analis dapat mengkategorikan data atau menugaskannya ke proyek yang lebih besar. OmniFocus
berisi mode perencanaan sehingga analis dapat melihat tugas mana yang merupakan bagian dari proyek yang lebih besar dan mode
konteks yang mengatur tugas sehingga analis mengetahui semua tugas yang harus dilakukan baik melalui telepon, dengan menelusuri
Web, atau dengan menggunakan email. OmniFocus juga tersedia sebagai aplikasi iPhone.
Gambar 6.MAC
OmniFocus dari The Omni Group. (Bentuk tangkapan layar OmniFocus, merek dagang terdaftar yang
digunakan di bawah lisensi. Grafik dicetak ulang dengan izin dari Omni Group.)
perlu tahu apa yang akan dihasilkan dan bagaimana mereka akan mengatur proyek sehingga mereka dapat
menyelesaikan semua tugas yang diperlukan.
Pendekatan tradisional akan mencakup penggunaan alat CASE, menggambar diagram (seperti diagram ER dan
diagram aliran data), menggunakan perangkat lunak manajemen proyek (seperti Microsoft Project), menulis deskripsi
pekerjaan terperinci, menggunakan dan menggunakan kembali formulir dan templat, dan menggunakan kembali kode yang
ditulis oleh programmer lainnya.
Pengembangan sistem menggunakan pendekatan tangkas menjawab kebutuhan untuk menyusun tugas dengan
menjadwalkan rilis singkat. Filosofi tangkas menunjukkan bahwa pengembang sistem membuat serangkaian
tenggat waktu untuk banyak rilis sistem. Rilis pertama akan memiliki lebih sedikit fitur, tetapi, dengan
setiap rilis baru, fitur tambahan akan ditambahkan.
MENGURANGI EKSPANSI KERJA NONPRODUKTIF. Hukum parkinson menyatakan bahwa "kerja"

mengembang untuk mengisi waktu yang tersedia untuk penyelesaiannya.” Jika tidak ada tenggat waktu yang ditentukan, ada
kemungkinan pekerjaan pengetahuan akan terus berkembang.
Dengan metodologi terstruktur tradisional, tenggat waktu pada awalnya tampak jauh di masa depan. Analis dapat
menggunakan teknik manajemen proyek untuk mencoba menjadwalkan kegiatan, tetapi ada bias bawaan untuk
memperpanjang tugas sebelumnya lebih lama dari yang seharusnya dan kemudian mencoba mempersingkat tugas di
kemudian hari dalam pengembangan. Analis dan pemrogram kurang peduli tentang tenggat waktu yang jauh daripada yang
mendekati.
Sekali lagi, pendekatan tangkas menekankan rilis pendek. Rilis dapat dikirimkan pada waktu yang
dijanjikan, dikurangi beberapa fitur yang awalnya dijanjikan. Membuat semua tenggat waktu segera
mendorong harapan yang realistis untuk penyelesaian (setidaknya sebagian) ke depan.
MENGURANGI WAKTU DAN BIAYA PENCARIAN DATA DAN PENGETAHUAN DAN PENYIMPANAN. Sistem
pengembang perlu mengumpulkan informasi tentang organisasi, tujuan, prioritas, dan detail tentang sistem
informasi saat ini sebelum mereka dapat melanjutkan untuk mengembangkan sistem baru. Metode
pengumpulan data meliputi wawancara, administrasi kuesioner, observasi, dan penyelidikan dengan
memeriksa laporan dan memo.
Metodologi terstruktur mendorong metode pengumpulan data terstruktur. Teknik terstruktur
biasanya digunakan untuk menyusun wawancara dan merancang proses wawancara. Kuesioner akan
dikembangkan secara terstruktur, dan teknik observasi terstruktur seperti STROBE akan mendorong
analis untuk secara khusus mengamati elemen kunci dan membentuk kesimpulan berdasarkan
pengamatan lingkungan fisik. Rencana pengambilan sampel akan ditentukan secara kuantitatif, agar
analis sistem dapat memilih laporan dan memo untuk diperiksa.
Pencarian pengetahuan kurang terstruktur dalam lingkungan pemodelan tangkas. Praktek memiliki pelanggan
di tempat sangat meningkatkan akses ke informasi. Pelanggan di tempat hadir untuk menjawab pertanyaan tentang
organisasi itu sendiri, tujuannya, prioritas anggota organisasi dan pelanggan, dan pengetahuan apa pun yang
diperlukan tentang sistem informasi yang ada. Seiring proyek berlanjut, gambaran kebutuhan pelanggan menjadi
lebih jelas. Pendekatan ini tampaknya relatif tidak menyakitkan karena, ketika pengembang sistem ingin
mengetahui sesuatu, mereka hanya dapat bertanya. Kelemahannya, bagaimanapun, adalah bahwa perwakilan di
tempat dapat membuat informasi jika tidak diketahui atau tidak tersedia atau menghindari mengatakan yang
sebenarnya untuk beberapa tujuan tersembunyi.
MENGURANGI WAKTU DAN BIAYA KOMUNIKASI DAN KOORDINASI.

Komunikasi antara analis dan pengguna, serta di antara analis itu sendiri, adalah inti dari pengembangan sistem.
Komunikasi yang buruk tentu saja merupakan akar dari berbagai masalah pembangunan. Kita tahu bahwa
komunikasi meningkat ketika lebih banyak orang bergabung dengan sebuah proyek. Ketika dua orang mengerjakan
sebuah proyek, ada satu kesempatan untuk percakapan satu lawan satu; ketika tiga orang terlibat, ada tiga
kemungkinan; ketika empat terlibat, ada enam kemungkinan, dan seterusnya. Anggota tim yang tidak
berpengalaman membutuhkan waktu untuk mempercepat, dan mereka dapat memperlambat proyek meskipun
mereka dimaksudkan untuk membantu mempercepatnya.
Pengembangan terstruktur tradisional mendorong pemisahan tugas-tugas besar menjadi tugas-tugas yang
lebih kecil. Ini memungkinkan kelompok yang lebih erat dan mengurangi waktu yang dihabiskan untuk
berkomunikasi. Pendekatan lain melibatkan pengaturan hambatan. Misalnya, pelanggan mungkin tidak diberikan
akses ke pemrogram. Ini adalah praktik umum di banyak industri. Namun, peningkatan efisiensi sering berarti
penurunan efektivitas, dan telah dicatat bahwa membagi kelompok dan menetapkan hambatan sering
menimbulkan kesalahan.
Metode tangkas, di sisi lain, membatasi waktu alih-alih tugas. Timeboxing digunakan dalam metodologi
tangkas untuk mendorong penyelesaian aktivitas dalam periode yang lebih singkat. Timeboxing hanya menetapkan
batas waktu satu atau dua minggu untuk menyelesaikan fitur atau modul. Metode agile scrum mengutamakan
ketepatan waktu, sementara pengembang berkomunikasi secara efektif sebagai sebuah tim. Karena komunikasi
adalah salah satu dari empat nilai filosofi tangkas, biaya komunikasi cenderung meningkat daripada menurun.
MENGURANGI KEHILANGAN INFORMASI MANUSIA OVERLOAD. Kami telah lama mengetahui bahwa orang-orang
tidak bereaksi dengan baik dalam situasi informasi yang berlebihan. Ketika telepon merupakan teknologi
yang baru muncul, operator switchboard secara manual menghubungkan panggilan antara dua pihak. Dulu
menunjukkan bahwa sistem ini akan bekerja sampai terjadi kelebihan informasi, pada saat itu seluruh
sistem rusak. Ketika terlalu banyak panggilan masuk, operator switchboard yang kewalahan akan
berhenti bekerja dan menyerah sepenuhnya untuk menghubungkan penelepon. Situasi kelebihan
beban analog dapat terjadi kapan saja kepada siapa saja, termasuk analis sistem dan pemrogram.
Pendekatan tradisional adalah mencoba menyaring informasi untuk melindungi analis dan
pemrogram dari keluhan pelanggan. Pendekatan ini memungkinkan pengembang untuk terus
mengerjakan masalah tanpa gangguan dan subjektivitas yang biasanya terjadi.
Menggunakan filosofi tangkas, analis dan pemrogram diharapkan untuk tetap bekerja selama 40 jam per
minggu. Beberapa orang mungkin melihat ini sebagai praktik yang dipertanyakan. Bagaimana semua pekerjaan
akan selesai? Filosofi tangkas menyatakan bahwa pekerjaan berkualitas biasanya dilakukan selama jadwal rutin, dan
hanya ketika lembur ditambahkan, masalah desain dan pemrograman berkualitas buruk mulai muncul. Dengan
tetap berpegang pada jadwal kerja 40 jam seminggu, metodologi tangkas mengklaim bahwa Anda pada akhirnya
akan unggul.
Risiko Inheren dalam Inovasi Organisasi

Dalam konsultasi dengan pengguna, analis harus mempertimbangkan risiko yang dihadapi organisasi saat mengadopsi
metodologi baru. Jelas, ini adalah bagian dari pertanyaan yang lebih besar tentang kapan waktu yang tepat untuk
meningkatkan keterampilan manusia, mengadopsi proses organisasi baru, dan melembagakan perubahan internal.
Dalam arti yang lebih besar, ini adalah pertanyaan dari dimensi strategis untuk kepemimpinan
organisasi. Secara khusus, kami mempertimbangkan kasus tim analisis sistem yang mengadopsi
metode tangkas mengingat risiko bagi organisasi dan hasil akhir yang sukses untuk tim
pengembangan sistem dan klien mereka. Gambar 6.9 menunjukkan banyak variabel yang perlu
dipertimbangkan ketika menilai risiko mengadopsi inovasi organisasi.
BUDAYA ORGANISASI. Pertimbangan utama dalam inovasi organisasi adalah budaya organisasi secara
keseluruhan dan bagaimana budaya tim pengembangan cocok di dalamnya. Budaya organisasi konservatif
dengan banyak fitur stabil yang tidak berusaha untuk berinovasi mungkin merupakan konteks yang tidak
tepat atau bahkan tidak ramah untuk penerapan metodologi tangkas oleh kelompok pengembangan sistem.
Analis dan pengembang lain harus berhati-hati dalam memperkenalkan teknik baru ke dalam jenis
pengaturan ini karena keberhasilan mereka jauh dari pasti, dan anggota tim pengembangan lama atau
anggota organisasi lainnya dapat terancam oleh cara kerja baru yang menyimpang dari pendekatan yang
biasa dan dapat diandalkan dengan hasil yang terbukti.
Gambar 6.9
Mengadopsi sistem informasi baru
melibatkan penyeimbangan
beberapa risiko. Organisasi
Budaya
Individu
Waktu
Hak
Risiko dalam
Mengadopsi
Organisasi
Inovasi
Ukur
Biaya
Dampak
klien
Reaksi
Sebaliknya, organisasi yang bergantung pada inovasi untuk mempertahankan keunggulannya

dalam industrinya mungkin merupakan organisasi yang paling ramah terhadap inovasi tangkas
dalam metode pengembangan sistem. Dalam hal ini, budaya organisasi sudah diresapi dengan
pemahaman tentang sifat kritis dari banyak prinsip inti metodologi pengembangan tangkas. Dari
tingkat strategis ke bawah, anggota perusahaan telah menginternalisasi kebutuhan akan umpan
balik yang cepat, tanggapan dinamis terhadap perubahan lingkungan secara real time,
ketergantungan pada pelanggan untuk bimbingan dan partisipasi dalam pemecahan masalah, dan
sebagainya.
Terletak di antara ekstrem ini adalah organisasi yang tidak mengandalkan inovasi sebagai kekuatan strategis
utama (dengan kata lain, mereka tidak bergantung pada penelitian dan pengembangan produk atau layanan baru
untuk tetap bertahan) tetapi yang mungkin masih ingin mengadopsi praktik inovatif dalam skala kecil. unit atau
kelompok. Memang, pusat atau kernel yang kecil dan inovatif seperti itu pada akhirnya dapat mendorong
pertumbuhan atau keunggulan kompetitif dari jenis organisasi ini.
WAKTU. Organisasi harus bertanya dan menjawab pertanyaan tentang kapan waktu terbaik untuk
berinovasi dengan mengadopsi metodologi pengembangan sistem baru, ketika semua proyek dan
faktor lain (internal dan eksternal) diperhitungkan. Organisasi harus mempertimbangkan
keseluruhan proyek di mana mereka berinvestasi, melihat ke depan pada tenggat waktu proyek,
menjadwalkan peningkatan pabrik fisik, dan menyerap prakiraan industri dan ekonomi utama.
BIAYA. Risiko lain untuk penerapan metodologi tangkas untuk organisasi adalah biaya yang terlibat dalam
pendidikan dan pelatihan analis sistem dan pemrogram dalam pendekatan baru. Ini dapat melibatkan seminar dan
kursus di luar lokasi yang mahal atau menyewa konsultan untuk bekerja dengan staf saat ini di lokasi. Selanjutnya,
biaya peluang terlibat ketika pengembang sistem perlu dialihkan (walaupun sementara) dari proyek yang sedang
berlangsung untuk mempelajari keterampilan baru. Pendidikan itu sendiri bisa mahal, tetapi beban tambahan
diakui ketika analis tidak dapat memperoleh penghasilan selama periode pelatihan mereka.
REAKSI KLIEN. Ketika klien (baik internal atau eksternal) terlibat sebagai pengguna atau pemrakarsa upaya
pengembangan sistem informasi, reaksi terhadap penggunaan metode baru yang dicakup oleh pendekatan
tangkas juga menjadi pertimbangan utama. Beberapa klien bereaksi dengan gembira begitu manfaat dari
ketepatan waktu dan keterlibatan dijelaskan. Lainnya tidak ingin digunakan untuk sistem "eksperimen"
dengan hasil yang tidak pasti. Hubungan klien-analis harus cukup tangguh untuk menyerap dan beradaptasi
dengan perubahan perilaku yang diharapkan. Misalnya, kehadiran klien di tempat selama pengembangan
adalah komitmen utama yang harus dipahami dan disepakati secara menyeluruh oleh mereka yang
mengadopsi metode tangkas.
MENGUKUR DAMPAK. Pertimbangan lain untuk organisasi yang mengadopsi metodologi tangkas adalah bagaimana
mengesahkan dan mengukur bahwa metode baru akan memfasilitasi pengembangan sistem yang sukses. Kekuatan
dan kelemahan metode terstruktur tradisional yang digunakan untuk mengembangkan sistem informasi sudah
diketahui dengan baik.
Meskipun ada banyak bukti anekdot bahwa metodologi tangkas lebih unggul untuk
pengembangan dalam beberapa kondisi, sejarahnya berumur pendek dan belum didukung secara
empiris. Oleh karena itu, adopsi metodologi tangkas membawa risiko bahwa sistem yang dibuat
dengannya tidak akan berhasil atau tidak akan cukup berinteraksi dengan sistem lama. Pengukuran
dampak penggunaan metodologi tangkas telah dimulai, tetapi organisasi perlu waspada dalam
mengusulkan pengukuran dampak seiring dengan penerapan metode baru.
HAK INDIVIDU PROGRAMMER/ANALIS. Pengembang sistem yang sukses

(analis dan pemrogram) melatih kreativitas dalam pendekatan mereka terhadap pekerjaan mereka, dan
mereka berhak atas hak untuk bekerja dalam konfigurasi yang paling bermanfaat. Ada kemungkinan bahwa
persyaratan kerja metode gesit baru (misalnya, pemrograman berpasangan) melanggar beberapa hak dasar
orang-orang kreatif untuk bekerja sendiri atau dalam kelompok seperti yang ditentukan oleh pekerjaan
desain. Tidak ada "satu cara terbaik" untuk merancang sistem, modul, antarmuka, formulir, atau halaman
web. Dalam kasus pengembang sistem, kreativitas, subjektivitas, dan hak untuk mencapai tujuan desain
melalui berbagai jalur individu perlu diseimbangkan dengan adopsi organisasi dari pendekatan inovatif
seperti metodologi tangkas.
Seperti yang Anda lihat, mengadopsi inovasi organisasi menimbulkan banyak risiko bagi organisasi
maupun individu. Kami memeriksa risiko terhadap organisasi secara keseluruhan serta risiko terhadap
analis sistem individu yang terlibat dalam keinginan organisasi untuk berinovasi.
HIPERKASUS® pengalaman 6
"T syukurlah ini adalah waktu tahun ketika semuanya baru. Saya suka musim semi; ini
adalah waktu yang paling menggembirakan di sini di MRE. Pepohonan sangat hijau, dengan
sebuah prototipe. Tapi menyenangkan untuk terlibat dengan sesuatu yang terjadi
dengan cepat, dan sesuatu yang akan berubah.”
daun dalam berbagai warna. Begitu banyak proyek baru yang harus dilakukan juga; begitu
banyak klien baru untuk bertemu. Kami memiliki magang baru juga. Anna Mae Perak. Pertanyaan HYPERCASE
Terkadang karyawan terbaru adalah yang paling bersemangat untuk membantu. Hubungi
1. Buatlah daftar cerita pengguna yang dibagikan Tessa Silverstone sebagai
dia jika Anda membutuhkan lebih banyak jawaban. ”
contoh.
“Semua hal baru mengingatkan saya pada prototyping. Atau apa yang saya
2. Cari prototipe yang saat ini diusulkan untuk digunakan di salah satu
ketahui tentang pembuatan prototipe. Ini adalah sesuatu yang baru dan segar, cara
departemen MRE. Sarankan beberapa modifikasi yang akan
cepat untuk mengetahui apa yang terjadi.
membuat prototipe ini lebih responsif terhadap kebutuhan unit.
“Saya percaya bahwa kami memiliki beberapa prototipe yang sudah 3. Menggunakan pengolah kata, buat prototipe nonoperasional untuk Sistem
dimulai. Terkadang pelanggan baru kami, Tessa Silverstone, terlibat dengan Pelaporan Proyek Departemen Pelatihan. Sertakan fitur yang dibawa oleh
membantu membuat cerita pengguna untuk membangun prototipe. Tetapi cerita pengguna yang Anda temukan.Petunjuk: Lihat contoh layar di Bab 11
hal terbaik tentang prototipe adalah mereka dapat berubah. Saya tidak tahu dan 12 untuk membantu Anda dalam desain Anda.
siapa yang benar-benar puas dengan umpan pertama di
Gambar 6.HC1
Salah satu dari banyak layar prototipe yang ditemukan di HyperCase.
Ringkasan
Prototyping adalah teknik pengumpulan informasi yang berguna untuk melengkapi SDLC tradisional; namun, baik metode
tangkas maupun interaksi manusia-komputer berbagi akar dalam pembuatan prototipe. Ketika analis sistem menggunakan
prototyping, mereka mencari reaksi pengguna, saran, inovasi, dan rencana revisi untuk membuat perbaikan pada prototipe,
dan dengan demikian memodifikasi rencana sistem dengan biaya dan gangguan minimal. Empat pedoman utama untuk
mengembangkan prototipe adalah (1) bekerja dalam modul yang dapat dikelola, (2) membangun prototipe dengan cepat, (3)
memodifikasi prototipe, dan (4) menekankan antarmuka pengguna.
Meskipun pembuatan prototipe tidak selalu diperlukan atau diinginkan, perlu dicatat bahwa ada tiga keuntungan utama yang
saling terkait untuk menggunakannya: (1) potensi untuk mengubah sistem di awal pengembangannya, (2) peluang untuk
menghentikan pengembangan pada suatu sistem. yang tidak berfungsi, dan (3) kemungkinan berkembangnya a
sistem yang lebih dekat dengan kebutuhan dan harapan pengguna. Pengguna memainkan peran yang berbeda dalam proses pembuatan
prototipe, dan analis sistem harus bekerja secara sistematis untuk mendapatkan dan mengevaluasi reaksi pengguna terhadap prototipe.
Pemodelan tangkas adalah pendekatan pengembangan perangkat lunak yang mendefinisikan rencana keseluruhan dengan
cepat, mengembangkan dan merilis perangkat lunak dengan cepat, dan kemudian terus merevisi perangkat lunak untuk
menambahkan fitur tambahan. Nilai-nilai pendekatan tangkas yang dimiliki oleh pelanggan serta tim pengembangan adalah
komunikasi, kesederhanaan, umpan balik, dan keberanian. Aktivitas tangkas meliputi pengkodean, pengujian, mendengarkan, dan
mendesain. Sumber daya yang tersedia meliputi waktu, biaya, kualitas, dan ruang lingkup.
Praktik inti tangkas membedakan metode tangkas, termasuk jenis metode tangkas yang disebut pemrograman
ekstrem (XP), dari proses pengembangan sistem lainnya. Empat praktik inti dari pendekatan tangkas adalah (1) rilis singkat,
(2) minggu kerja 40 jam, (3) pelanggan di tempat, dan (4) pemrograman berpasangan. Proses pengembangan tangkas
termasuk memilih tugas yang terkait langsung dengan fitur yang diinginkan pelanggan berdasarkan cerita pengguna,
memilih mitra pemrograman, memilih dan menulis kasus uji yang sesuai, menulis kode, menjalankan kasus uji, men-debug
hingga semua kasus uji. menjalankan, mengimplementasikannya dengan desain yang ada, dan mengintegrasikannya ke
dalam apa yang ada saat ini.
Kemudian dalam bab ini kami membandingkan bagaimana SDLC dan pendekatan tangkas menangani peningkatan
efisiensi kerja pengetahuan secara berbeda. Kami kemudian membahas beberapa bahaya yang melekat pada organisasi
yang mengadopsi pendekatan inovatif, termasuk budaya organisasi yang tidak sesuai, waktu proyek yang buruk, biaya analis
sistem pelatihan, reaksi klien yang tidak menguntungkan terhadap ekspektasi perilaku baru, kesulitan dalam mengukur
dampak, dan kemungkinan kompromi dari hak kreatif individu programmer dan analis.
Kata kunci dan Frasa

40 jam kerja seminggu pelanggan di tempat
pemodelan tangkas pemrograman pasangan
prinsip tangkas prototipe yang ditambal

nilai tangkas prototipe
menganggap kesederhanaan metodologi scrum fase
merangkul perubahan perencanaan persyaratan
implementasi prototipe rilis pendek prototipe
pertama-of-a-series fitur terpilih
pemrograman ekstrim (XP) menekankan antarmuka pengguna
perubahan bertahap keterlibatan pengguna dengan membuat prototipe
memodifikasi prototipe cerita pengguna
prototipe nonoperasional bekerja dalam modul yang dapat dikelola
Tinjau Pertanyaan
1. Apa empat jenis informasi yang dicari oleh seorang analis melalui pembuatan prototipe?
2. Apa yang dimaksud dengan istilah? prototipe yang ditambal?
3. Tentukan prototipe yang merupakan model skala nonworking.
4. Berikan contoh prototipe yang merupakan model skala penuh pertama.
5. Tentukan apa yang dimaksud dengan prototipe yang merupakan model dengan beberapa, tetapi tidak semua, fitur penting.
6. Sebutkan keuntungan dan kerugian menggunakan prototyping untuk mengganti SDLC tradisional.
7. Jelaskan bagaimana prototyping dapat digunakan untuk menambah SDLC tradisional.
8. Apa kriteria untuk memutuskan apakah suatu sistem harus dibuat prototipe?
9. Sebutkan empat pedoman yang harus diperhatikan seorang analis dalam mengembangkan prototipe.
10. Apa dua masalah utama yang diidentifikasi dengan pembuatan prototipe?
11. Sebutkan tiga keuntungan utama dalam menggunakan prototyping.
12. Bagaimana prototipe yang dipasang pada situs web interaktif dapat memfasilitasi proses pembuatan prototipe? Jawab dalam satu
paragraf.
13. Apa tiga cara yang dapat membantu pengguna dalam proses pembuatan prototipe?
14. Apa saja empat nilai yang harus dimiliki bersama oleh tim pengembangan dan pelanggan bisnis saat
mengambil pendekatan tangkas?
15. Apa prinsip tangkas? Berikan lima contoh.
16. Apa saja empat praktik inti dari pendekatan tangkas?
17. Sebutkan empat variabel kendali sumber daya yang digunakan dalam pendekatan tangkas.
18. Uraikan langkah-langkah tipikal dalam episode pengembangan tangkas.
19. Apa yang dimaksud dengan cerita pengguna? Apakah itu terutama ditulis atau diucapkan? Nyatakan pilihan Anda, kemudian pertahankan jawaban Anda
dengan sebuah contoh.

bagian 2 • analisis kebutuhan informasi
20. Daftar alat perangkat lunak yang dapat membantu pengembang dalam melakukan berbagai pengujian kode
21. Apa itu scrum?
22. Sebutkan tujuh strategi untuk meningkatkan efisiensi dalam pekerjaan pengetahuan.
23. Identifikasi enam risiko dalam mengadopsi inovasi organisasi.
Masalah
1. Sebagai bagian dari proyek sistem yang lebih besar, Clone Bank of Clone, Colorado, menginginkan bantuan Anda dalam menyiapkan yang baru
formulir pelaporan bulanan untuk nasabah giro dan tabungan. Presiden dan wakil presiden sangat selaras dengan
apa yang dikatakan pelanggan di komunitas. Mereka berpikir bahwa pelanggan mereka menginginkan ringkasan
rekening giro yang terlihat seperti yang ditawarkan oleh tiga bank lain di kota. Namun, mereka tidak mau
berkomitmen pada formulir itu tanpa ringkasan formal dari umpan balik pelanggan yang mendukung keputusan
mereka. Umpan balik tidak akan digunakan untuk mengubah bentuk prototipe dengan cara apa pun. Mereka ingin
Anda mengirim prototipe satu formulir ke satu grup dan mengirim formulir lama ke grup lain.
A. Dalam sebuah paragraf, diskusikan mengapa mungkin tidak ada gunanya membuat prototipe bentuk baru dalam keadaan
seperti ini.
B. Dalam paragraf kedua, diskusikan situasi di mana disarankan untuk membuat prototipe bentuk baru.
2. CN Itall telah menjadi analis sistem untuk Tun-L-Vision Corporation selama bertahun-tahun. Saat kamu datang
on board sebagai bagian dari tim analisis sistem dan menyarankan pembuatan prototipe sebagai bagian dari SDLC untuk proyek saat
ini, CN berkata, “Tentu, tetapi Anda tidak dapat memperhatikan apa yang dikatakan pengguna. Mereka tidak tahu apa yang mereka
inginkan. Saya akan membuat prototipe, tetapi saya tidak 'mengamati' pengguna mana pun. ”
A. Sebijaksana mungkin, agar tidak mengecewakan CN Itall, buatlah daftar alasan yang mendukungnya
pentingnya mengamati reaksi pengguna, saran, dan inovasi dalam proses pembuatan prototipe.
B. Dalam sebuah paragraf, jelaskan apa yang mungkin terjadi jika bagian dari sistem dibuat prototipe dan tidak ada umpan balik pengguna
tentang hal itu yang dimasukkan ke dalam sistem yang berurutan.
3. "Setiap kali saya pikir saya telah menangkap persyaratan informasi pengguna, mereka sudah berubah. Ini seperti
mencoba untuk mencapai target yang bergerak. Separuh waktu, saya rasa mereka bahkan tidak tahu apa yang mereka inginkan
sendiri,” seru Flo Chart, seorang analis sistem untuk 2 Good 2 Be True, sebuah perusahaan yang mensurvei penggunaan produk
untuk divisi pemasaran beberapa perusahaan manufaktur.
A. Dalam sebuah paragraf, jelaskan kepada Flo Chart bagaimana pembuatan prototipe dapat membantunya mendefinisikan informasi pengguna dengan lebih baik.
persyaratan.
B. Dalam sebuah paragraf, komentari pengamatan Flo: “Separuh waktu, saya rasa mereka bahkan tidak tahu apa
mereka menginginkan diri mereka sendiri.” Pastikan untuk menjelaskan bagaimana prototyping benar-benar dapat membantu pengguna lebih
memahami dan mengartikulasikan kebutuhan informasi mereka sendiri.
C. Sarankan bagaimana situs web interaktif yang menampilkan prototipe dapat mengatasi kekhawatiran Flo tentang
menangkap persyaratan informasi pengguna. Gunakan paragraf.
4. Harold, manajer distrik untuk rantai multioutlet Sprocket's Gifts, berpikir bahwa membangun prototipe
dapat berarti hanya satu hal: model skala nonworking. Dia juga percaya bahwa cara ini terlalu rumit untuk sistem
informasi prototipe dan dengan demikian enggan untuk melakukannya.
A. Secara singkat (dalam dua atau tiga paragraf) bandingkan dan kontraskan tiga jenis prototyping lainnya yang
mungkin sehingga Harold memiliki pemahaman tentang apa arti prototipe.
B. Harold memiliki opsi untuk menerapkan satu sistem, mencobanya, dan kemudian memasangnya di
lima lokasi Sprocket lain jika berhasil. Sebutkan jenis prototyping yang sesuai dengan pendekatan ini,
dan dalam paragraf pertahankan pilihan Anda.
5. “Saya punya ide abad ini!” kata Bea Kwicke, analis sistem baru dengan sistem Anda
kelompok. “Mari kita lewati semua sampah SDLC ini dan buat prototipe semuanya. Proyek kami akan berjalan jauh lebih
cepat, kami akan menghemat waktu dan uang, dan semua pengguna akan merasa seolah-olah kami memperhatikan mereka
alih-alih pergi selama berbulan-bulan dan tidak berbicara dengan mereka.”
A. Buat daftar alasan Anda (sebagai anggota tim yang sama dengan Bea) akan memberi Bea untuk mencegahnya
mencoba menghapus SDLC dan membuat prototipe setiap proyek.
B. Bea cukup kecewa dengan apa yang Anda katakan. Untuk mendorongnya, gunakan sebuah paragraf untuk menjelaskan
situasi yang menurut Anda akan cocok untuk pembuatan prototipe.
6. Pernyataan berikut terdengar pada pertemuan antara manajer dan tim analisis sistem di:
perusahaan pagar Fence-Me-In: “Anda memberi tahu kami bahwa prototipe akan selesai tiga minggu lalu. Kami
masih menunggunya!"
A. Dalam sebuah paragraf, beri komentar tentang pentingnya pengiriman cepat sebagian dari informasi prototipe
sistem tion.
B. Sebutkan tiga elemen dari proses pembuatan prototipe yang harus dikendalikan untuk memastikan pengiriman prototipe
yang cepat.
C. Apa saja elemen dari proses pembuatan prototipe yang sulit dikelola? Daftar mereka.
7. Menyiapkan daftar kegiatan untuk tim pengembangan sistem untuk agen perjalanan online yang menyiapkan
situs web untuk pelanggan. Sekarang anggaplah Anda kehabisan waktu. Jelaskan beberapa pilihan Anda.
Jelaskan apa yang akan Anda tukarkan agar situs web dirilis tepat waktu.
8. Mengingat situasi untuk cokelat Williwonk (Masalah 1 dalam Bab 3), mana dari empat variabel sumber
daya pemodelan tangkas yang dapat disesuaikan?
9. Periksa kumpulan cerita pengguna dari pedagang online yang ditampilkan sebelumnya di bab ini. NS
toko media online sekarang ingin Anda menambahkan beberapa fitur ke situs webnya. Mengikuti format yang ditunjukkan
sebelumnya dalam bab ini pada Gambar 6.7, tulis cerita pengguna untuk fitur yang tercantum di bawah ini:
A. Sertakan iklan pop-up.
B. Tawarkan untuk membagikan detail pembelian pelanggan dengan teman-temannya.
C. Perpanjang penawaran untuk membeli barang lain.
10. Kunjungi situs web Android, di www.palmgear.com. Jelajahi situs web dan tulis selusin cerita pengguna
singkat untuk meningkatkan situs web.
11. Buka situs web iTunes dan tulis selusin cerita pengguna singkat untuk meningkatkan situs web.
12. Dengan menggunakan cerita yang Anda tulis untuk Soal 9, telusuri lima tahap proses
pengembangan tangkas dan jelaskan apa yang terjadi di setiap tahap.
Proyek Grup
1. Bagilah kelompok Anda menjadi dua subkelompok yang lebih kecil. Mintalah Grup 1 mengikuti proses yang ditentukan dalam
bab ini untuk membuat prototipe. Dengan menggunakan alat CASE atau pengolah kata, Grup 1 harus merancang dua layar
prototipe yang tidak berfungsi menggunakan informasi yang dikumpulkan dalam wawancara dengan karyawan Maverick
Transport yang diselesaikan dalam latihan kelompok di Bab 4. Buat asumsi apa pun yang diperlukan untuk membuat dua
layar untuk petugas operator truk. Grup 2 (berperan sebagai petugas operator) harus bereaksi terhadap layar prototipe dan
memberikan umpan balik tentang penambahan dan penghapusan yang diinginkan.
2. Anggota Grup 1 harus merevisi layar prototipe berdasarkan komentar pengguna yang mereka terima. Mereka
yang berada di Grup 2 harus menanggapi dengan komentar tentang seberapa baik kekhawatiran awal mereka
ditangani dengan prototipe yang disempurnakan.
3. Sebagai kelompok yang bersatu, tulislah sebuah paragraf yang membahas pengalaman Anda dengan pembuatan prototipe untuk
memastikan kebutuhan informasi.
4. Dalam kelompok bersatu Anda, tetapkan beberapa peran yang diambil orang dalam pengembangan tangkas. Pastikan
bahwa satu orang adalah pelanggan di tempat dan setidaknya dua orang adalah pemrogram. Tetapkan peran lain,
sesuai keinginan Anda. Simulasikan situasi pengembangan sistem yang dibahas dalam Soal 7, atau mintalah orang
yang bertindak sebagai pelanggan di lokasi memilih bisnis e-niaga yang dikenalnya. Asumsikan bahwa pelanggan ingin
menambahkan beberapa fungsi ke situs webnya. Bermain peran skenario yang menunjukkan apa yang akan dilakukan
setiap orang jika ini didekati melalui metode tangkas. Tulislah sebuah paragraf yang membahas kendala-kendala yang
dihadapi setiap orang dalam menjalankan perannya.
Daftar Pustaka yang Dipilih

Alavi, M. "Sebuah Penilaian Pendekatan Prototyping untuk Pengembangan Sistem Informasi."
Komunikasi ACM, Jil. 27, No. 6, Juni 1984, hlm. 556–563. Avison, D., dan DN Wilson. “Kontrol untuk
Pembuatan Prototipe yang Efektif.”Jurnal Sistem Manajemen, Jil.
3, No. 1, 1991.
Beck, K Pemrograman Ekstrim Dijelaskan: Rangkullah Perubahan. Boston: Addison-Wesley Publishing Co., 2000.
Beck, K., dan M. Fowler. Merencanakan Pemrograman Ekstrim. Boston: Addison-Wesley Publishing Co., 2001.
Cockburn, A. Pengembangan Perangkat Lunak Tangkas. Boston: Addison-Wesley Publishing Co., 2002. Davis, GB,
dan JD Naumann. “Produktivitas Kerja Pengetahuan.” Di dalamInformasi yang Muncul
Teknologi: Meningkatkan Keputusan, Kerjasama, dan Infrastruktur. Diedit oleh KE Kendall, hlm. 343–
357. Thousand Oaks, CA: Sage, 1999.
Davis, GB, dan MH Olson. Sistem Informasi Manajemen: Pondasi Konseptual, Struktur,
dan pengembangan, edisi ke-2 New York: McGraw-Hill, 1985.
Fitzgerald, B., dan G. Hartnett. “Studi Penggunaan Metode Agile Dalam Intel.” Di dalamKelincahan Bisnis &
Difusi TI. Diedit oleh L. Matthiassen, J. Pries-Heje, dan J. DeGross, hlm. 187–202. Konferensi Proc,
Atlanta, Mei 2005. New York: Springer, 2005.
Ghione, J. "Panduan Pengembang Web untuk Alat dan Teknik Pengembangan Aplikasi Cepat."
Dunia Netscape, Juni 1997.
Gremillion, LL, dan P. Pyburn. “Mematahkan Kemacetan Pengembangan Sistem.”Bisnis Harvard
Tinjauan, Maret–April 1983, hlm. 130–137.

Ads CH 6 Id

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ads CH 6 Id

Diunggah oleh

Hak Cipta:

Format Tersedia

Diterjemahkan dari bahasa Inggris ke bahasa Indonesia - www.onlinedoctranslator.

2. Gunakan prototyping untuk pengumpulan kebutuhan informasi manusia.

4. Pelajari pentingnya nilai-nilai penting untuk pemodelan tangkas.

terstruktur atau pemodelan tangkas.

Bab ini mengeksplorasi pemodelan tangkas, yang merupakan kumpulan

Memasukkan Proses Keluaran

Prototipe yang Ditambal Prototipe Nonoperasional

Prototipe Seri Pertama Prototipe Fitur yang Dipilih

PELUANG KONSULTASI 6.1

Apakah Prototyping Raja?

fitur apa yang akan ditambahkan selanjutnya.

Prototyping sebagai Alternatif untuk SDLC

Pedoman untuk Mengembangkan Prototipe

1. Bekerja dalam modul yang dapat dikelola.

Membersihkan Jalan untuk Tautan Pelanggan

W Orld's Trend (lihat Bab 7 untuk deskripsi perusahaan yang

Kekurangan dari Prototyping

Keuntungan dari Prototyping

Membuat Prototipe Menggunakan Perangkat Lunak COTS

Peran Pengguna dalam Pembuatan Prototipe

1. Bereksperimen dengan prototipe

adalah merekam pengguna dengan benar

Nilai dan Prinsip Pemodelan Agile

Untuk Menetas Ikan

1. Memuaskan pelanggan melalui pengiriman perangkat lunak yang berfungsi.

6. Promosikan percakapan tatap muka.

8. Mendorong pembangunan yang berkesinambungan, teratur, dan berkelanjutan.

9. Mengadopsi kelincahan dengan memperhatikan desain yang penuh perhatian.

10. Mendukung tim yang mengatur diri sendiri.

11. Memberikan umpan balik yang cepat.

12. Mendorong kualitas.

Aktivitas, Sumber Daya, dan Praktik Pemodelan Agile

menemukan diri Anda kehabisan waktu, apa yang Anda lakukan?

Tampilkan penerbangan alternatif.

Siapkan daftar lima penerbangan termurah.

Menawarkan alternatif yang lebih murah.

Biarkan pelanggan memilih tempat duduknya.

Prototipe Ini Semua Basah

sistem atau produk tersebut, dan kemudian memperbaikinya nanti.

Gambar 6.5 Latihan Inti Agile

Praktik inti saling terkait dengan kamu

Sumber Daya Agile

yang menyenangkan untuk memprogram.

Proses Pengembangan Agile

1. Dengarkan cerita pengguna dari pelanggan.

Selamat datang pelanggan.

Menampilkan hasil pencarian di halaman web baru.

Menampilkan ulasan produk.

Konfirmasi identitas pelanggan.

Terapkan metode pintasan untuk checkout lebih cepat.

Jika identitas pelanggan diketahui dan alamat pengiriman cocok, percepat

Kebutuhan atau Pelu

1. Product backlog, di mana daftar berasal dari spesifikasi produk.

Nilai tangkas adalah Pemrograman pasangan

penting untuk meningkatkan secara keseluruhan

Pelajaran yang Didapat

Sumber daya yang seimbang Pelanggan di tempat

Pelajaran yang Dipetik dari Pemodelan Agile

Membandingkan Pemodelan Agile dan Metode Terstruktur

Meningkatkan Efisiensi dalam Pekerjaan Pengetahuan: SDLC Versus Agile

Strategi untuk Meningkatkan Implementasi Menggunakan Implementasi Menggunakan

Efisiensi dalam Pekerjaan Pengetahuan Metodologi Terstruktur Metodologi Agile

penamaan, dll.; menggunakan formulir pemrograman