Pertemuan 1

Software Construction
 Pokok Bahasan
• Konsepsi umum
• What Is Software Construction?
• Why Is Software Construction Important?
• Metaphors for a Richer Understanding of
Software Development
• How to Use Software Metaphors
• Metafora Perangkat Lunak
• Software Construction: Building Software
 Konsepsi Umum

Konsepsi umum konstruksi seperti kualitas perangkat lunak

dan cara berpikir tentang pemrograman. Hal ini berkaitan
dengan konstruksi seluk beluk detail seperti langkah-langkah
dalam membangun kelas, seluk beluk menggunakan data dan
mengontrol struktur, debugging, refactoring, dan teknik dan
strategi penyempurnaan kode.
 Anda tahu apa artinya "konstruksi" ketika digunakan di luar
pengembangan perangkat lunak. “Konstruksi” adalah pekerjaan
yang “dilakukan oleh pekerja konstruksi” ketika mulai
membangun rumah, sekolah, atau gedung pencakar langit.
Ketika Anda masih muda, Anda membangun hal dari "kertas
konstruksi." Dalam penggunaan umum, "konstruksi" mengacu
pada proses pembangunan. Proses konstruksi mungkin
mencakup beberapa aspek perencanaan, perancangan, dan
pemeriksaan pekerjaan, tetapi sebagian besar "konstruksi"
mengacu pada bagian langsung dari menciptakan sesuatu.
 What Is Software Construction?
Mengembangkan perangkat lunak komputer bisa menjadi
proses yang rumit, dan dalam 25 tahun terakhir, para peneliti
telah mengidentifikasi berbagai kegiatan berbeda yang masuk
ke dalam 11 pengembangan perangkat lunak. Diantaranya
adalah:
1. Definisi masalah
2. Pengembangan persyaratan
3. Perencanaan konstruksi
4. Arsitektur perangkat lunak, atau desain tingkat tinggi
5. Desain terperinci
6. Pengkodean dan debugging
7. Pengujian unit
8. Pengujian integrasi
9. Integrasi, 10. Pengujian sistem, 11. Perawatan korektif
 Jika telah belajar sendiri untuk memprogram atau bekerja
terutama pada proyek-proyek informal, Anda mungkin tidak
membuat perbedaan di antara banyak kegiatan yang digunakan
untuk menciptakan produk perangkat lunak. Secara mental,
mungkin telah mengelompokkan semua kegiatan ini bersama-
sama sebagai “pemrograman.” Jika Anda bekerja pada proyek-
proyek informal, kegiatan utama yang Anda pikirkan ketika Anda
berpikir tentang membuat perangkat lunak mungkin adalah
kegiatan yang oleh peneliti disebut sebagai “konstruksi. ”
Gagasan intuitif tentang "konstruksi" ini cukup akurat, tetapi
tidak memiliki perspektif. Menempatkan konstruksi dalam
konteksnya dengan kegiatan-kegiatan lain membantu menjaga
fokus pada tugas-tugas yang tepat selama konstruksi dan dengan
tepat menekankan kegiatan-kegiatan non-konstruksi yang
penting. Gambar-1 menggambarkan tempat konstruksi yang
terkait dengan kegiatan pengembangan perangkat lunak lain.
Gambar-1. Kegiatan konstruksi ditampilkan di dalam lingkaran abu-abu.
Konstruksi berfokus pada pengkodean dan debugging tetapi juga mencakup
beberapa desain terperinci, pengujian unit, pengujian integrasi dan aktivitas
lainnya
 Seperti yang ditunjukkan oleh gambar, konstruksi sebagian
besar adalah pengkodean dan debugging tetapi juga melibatkan
elemen-elemen desain rinci, pengujian unit, integrasi, pengujian
integrasi, dan aktivitas lainnya. Jika ini adalah buku tentang
semua aspek pengembangan perangkat lunak, itu akan
menampilkan diskusi seimbang yang baik dari semua kegiatan
dalam proses pengembangan. Karena ini adalah buku pedoman
teknik konstruksi, yang menempatkan penekanan miring pada
konstruksi dan hanya menyentuh topik terkait. Hal ini
menggambarkan pada desain dan pengujian, dan merongrong
pada kegiatan pengembangan lainnya.
 Konstruksi juga kadang-kadang dikenal sebagai "pengkodean"
