Software Development · ⁨Pengembangan Perangkat Lunak⁩

Siklus hidup pengembangan adalah serangkaian tahap dari ide hingga perangkat lunak jadi yang terawat. Tujuannya adalah untuk merencanakan, mengelola, dan mengendalikan sebuah proyek — yaitu membangun produk yang tepat, tepat waktu, dengan kualitas baik.

*Diagram alir merencanakan logika program selama tahap desain dalam siklus tersebut

Mengapa siklus hidup diperlukan

Daftar penguji untuk "tujuan siklus hidup pengembangan": memecah proyek besar menjadi tahap-tahap yang dapat direncanakan dan dikelola; memastikan kebutuhan ditemukan dan disepakati sebelum desain dan pengkodean dimulai; menyertakan pengujian dan dokumentasi daripada meninggalkannya hingga akhir; memungkinkan tim melacak kemajuan terhadap titik penting dan mengelola risiko; serta memberikan pelanggan titik-titik terdefinisi untuk meninjau pekerjaan. Tanpa satu pun itu, tim akan mulai mengode terlebih dahulu dan baru menyadari terlambat bahwa mereka telah membangun sesuatu yang salah.

Mengapa ada berbagai jenisnya

Tidak ada satu siklus hidup pun yang cocok untuk setiap proyek, sehingga terdapat banyak siklus hidup pengembangan. Pilihannya bergantung pada ukuran dan kompleksitas, seberapa jelas kebutuhan di awal, seberapa banyak perubahan yang diharapkan, tingkat risiko, tim, dan tenggat waktu.

Model-model umum

• Waterfall — urutan linear (Analisis → Desain → Pengkodean → Pengujian → Pemeliharaan), setiap tahap selesai sebelum tahap berikutnya dimulai. Jelas dan terdokumentasi dengan baik; baik untuk kebutuhan yang stabil, tetapi buruk dalam menghadapi perubahan di tengah proyek, dan pelanggan tidak melihat apa pun yang berfungsi hingga akhirnya.
• Model iteratif — perjalanan berulang, setiap putaran menghasilkan versi parsial yang ditinjau dan disempurnakan. Menangkap masalah lebih awal; baik ketika kebutuhan ditemukan seiring berjalannya waktu, tetapi lebih sulit untuk diestimasi.
• Pengembangan Aplikasi Cepat (RAD) — penggunaan intensif prototipe dan umpan balik pengguna. Pengiriman pertama sangat cepat; baik untuk kebutuhan yang berubah, tetapi bergantung pada ketersediaan pengguna dan cocok untuk sistem yang lebih kecil.
• Agile — iterasi pendek ("sprint"), kolaborasi dan pengujian yang konstan. Fleksibel dan adaptif, tetapi membutuhkan pelanggan yang berkomitmen dan tim yang terampil.

*Model waterfall: setiap tahap selesai sebelum tahap berikutnya dimulai

*Model iteratif: perjalanan berulang menyempurnakan program

*Pengembangan aplikasi cepat: tim bekerja pada bagian-bagian secara paralel

Prinsip, manfaat, dan kekurangan — seperti yang terdaftar dalam skema pemarkahan.

Contoh soal. Sebuah perusahaan harus menjadi yang pertama meluncurkan situs web untuk konsol game baru, dan desainnya akan berubah saat fitur konsol diumumkan. Sebutkan siklus hidup yang paling sesuai dan berikan alasannya.

RAD. Prototipe situs dapat dibangun dan ditampilkan kepada pengguna dalam hitungan hari, dan disempurnakan seiring perubahan kebutuhan; situsnya cukup kecil untuk pendekatan berbasis prototipe, dan kecepatan pengiriman adalah persyaratan utama. Waterfall akan menetapkan kebutuhan sebelum halaman mana pun dibangun dan tidak akan mengirimkan apa pun hingga akhir.

Tahap-tahap standar

Setiap tahap memiliki tujuan, keluaran, dan aktivitas典型 — pertanyaan "deskripsikan tahap …" menginginkan dua atau tiga dari hal-hal ini.

• analisis — tentukan apa yang harus dilakukan program. Kegiatan: wawancara, kuesioner dan pengamatan sistem saat ini; studi kelayakan; persetujuan spesifikasi kebutuhan, yang menjadi acuan pengecekan pada setiap tahap selanjutnya.
• desain — tentukan bagaimana hal itu akan dilakukan. Output: diagram struktur (modul dan parameter), flowchart atau pseudocode untuk setiap modul, tabel identifikasi dan struktur data, tata letak layar dan file, serta rencana uji yang ditulis sekarang, berdasarkan spesifikasi, sebelum kode dibuat.
• pengkodean (implementasi) — tulis program dalam bahasa tingkat tinggi, modul per modul, mengikuti desain; setiap modul diuji saat ditulis.
• pengujian — jalankan program sesuai rencana uji (data normal, tidak normal, ekstrem dan batas) dan perbaiki kesalahan yang ditemukan; pengujian integrasi, alpha, beta dan penerimaan mengikuti tahap ini.
• pemeliharaan — setelah rilis, perbaiki cacat, sesuaikan program dengan perangkat keras, perangkat lunak atau undang-undang baru, dan tingkatkan performanya (lihat di bawah).

Contoh pengerjaan. Lengkapi diagram waterfall Analisis → ? → ? → ? → Pemeliharaan dan jelaskan apa yang terjadi pada tahap desain.

Tahap yang hilang adalah Desain, Pengkodean, Pengujian. Pada tahap desain, kebutuhan diubah menjadi rencana program: masalah diuraikan menjadi modul-modul (diagram struktur), algoritma untuk setiap modul ditulis sebagai pseudocode atau flowchart, struktur data dan identifikasi dipilih, layar dan file ditata, dan rencana uji ditulis berdasarkan spesifikasi.

Diagram struktur

Sebuah diagram struktur menunjukkan dekomposisi hierarkis dari sebuah program ke dalam modul-modul (subrutin) dan parameter yang dilewatkan di antaranya. Setiap modul berupa persegi panjang; garis menghubungkan pemanggil (atas) ke yang dipanggil (bawah); panah kecil menunjukkan data turun dan hasil naik kembali. Desain kemudian dapat dikonversi menjadi pseudocode yang setara.

                CalculatePay
            /        |         \
       GetEmployee  CalculateBonus  CalculateTax
       Returns:     Takes: sales    Takes: gross
       employeeID   Returns: bonus  Returns: tax

Ini adalah alat pada tahap desain, dan Anda dapat membaca tanda tangan prosedur darinya.

Simbol yang ditanyakan penguji. Kotak adalah modul; garis menghubungkan pemanggil (atas) ke modul yang dipanggilnya (bawah), dibaca dari kiri ke kanan sesuai urutan pemanggilan. Panah kecil dengan lingkaran terbuka di pangkalnya adalah pasangan data — parameter yang dikirim turun ke dalam modul atau nilai yang dikembalikan naik; panah dengan lingkaran terisi adalah pasangan kontrol, yaitu flag (biasanya BOOLEAN) yang memberi tahu pemanggil apa yang telah terjadi. Berlian pada percabangan berarti pemilihan: hanya satu dari modul-modul di bawahnya yang dipanggil, tergantung pada suatu kondisi. Panah melengkung yang menyapu tautan-tautan menandakan iterasi: modul-modul di bawahnya dipanggil berulang kali dalam sebuah loop.

Contoh pengerjaan. Empat modul didefinisikan sebagai PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN dan PROCEDURE Report(Total : INTEGER, Count : INTEGER). Main memanggil ReadData, lalu memanggil IsValid sekali untuk setiap nilai yang dibaca, lalu memanggil Report. Jelaskan diagram strukturnya.

Main di bagian atas; ReadData, IsValid, dan Report berada dalam satu baris di bawahnya, dari kiri ke kanan sesuai urutan pemanggilan. Pada tautan ReadData terdapat pasangan data naik Count (parameter BYREF kembali). Pada tautan IsValid terdapat pasangan data turun Value dan pasangan kontrol naik (hasil BOOLEAN), dengan panah iterasi melengkung melintasi tautan tersebut karena dipanggil untuk setiap nilai. Pada tautan Report terdapat dua pasangan data turun, yaitu Total dan Count. Dibaca dari arah sebaliknya, fungsi adalah modul mana pun yang mengembalikan nilai — header-nya memerlukan RETURNS dan tipe yang dikembalikan.