atau "pemrograman." "Pengkodean“ tidak benar-benar kata
yang terbaik karena menyiratkan terjemahan mekanis dari
desain yang sudah ada sebelumnya ke dalam bahasa komputer;
konstruksi sama sekali tidak mekanis dan melibatkan kreativitas
dan penilaian yang substansial. Sepanjang pembelajaran akan
menggunakan "pemrograman" secara bergantian dengan
"konstruksi.“
Berbeda dengan Gambar-1 pandangan datar dari
pengembangan perangkat lunak, Gambar-2 menunjukkan
perspektif coding dan debugging.
Gambar-2. Desain terperinci, pengkodean, debugging, dan pengujian unit
 Dengan begitu banyak kegiatan yang sedang dikerjakan dalam
konstruksi, Anda mungkin berkata, "Oke, Jack, kegiatan apa yang
bukan bagian dari konstruksi?" Itu pertanyaan yang wajar.
kegiatan non-konstruksi penting termasuk manajemen,
pengembangan persyaratan, arsitektur perangkat lunak, desain
antarmuka pengguna, pengujian sistem, dan pemeliharaan.
Setiap kegiatan ini memengaruhi keberhasilan akhir suatu proyek
sebanyak konstruksi, setidaknya keberhasilan setiap proyek yang
membutuhkan lebih dari satu atau dua orang dan berlangsung
lebih lama dari beberapa minggu.
 Why Is Software Construction
Important?
Konstruksi adalah bagian besar dari pengembangan
perangkat lunak. Tergantung pada ukuran proyek, konstruksi
biasanya membutuhkan 30 hingga 80 persen dari total waktu
yang dihabiskan untuk suatu proyek. Apa pun yang
menghabiskan banyak waktu proyek pasti akan memengaruhi
keberhasilan proyek.
Konstruksi adalah kegiatan utama dalam pengembangan
perangkat lunak. Persyaratan dan arsitektur dilakukan sebelum
konstruksi sehingga Anda dapat melakukan 120 konstruksi
secara efektif. Pengujian sistem dilakukan setelah konstruksi
untuk memverifikasi bahwa konstruksi telah dilakukan dengan
benar. Konstruksi berada di pusat proses pengembangan
perangkat lunak.
 Dengan fokus pada konstruksi, produktivitas masing-masing
programmer dapat meningkat secara drastis. Sebuah studi klasik
oleh Sackman, Erikson, dan Grant menunjukkan bahwa
produktivitas programmer berbeda-beda dengan faktor 10
hingga 20 selama konstruksi. Sejak studi mereka, hasil mereka
telah dikonfirmasi oleh banyak studi lainnya (Curtis, Mills, Curtis
et al , Card, Valett dan McGarry, DeMarco dan Lister, Boehm et
al). Buku ini membantu semua programmer mempelajari teknik
yang sudah digunakan oleh programmer terbaik.
 Produk konstruksi, kode sumber, sering kali merupakan satu-