Diagram transisi-keadaan

Sebuah diagram transisi-keadaan menunjukkan keadaan yang bisa dimiliki sistem dan kejadian yang memindahkannya antar keadaan — cocok untuk mesin penjual otomatis, lampu lalu lintas, antarmuka pengguna. Diagram transisi-keadaan digunakan untuk mendokumentasikan perilaku algoritma atau sistem. Setiap keadaan berupa lingkaran; setiap transisi berupa panah yang diberi label dengan kejadian.

   coin inserted               item selected
[Idle] --------------→ [Awaiting selection] ----------→ [Dispensing]

Hal ini memudahkan penemuan transisi yang hilang ("bagaimana jika koin kedua dimasukkan sementara menunggu pilihan?").

Membaca dan menggambar salah satunya. Setiap transisi diberi label input | output (atau condition | action): apa yang terjadi, lalu apa yang dilakukan sistem saat berubah keadaan. Soal memberikan tabel keadaan saat ini, input, output, keadaan berikutnya dan meminta diagram, atau sebaliknya — setiap baris tabel tepat sama dengan satu anak panah. Pastikan setiap keadaan memiliki panah keluar untuk setiap input yang dapat terjadi, termasuk yang membuat keadaan tetap sama (panah yang melingkar kembali ke keadaan yang sama).

Contoh pengerjaan. Pengontrol pompa memiliki keadaan pump off dan pump on. Dalam pump off, input low level detected menghasilkan output activate pump dan berpindah ke pump on; dalam pump on, normal level detected menghasilkan deactivate pump dan berpindah ke pump off. Input lainnya membuat keadaan tetap tidak berubah. Gambarlah tabelnya.

Dua baris "tidak ada perubahan" menjadi panah loop pada diagram; melewatinya akan kehilangan nilai karena kelengkapan.

• kesalahan sintaks — melanggar tata bahasa bahasa pemrograman (kurung hilang, kata kunci salah eja). Terdeteksi saat penterjemahan; program tidak akan berjalan hingga diperbaiki.
• kesalahan waktu jalannya — terjadi saat program dieksekusi (pembagian dengan nol, file tidak ditemukan, indeks array di luar jangkauan). Program mengalami crash atau memunculkan pengecualian; perbaiki dengan menambahkan pengecekan.
• kesalahan logika — program berjalan tetapi menghasilkan hasil yang salah (menggunakan + untuk -, kesalahan satu langkah dalam perulangan, kondisi dalam urutan yang salah). Paling sulit ditemukan; satu-satunya tanda adalah output yang salah, jadi gunakan pengujian dan pelacakan yang teliti.

Mendedahkan dan menghindari cacat. Cacat didedahkan melalui pengujian terhadap rencana uji, melalui simulasi kering atau tabel pelacakan, melalui walkthrough dengan rekan sejawat, dan melalui debugger IDE (titik henti, langkah tunggal, pemantauan variabel). Cacat dihindari dengan merancang sebelum coding (diagram struktur, pseudocode), dengan kode modular yang memiliki penanda dan komentar bermakna, dengan validasi setiap input, dengan penanganan pengecualian alih-alih membiarkan kesalahan waktu jalannya membuat program crash, dan dengan pengecekan sintaks dinamis IDE saat mengetik.

Contoh dikerjakan. Sebutkan jenis kesalahan pada setiap kasus dan bagaimana ia bermanifestasi. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) dijalankan dengan y = "0". (b) Baris yang sama dijalankan dengan x = "12a". (c) Perulangan yang ditulis sebagai FOR i <- 1 TO 9 memproses array beranggotakan sepuluh. (d) OUTPUT "Total: " Total koma hilang.

(a) Kesalahan waktu jalannya — pembagian dengan nol; program mengalami crash ketika baris ini dieksekusi dengan data tersebut. (b) Kesalahan waktu jalannya — string tidak dapat dikonversi menjadi angka. (c) Kesalahan logika — program berjalan tetapi elemen kesepuluh tidak pernah diproses, sehingga outputnya salah. (d) Kesalahan sintaks — pernyataan melanggar aturan bahasa dan dilaporkan oleh penterjemah sebelum program dijalankan.