satunya deskripsi akurat dari perangkat lunak. Dalam banyak
proyek, satu-satunya dokumentasi yang tersedia untuk
programmer adalah kode itu sendiri. Spesifikasi persyaratan dan
dokumen desain bisa kedaluwarsa, tetapi kode sumbernya selalu
terbaru. Karenanya, sangat penting bahwa kode sumber memiliki
kualitas setinggi mungkin. Penerapan teknik yang konsisten
untuk peningkatan kode sumber membuat perbedaan antara
alat dan program yang terperinci, benar, dan informatif. Teknik
seperti itu paling efektif diterapkan selama konstruksi.
Konstruksi adalah satu-satunya kegiatan yang dijamin akan
dilakukan. Proyek perangkat lunak yang ideal melewati
pengembangan persyaratan yang cermat dan desain arsitektur
sebelum konstruksi dimulai. Proyek yang ideal menjalani
pengujian sistem yang komprehensif, terkendali secara statistik
setelah konstruksi. Proyek-proyek dunia nyata yang tidak
sempurna, bagaimanapun, sering melompati persyaratan dan
desain untuk lompat ke konstruksi. Mereka membatalkan
pengujian karena mereka memiliki terlalu banyak kesalahan
untuk diperbaiki dan mereka kehabisan waktu. Tetapi tidak peduli
seberapa tergesa-gesa atau buruknya merencanakan suatu
proyek, Anda tidak dapat menghentikan konstruksi;
Meningkatkan konstruksi dengan demikian merupakan cara
untuk meningkatkan upaya pengembangan perangkat lunak apa
pun, betapa pun singkatnya.
Metaphors for a Richer Understanding
of Software Development
Perkembangan penting sering muncul dari analogi. Dengan
membandingkan suatu topik yang kurang Anda pahami dengan
sesuatu yang serupa dengan yang Anda pahami lebih baik,
Anda bisa memunculkan wawasan yang menghasilkan
pemahaman yang lebih baik tentang topik yang kurang dikenal.
Penggunaan metafora ini disebut "pemodelan.“
Secara umum, kekuatan model adalah bahwa mereka jelas
dan dapat dipahami sebagai keseluruhan konseptual. Mereka
menyarankan properti, hubungan, dan bidang penyelidikan
tambahan. Kadang-kadang sebuah model menyarankan
bidang-bidang penyelidikan yang metafornya telah diperluas.
 Beberapa metafora lebih baik daripada yang lain. Metafora
yang baik adalah sederhana, berhubungan baik dengan metafora
lain yang relevan, dan menjelaskan banyak dari bukti
eksperimental dan fenomena yang diamati lainnya.
Pengembangan perangkat lunak adalah bidang yang lebih
muda daripada kebanyakan ilmu lainnya. Belum cukup dewasa
untuk memiliki seperangkat metafora standar. Akibatnya, ia
memiliki banyak metafora yang saling melengkapi dan saling
bertentangan. Beberapa lebih baik dari lainnya. Beberapa lebih
buruk. Seberapa baik Anda memahami metafora menentukan
seberapa baik Anda memahami pengembangan perangkat lunak.
How to Use Software Metaphors
Metafora perangkat lunak lebih seperti lampu sorot
daripada peta jalan. Itu tidak memberi tahu Anda di mana
menemukan jawabannya; ini memberitahu Anda bagaimana
mencarinya. Metafora berfungsi lebih sebagai heuristik dari
pada sebagai algoritma.
Algoritme adalah seperangkat instruksi yang terdefinisi
dengan baik untuk melaksanakan tugas tertentu. Algoritma
dapat diprediksi, deterministik, dan tidak tunduk pada
peluang. Algoritma memberi tahu Anda cara beralih dari titik A
ke titik B tanpa jalan memutar, tidak ada sisi perjalanan ke titik
D, E, dan F, dan tidak berhenti.
Heuristik adalah teknik yang membantu Anda mencari jawaban.
Hasilnya adalah kemungkinan karena heuristik memberi tahu
Anda hanya bagaimana melihat, bukan apa yang ditemukan. Itu
tidak memberi tahu Anda bagaimana untuk langsung dari titik A
ke titik B; bahkan mungkin tidak tahu di mana titik A dan titik B
berada. Efeknya, heuristik adalah algoritma dalam setelan badut.
Ini kurang dapat diprediksi, lebih menyenangkan, dan dilengkapi
tanpa jaminan uang kembali selama beberapa hari.
 Perbedaan antara algoritma dan heuristik adalah halus, dan
dua istilah agak tumpang tindih. Untuk tujuan penjelasn ini,
perbedaan utama antara keduanya adalah tingkat tipuan dari
solusi. Algoritme memberi Anda petunjuk secara langsung,
sedangkan heuristik memberi tahu Anda cara menemukan
instruksi untuk Anda sendiri, atau setidaknya di mana harus
mencarinya.
 Metafora Perangkat Lunak