Contoh dikerjakan. Perbaiki kesalahan dalam pseudocode ini, yang seharusnya menghasilkan rata-rata dari sepuluh nilai.

Total <- 0
FOR i <- 1 TO 10
    INPUT Mark
    Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average

Pembagian harus dengan 10, bukan 9 (kesalahan logika); baris output memerlukan koma atau & antara string dan nilai (kesalahan sintaks); dan Average tidak pernah dideklarasikan sebagai REAL (kesalahan sintaks atau waktu jalannya, tergantung bahasanya). Sebutkan nomor baris dan apa baris yang telah diperbaiki: Average <- Total / 10.

• simulasi kering — menelusuri kode di atas kertas, mencatat nilai setiap variabel dalam tabel.
• walkthrough — tinjauan tim terhadap kode.
• pengujian kotak putih — dirancang berdasarkan struktur internal kode, mencakup setiap pernyataan, cabang, dan perulangan.
• pengujian kotak hitam — dirancang hanya berdasarkan spesifikasi: masukkan input, periksa output.
• pengujian integrasi — gabungkan modul dan uji antarmuka di antaranya.
• pengujian alpha α — dilakukan oleh pengembang/in-house sebelum rilis; pengujian beta β — dilakukan oleh kelompok terbatas pengguna nyata di lingkungan mereka sendiri.
• pengujian penerimaan — dilakukan oleh pelanggan, untuk memutuskan apakah produk layak guna.
• stub — placeholder untuk modul yang belum ada, sehingga struktur dapat diuji secara top-down.

Metode mana, kapan. Simulasi kering dan walkthrough tidak memerlukan komputer—simulasi kering dilakukan Anda sendiri, menelusuri algoritma dengan tabel pelacakan; walkthrough adalah pertemuan di mana penulis menjelaskan kode baris demi baris dan rekan sejawat mencari cacat, sehingga juga menyebarkan pengetahuan kode melalui tim dan memverifikasinya terhadap desain. Pengujian kotak putih ditulis oleh seseorang yang dapat melihat kode dan bertujuan untuk melintasi setiap jalur; pengujian kotak hitam ditulis dari spesifikasi dan hanya memeriksa input terhadap output yang diharapkan, sehingga pengguna atau tester terpisah dapat melakukannya. Pengujian integrasi mengikuti pengujian modul: modul yang lolos sendirian bisa gagal jika data yang diteruskan di antaranya bertipe atau berurutan salah. Pengujian alpha dilakukan in-house; pengujian beta memberikan calon rilis kepada sampel pengguna nyata, yang melaporkan cacat dari penggunaan riil; pengujian penerimaan adalah pelanggan yang memeriksa produk jadi terhadap persyaratan sebelum membayarnya. Stub memungkinkan pengujian top-down dimulai sebelum semua modul tersedia.

Contoh dikerjakan. Setelah program lulus uji in-house, program diberikan kepada sekelompok pengguna untuk dicoba sebelum dirilis. Sebutkan nama jenis pengujian ini, dan jelaskan apa yang terjadi selanjutnya.

Pengujian beta — pengguna nyata di lingkungan mereka sendiri, melaporkan cacat yang tidak ditemukan pengembang. Cacat diperbaiki, kemudian pelanggan melakukan pengujian penerimaan terhadap persyaratan dan program dirilis; cacat yang ditemukan dalam penggunaan langsung kemudian ditangani oleh pemeliharaan korektif.

Contoh dikerjakan. Berikan tiga manfaat pengujian program melalui walkthrough.

Kesalahan ditemukan oleh orang yang tidak menulis kode tersebut, sehingga membacanya tanpa asumsi; logika dicek terhadap desain dan spesifikasi, bukan hanya terhadap data uji; beberapa orang mempelajari cara kerja kode, yang membantu pemeliharaan di masa depan; dan tidak diperlukan data uji atau komputer yang berfungsi, sehingga hal ini dapat dilakukan lebih awal.