Banyak metafora yang membingungkan telah tumbuh di
sekitar pengembangan perangkat lunak. Fred Brooks
mengatakan bahwa menulis perangkat lunak seperti bertani,
berburu manusia serigala, atau tenggelam dengan dinosaurus di
lubang . David Gries mengatakan ini adalah sebuah sains.
Donald Knuth mengatakan itu seni. Watts Humphrey
mengatakan proses. P.J. Plauger dan Kent Beck mengatakan ini
seperti mengendarai mobil (Plauger, Beck 2000). Alistair
Cockburn mengatakan ini permainan (2001). Eric Raymond
mengatakan ini seperti pasar. Paul Heckel mengatakan ini
seperti syuting Snow White dan the Seven Dwarfs. Jadi apa dan
seperti apa metafora terbaik?
 Metafora yang paling primitif untuk pengembangan
perangkat lunak tumbuh dari ungkapan "kode penulisan".
Ekspresi metafora penulisan menunjukkan bahwa
mengembangkan program seperti menulis surat biasa - Anda
duduk dengan pena, tinta, dan kertas dan menulisnya dari awal
menyelesaikan. Itu tidak memerlukan perencanaan formal apa
pun, dan Anda harus mencari tahu apa yang ingin Anda katakan
saat Anda pergi.
 Software Construction: Building
Software
Gambar "membangun" perangkat lunak lebih berguna daripada
gambar "menulis" atau "tumbuh". Ini kompatibel dengan ide
penambahan perangkat lunak dan memberikan panduan yang
lebih rinci. Membangun perangkat lunak menyiratkan berbagai
tahap dalam perencanaan, persiapan, dan pelaksanaan yang
bervariasi dalam jenis dan tingkat tergantung pada 281 apa
yang sedang dibangun. Saat Anda menjelajahi metafora, Anda
menemukan banyak persamaan lainnya.
Membangun menara 4 kaki membutuhkan tangan yang kokoh,
permukaan yang rata, dan 10 kaleng susu yang tidak rusak.
Membangun menara 100 kali ukuran itu tidak hanya
membutuhkan kali lebih banyak kaleng susu. Dibutuhkan jenis
perencanaan dan konstruksi yang berbeda.
 Jika Anda membangun struktur sederhana — rumah anjing,
misalnya — Anda dapat pergi ke toko kayu dan membeli
beberapa kayu dan paku. Menjelang sore, Anda akan memiliki
rumah baru untuk Fido. Jika Anda lupa menyediakan pintu atau
membuat kesalahan lain, itu bukan masalah besar; Anda dapat
memperbaikinya atau bahkan memulai dari awal. Yang Anda
buang hanyalah bagian dari suatu sore. Pendekatan longgar ini
juga sesuai untuk proyek perangkat lunak kecil, jika Anda
menggunakan desain yang salah untuk 1000 baris kode, Anda
dapat memperbaiki atau memulai kembali sepenuhnya tanpa
kehilangan banyak.
Kesalahan pada struktur yang sederhana hanya sedikit waktu
dan mungkin sedikit memalukan.
Gambar 3. The penalty for a mistake on a simple structure is only a little time
and maybe some embarrassment.
Jika Anda membangun rumah, proses pembangunannya
menjadi lebih rumit, dan begitu pula konsekuensi dari desain
yang buruk.
Pertama, Anda harus memutuskan jenis rumah apa yang ingin
Anda bangun — analog dengan pengembangan perangkat lunak
dengan definisi masalah. Kemudian Anda dan seorang arsitek
harus membuat desain umum dan membuatnya disetujui. Ini
mirip dengan desain arsitektur perangkat lunak. Anda
menggambar cetak biru terperinci dan menyewa kontraktor. Ini
mirip dengan desain perangkat lunak terperinci. Anda harus
mempersiapkan situs bangunan, meletakkan fondasi,
membingkai rumah, meletakkan dinding dan atap di atasnya,
dan menyelipkan dan memasang kawatnya.
 Ini mirip dengan konstruksi perangkat lunak. Ketika sebagian
besar rumah selesai dibangun, para penata taman dan pelukis
datang untuk memanfaatkan properti Anda sebaik mungkin dan
rumah yang Anda bangun. Ini mirip dengan pengoptimalan
perangkat lunak . Sepanjang proses, berbagai pemeriksa datang
untuk memeriksa lokasi, fondasi, bingkai, perkabelan, dan
barang-barang inspeksi lainnya. Ini mirip dengan perangkat lunak
ulasan, pemrograman pasangan, dan inspeksi.
Gambar 4. More complicated structures require more careful planning.