Strategi pengujian adalah pendekatan tingkat tinggi — jenis pengujian apa saja, siapa yang melakukannya, kapan, dan kriteria untuk melanjutkan. Rencana pengujian adalah daftar detail tes — masing-masing dengan data input, output yang diharapkan, dan kolom untuk output aktual.

Apa yang terkandung di dalamnya. Strategi pengujian menyatakan metode pengujian mana yang akan digunakan pada tahap mana (pengujian modul oleh programmer, kemudian integrasi, alpha, beta, penerimaan), siapa yang bertanggung jawab atas masing-masing, data uji apa yang diperlukan, dan kriteria untuk lanjut ke tahap berikutnya. Rencana pengujian mencantumkan tes individu: untuk setiap tes, modul atau fitur yang sedang diuji, data input, alasan data dipilih (normal, abnormal, ekstrem, batas), hasil yang diharapkan, ruang untuk hasil aktual, dan apa yang harus dilakukan jika berbeda. Rencana ditulis pada tahap desain, dari spesifikasi, sehingga menguji apa yang program seharusnya lakukan daripada apa yang kebetulan dilakukannya.

Memilih data uji

Untuk setiap bidang atau kondisi, sertakan tiga jenis:

• data normal — nilai tipikal dalam rentang valid (untuk nilai 0–100: 50, 75).
• data abnormal — nilai yang seharusnya ditolak (-10, 200, "abc").
• data ekstrem — nilai terbesar dan terkecil yang masih diterima (0 dan 100).
• data batas — nilai di tepi, di mana kesalahan off-by-one bersembunyi (setiap nilai ekstrem yang diterima dan nilai yang ditolak tepat di luarnya: 0/-1, 100/101).

Contoh dikerjakan. Sebuah bidang menerima nilai ujian dari 0 hingga 100. Berikan data uji dari setiap jenis beserta hasilnya yang diharapkan. Normal: 50 - diterima, nilai tipikal di dalam rentang. Abnormal: -10, 200, "abc" - semua ditolak, karena berada di luar rentang atau tipe data salah. Ekstrem: 0 dan 100 - nilai terbesar dan terkecil yang masih diterima. Batas: pasangan yang melintasi setiap tepi - -1 ditolak bersama 0 diterima, dan 100 diterima bersama 101 ditolak. Setiap nilai harus memiliki hasil yang diharapkan, atau rencana pengujian tidak membuktikan apa-apa. Ekstrem dan batas adalah pasangan yang paling sering bingung: nilai ekstrem berada di dalam dan diterima, sementara pengujian batas selalu berupa pasangan di kedua sisi tepi - yang merupakan tempat persis di mana kesalahan off-by-one bersembunyi.

Contoh dikerjakan. Sebuah komponen lolos jika beratnya, diukur hingga gram terdekat, berada dalam 3 g dari target 50 g, yaitu dari 47 g hingga 53 g termasuk. Susun baris rencana pengujian untuk pengecekan.

Setiap baris harus menjelaskan mengapa nilai dipilih dan apa yang harus terjadi; daftar angka kosong tidak mendapat nilai.

Sebagian besar biaya siklus hidup program ada pada pemeliharaan. Tiga jenis:

• pemeliharaan perfective — meningkatkan kinerja atau fitur meskipun sudah bekerja (kueri yang lebih cepat, opsi baru).
• pemeliharaan adaptive — menjaganya tetap berfungsi di lingkungan yang berubah (sistem operasi baru, API baru, perubahan hukum).
• pemeliharaan corrective — memperbaiki bug yang ditemukan saat penggunaan.

Sebuah program mungkin memerlukan ketiganya sepanjang hidupnya.

Mengapa masing-masing diperlukan — alasan yang disebutkan dalam kunci jawaban. Corrective: kesalahan dilaporkan oleh pengguna setelah rilis, atau output yang salah terlihat dalam kondisi tertentu yang tidak tercakup pengujian. Adaptive: sistem operasi, perangkat keras, atau browser ditingkatkan; undang-undang atau aturan perusahaan berubah (tarif pajak, persyaratan perlindungan data); program harus bekerja dengan sistem eksternal atau format file baru. Perfective: pengguna meminta fitur tambahan atau antarmuka yang lebih baik; program dibuat lebih cepat atau menggunakan lebih sedikit memori; kode dirapikan agar perubahan di masa depan lebih mudah.

Contoh dikerjakan. (a) Program yang dirilis menghasilkan nilai yang salah dalam kondisi tertentu. (b) Perangkat keras yang menjalankan program diganti. (c) Pelanggan meminta program loyalitas kedai kopi untuk mengirim pesan pada hari ulang tahun pelanggan. Sebutkan jenis pemeliharaan dalam setiap kasus.

(a) Corrective — sebuah kesalahan dalam program yang dikirim sedang diperbaiki. (b) Adaptive — program diubah untuk berjalan di lingkungannya yang baru. (c) Perfective — fitur ditambahkan ke program yang sudah bekerja.

Ketika diminta untuk menambahkan fitur atau memperbaiki bug:

1. bacalah kode yang ada sampai Anda memahami algoritma dan aliran data.
2. temukan di mana perubahan masuk — subrutin mana, baris mana.
3. perubahan sekecil mungkin — jangan menulis ulang kode yang sudah berfungsi.
4. perbarui bagian terkait — setiap pemanggil dari daftar parameter yang diubah, setiap rutinitas yang menggunakan struktur data yang diubah.
5. uji perilaku baru dan lama (pengujian regresi — pastikan Anda tidak merusak apa pun).
6. dokumentasikan perubahan tersebut.

Komentar yang jelas, nama yang bermakna, subrutin terurai, dan bagan struktur membuat program jauh lebih mudah dimodifikasi — itulah sebabnya alat desain tetap penting bahkan setelah rilis pertama.

Menganalisis program yang bukan buatan Anda. Mulai dari tabel pengidentifikasi dan header modul: mereka memberi tahu apa yang diterima dan dikembalikan oleh setiap modul sebelum Anda membaca satu baris tubuh modulenya. Kemudian lacak algoritma dengan tabel jejak untuk satu input kecil, mencatat dari mana setiap nilai output berasal. Baru kemudian tentukan di mana peningkatan akan ditempatkan — biasanya sebuah modul baru yang dipanggil dari modul yang ada, sehingga kode yang berfungsi terganggu semaksimal mungkin — dan tulis pseudokode untuk perubahan serta data uji yang membuktikannya.

Soal definisi dinilai berdasarkan frasa tetap. Hafalkan ini persis, dan berikan hanya satu jawaban.

• Bandingkan model pengembangan (air terjun, iteratif, RAD) berdasarkan prinsip, manfaat, kekurangan, dan ketahui lima tahap siklus hidup pengembangan program serta产出 yang dihasilkan masing-masing.
• Bedakan kesalahan sintaks, logika, dan waktu jalankan berdasarkan kapan masing-masing muncul: saat penterjemahan, dalam output, selama proses jalankan.
• Pilih data uji dari segala jenis — normal, abnormal, ekstrem, dan batas — dan berikan setiap nilai beserta alasannya dan hasil yang diharapkan.
• Bedakan jenis pemeliharaan (korektif, adaptif, sempurna) berdasarkan mengapa perubahan dilakukan.
• Pada bagan struktur, sebutkan setiap simbol: kotak, garis pemanggil, pasangan data, pasangan kontrol, berlian seleksi, panah iterasi. Membaca header modul dari bagan, ingat bahwa fungsi memiliki RETURNS.

Kesalahan umum

• Menggambarkan tahap siklus hidup hanya dengan namanya (
• Menyebutkan output yang salah sebagai "kesalahan waktu eksekusi". Jika program berjalan hingga selesai, itu adalah kesalahan logika.
• Memberikan data batas hanya sebagai nilai ekstrem. Nilai perlu mencakup kedua sisi dari batas tersebut.
• Memperlakukan pengujian alpha dan beta sama. Alpha dilakukan secara internal oleh pengembang; beta dilakukan oleh pengguna nyata di luar organisasi.
• Mengacaukan pemeliharaan adaptif dan sempurna. Adaptif merespons perubahan di luar program; sempurna meningkatkan program yang tidak perlu diubah.
• Menggambar bagan struktur dengan modul dalam urutan sembarang. Mereka dibaca dari kiri ke kanan sesuai urutan pemanggilannya, dan setiap parameter memerlukan panahnya sendiri.