SDLC Adalah: Arti, 7 Tahapan, Model & Cara Memilihnya

Sebelum sebuah rumah dibangun, ada urutan yang hampir tidak pernah dilanggar. Pemilik menyampaikan kebutuhan, arsitek menggambar denah, kontraktor membangun, pengawas memeriksa, lalu kunci diserahkan. Setelah dihuni pun, rumah tetap membutuhkan perawatan. Membuat software sebenarnya mengikuti pola yang mirip, hanya saja software jauh lebih mudah diubah sehingga banyak tim tergoda langsung menulis kode.

Akibatnya mudah ditebak: fitur yang dibuat ternyata bukan yang dibutuhkan pengguna, bug baru ketahuan setelah aplikasi dipakai, dan anggaran membengkak karena pekerjaan diulang. Untuk mencegah hal itu, dunia rekayasa perangkat lunak memakai SDLC. Singkatnya, SDLC adalah rangkaian tahapan yang dilalui sebuah software sejak masih berupa ide sampai dipakai dan dirawat. Di artikel ini kita akan membahas arti SDLC, tujuh tahapannya beserta hasil kerja tiap tahap, model-model SDLC, dan cara memilih model yang cocok.

Apa Itu SDLC dan Apa Kepanjangannya?

SDLC adalah singkatan dari Software Development Life Cycle atau siklus hidup pengembangan perangkat lunak. SDLC membagi pembuatan software menjadi beberapa tahap, mulai dari perencanaan sampai pemeliharaan. Setiap tahap punya tujuan, pelaku, dan hasil kerja yang jelas. Acuan internasionalnya adalah standar ISO/IEC/IEEE 12207 tentang proses siklus hidup software.

Di buku sistem informasi, Anda akan menemukan kepanjangan lain, yaitu System Development Life Cycle. Bedanya ada di cakupan. Sistem informasi mencakup software, hardware, data, prosedur, dan orang yang memakainya, sedangkan software development life cycle berfokus pada pembuatan aplikasinya. Karena tahapannya hampir sama, keduanya sama-sama disingkat SDLC.

Kata "siklus" dipakai karena prosesnya tidak berhenti saat aplikasi dirilis. Laporan bug, perubahan regulasi, dan permintaan fitur dari tahap pemeliharaan menjadi bahan perencanaan putaran berikutnya. Aplikasi yang dipakai sepuluh tahun bisa melewati puluhan putaran siklus SDLC.

SDLC Bukan Waterfall: Kerangka dan Model Itu Berbeda

Banyak mahasiswa menyamakan SDLC dengan Waterfall karena keduanya diajarkan di pertemuan yang sama. Padahal keduanya berada di tingkat yang berbeda. SDLC menjawab pertanyaan "apa saja yang harus terjadi" agar software layak dipakai. Model SDLC menjawab "kapan dan berapa kali" setiap tahap itu dijalankan.

Cara paling mudah memahaminya adalah melihat tahapan SDLC sebagai daftar pertanyaan wajib. Untuk apa aplikasi dibuat, apa kebutuhan pengguna, bagaimana rancangannya, apakah sudah teruji, dan bagaimana merilis serta merawatnya? Tidak ada model yang boleh melewatkan pertanyaan tersebut. Yang berbeda hanya jadwal menjawabnya:

1. Waterfall: menjawab semua pertanyaan sekali, berurutan, untuk seluruh sistem.
2. Iteratif: menjawabnya berulang kali untuk potongan sistem yang lebih kecil.
3. Spiral: menjawabnya berulang sambil menimbang risiko di setiap putaran.
4. Agile: menjawabnya ulang setiap satu sampai empat minggu bersama klien.

Jadi, jawaban untuk pertanyaan "apa bedanya SDLC dan Waterfall" cukup singkat: Waterfall adalah salah satu cara menjalankan SDLC. Istilah "metode SDLC" yang sering muncul di materi kuliah sebenarnya merujuk ke model-model ini, bukan ke SDLC itu sendiri.

Dari SAGE 1956 sampai DevOps: Asal-Usul SDLC

Gagasan membagi pembuatan program ke dalam tahap-tahap muncul jauh sebelum istilah SDLC populer. Pada Juni 1956, Herbert Benington memaparkan cara timnya membangun program untuk SAGE, sistem pertahanan udara Amerika Serikat. Tahapannya dimulai dari rencana operasional, lalu spesifikasi, coding, beberapa lapis pengujian, dan evaluasi sistem.

Pada Agustus 1970, Winston Royce menerbitkan makalah di konferensi IEEE WESCON. Makalah itu memuat diagram tujuh langkah berurutan yang kini dikenal sebagai Waterfall. Namun, Royce sendiri menyebut penerapan berurutan sederhana itu berisiko dan mengundang kegagalan. Ia lalu menambahkan lima perbaikan, di antaranya mengerjakan proyek dua kali dan melibatkan pelanggan sejak awal. Royce juga tidak pernah memakai kata "waterfall"; istilah itu baru muncul pada 1976 dalam makalah Bell dan Thayer.

Barry Boehm kemudian memperkenalkan model spiral pada 1986, dengan analisis risiko di setiap putaran. Tahun 2001, tujuh belas praktisi merumuskan Agile Manifesto yang menekankan rilis kecil dan umpan balik rutin. Sekitar 2009, gerakan DevOps menyambungkan tahap rilis dan operasional lewat otomatisasi. Jadi, SDLC tidak pernah dimaksudkan sebagai urutan kaku.

7 Tahapan SDLC dan Hasil Kerja Tiap Tahap

Jumlah tahapan SDLC berbeda di setiap sumber. AWS menulis enam tahap, IBM tujuh, dan beberapa buku sistem informasi hanya lima. Isinya sebenarnya sama; perbedaannya hanya soal tahap mana yang digabung atau dipecah. Kami memakai tujuh tahap karena paling mudah dipetakan ke peran orang di dalam tim. Ketujuhnya adalah perencanaan, analisis kebutuhan, desain, implementasi, pengujian, deployment, dan pemeliharaan.

Agar tidak abstrak, kita akan memakai satu contoh SDLC yang sama di setiap tahap. Sebuah klinik pratama dengan tiga dokter melayani sekitar 120 pasien per hari. Setiap pagi antrean menumpuk karena pendaftaran masih ditulis tangan. Pemilik klinik ingin aplikasi pendaftaran online agar pasien bisa mengambil nomor antrean dari rumah.

1. Perencanaan

Tahap perencanaan menjawab pertanyaan paling dasar: apakah proyek ini layak dikerjakan? Tim melakukan studi kelayakan (feasibility study) dari sisi teknis, biaya, operasional, dan hukum. Untuk klinik tadi, targetnya misalnya menurunkan waktu tunggu dari 90 menit menjadi 30 menit, dengan anggaran tertentu dan waktu pengerjaan tiga bulan.

Hasil kerjanya adalah proposal atau project charter yang memuat tujuan, ruang lingkup, anggaran, jadwal, dan risiko. Bagian yang sama pentingnya adalah daftar hal yang tidak dikerjakan. Misalnya, integrasi dengan BPJS Kesehatan ditunda ke putaran berikutnya agar proyek pertama tetap selesai tepat waktu.

2. Analisis Kebutuhan

Tahap ini memastikan tim membangun hal yang benar. Kebutuhan dibagi dua. Kebutuhan fungsional menjelaskan apa yang dilakukan aplikasi, misalnya pasien memilih dokter, mendapat nomor antrean, lalu menerima notifikasi saat gilirannya dekat. Kebutuhan non-fungsional menjelaskan seberapa baik aplikasi bekerja, misalnya sanggup melayani 300 pengguna bersamaan dan terbuka dalam tiga detik di jaringan 4G.

Analis mewawancarai resepsionis, dokter, dan beberapa pasien, lalu menuangkan hasilnya ke dokumen SRS (Software Requirements Specification) dan use case diagram. Di kasus klinik, ada kebutuhan yang lahir dari regulasi. UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi menggolongkan data kesehatan sebagai data pribadi spesifik, sehingga perlindungannya harus dirancang sejak tahap ini.

3. Desain Sistem

Desain menjawab pertanyaan "bagaimana kebutuhan tadi diwujudkan". Tim menentukan arsitektur, misalnya aplikasi web, basis data, dan layanan notifikasi WhatsApp. Tim juga merancang struktur basis data lewat ERD (Entity Relationship Diagram) berisi tabel pasien, dokter, jadwal, dan antrean. Antarmuka digambar sebagai wireframe, sedangkan alur proses dipetakan dengan flowchart.

Hasilnya dikumpulkan dalam dokumen desain (Software Design Document). Keputusan di tahap ini paling sulit diubah belakangan, karena seluruh kode dibangun di atasnya.

4. Implementasi

Implementasi adalah tahap coding, saat rancangan diterjemahkan menjadi kode. Developer bekerja dengan version control seperti Git agar setiap perubahan tercatat. Setiap perubahan juga diperiksa rekan lewat code review sebelum digabungkan.

Hasil kerjanya berupa kode sumber di repositori dan build aplikasi yang bisa dijalankan. Di proyek klinik, satu developer memegang alur pendaftaran pasien, satu lagi memegang dasbor resepsionis.

5. Pengujian

Pengujian memastikan aplikasi bekerja sesuai kebutuhan yang disepakati di tahap kedua. Lapisannya dimulai dari unit testing (fungsi per fungsi) dan pengujian integrasi antarmodul. Setelah itu ada pengujian sistem secara utuh, lalu UAT (User Acceptance Testing), yaitu uji coba oleh pengguna saat resepsionis mencoba sendiri aplikasinya.

Untuk klinik, penguji mensimulasikan 300 pengguna bersamaan dan memeriksa apa yang terjadi bila dua pasien memilih slot yang sama di detik yang sama. Hasil kerjanya berupa skenario uji (test case) dan laporan bug. Tahap ini tidak murah: IBM mencatat pengujian bisa menyerap hampir 33% biaya pengembangan sistem.

6. Deployment

Deployment adalah tahap merilis aplikasi ke lingkungan production yang dipakai pengguna sungguhan. Sebelumnya, aplikasi biasanya dijalankan dulu di lingkungan staging yang meniru production. Rilis bertahap juga mengurangi risiko, misalnya membuka pendaftaran online untuk satu dokter dulu selama dua minggu.

Hasil kerjanya adalah aplikasi yang sudah berjalan, catatan rilis, panduan pengguna, dan pelatihan untuk resepsionis.

7. Pemeliharaan

Pemeliharaan berlangsung selama aplikasi dipakai, dan standar ISO/IEC 14764 membaginya menjadi empat jenis:

1. Korektif: memperbaiki bug yang ditemukan pengguna lewat debugging.
2. Adaptif: menyesuaikan aplikasi dengan perubahan lingkungan, seperti versi sistem operasi baru atau aturan baru.
3. Perfektif: menambah fitur atau meningkatkan performa.
4. Preventif: mencegah masalah sebelum muncul, misalnya memperbarui library yang rentan.

Enam bulan setelah rilis, pemilik klinik meminta integrasi BPJS Kesehatan yang dulu ditunda. Permintaan ini kembali masuk ke tahap perencanaan dan memulai putaran kedua. Di sinilah kata "siklus" pada SDLC benar-benar terlihat.

Tahap	Pertanyaan kunci	Hasil kerja	Pihak utama
Perencanaan	Layak dan berapa biayanya?	Proposal, project charter	Pemilik & manajer proyek
Analisis kebutuhan	Apa kebutuhan pengguna?	SRS, use case diagram	Analis sistem, pengguna
Desain	Bagaimana mewujudkannya?	Arsitektur, ERD, wireframe	Arsitek, desainer UI
Implementasi	Apakah sudah dibangun?	Kode sumber, build	Developer
Pengujian	Apakah sudah benar?	Test case, laporan bug	QA, pengguna
Deployment	Bagaimana merilisnya?	Aplikasi live, catatan rilis	DevOps, developer
Pemeliharaan	Apa yang perlu diperbaiki?	Tiket perbaikan, rilis lanjutan	Tim support, developer

Macam-Macam Model SDLC yang Paling Sering Dipakai

Model SDLC adalah cara menyusun dan mengulang tahapan tadi. Setiap model lahir untuk menjawab masalah tertentu, jadi tidak ada model yang paling baik untuk semua proyek.

Waterfall

SDLC Waterfall menjalankan tahapan secara berurutan, dan satu tahap baru dimulai setelah tahap sebelumnya disetujui. Model ini cocok bila kebutuhan sudah beku sejak awal, misalnya proyek tender dengan spesifikasi yang tertulis di kontrak. Kelemahannya, klien baru melihat aplikasi menjelang akhir proyek, sehingga kesalahan memahami kebutuhan terlambat diketahui.

V-Model

V-Model adalah pengembangan Waterfall yang memasangkan setiap tahap desain dengan tahap ujinya. Kebutuhan pengguna dipasangkan dengan UAT, desain sistem dengan pengujian sistem, dan desain modul dengan unit testing. Rencana uji ditulis bersamaan dengan desainnya, bukan setelah kode jadi. Pola V ini banyak dipakai di bidang yang menuntut verifikasi ketat, seperti perangkat medis dan otomotif.

Iteratif dan Inkremental

Model iteratif membangun sistem dalam beberapa putaran, dan setiap putaran menyempurnakan versi sebelumnya. Model inkremental memecah sistem menjadi potongan yang langsung bisa dipakai. Di kasus klinik, putaran pertama hanya pendaftaran untuk satu dokter, putaran kedua menambah notifikasi, putaran ketiga menambah dasbor laporan.

Spiral

Model spiral rumusan Boehm menjalankan empat langkah di setiap putaran: menentukan tujuan, menganalisis risiko, membangun dan menguji, lalu merencanakan putaran berikutnya. Risiko terbesar selalu dikerjakan paling dulu. Model ini cocok untuk proyek besar berteknologi baru, tetapi terlalu berat untuk aplikasi kecil.

Prototype

SDLC prototype dimulai dengan membuat purwarupa (prototype) yang ditunjukkan ke pengguna sebelum sistem sebenarnya dibangun. Karena itu, pendekatan ini juga disebut prototyping. Purwarupa bisa berupa desain layar yang bisa diklik atau aplikasi sederhana tanpa basis data. Model ini cocok saat pengguna kesulitan menjelaskan kebutuhannya dengan kata-kata, tetapi langsung tahu "bukan seperti ini" begitu melihat contohnya.

RAD (Rapid Application Development)

RAD menekankan pengembangan cepat dengan siklus pendek, umumnya 60 sampai 90 hari, memakai komponen siap pakai dan keterlibatan pengguna yang intens. Model ini menuntut pengguna yang bisa hadir rutin dan tim yang cukup besar untuk mengerjakan beberapa modul secara paralel.

Agile

Agile menjalankan seluruh tahapan SDLC dalam iterasi pendek satu sampai empat minggu, dan setiap iterasi menghasilkan bagian aplikasi yang bisa dicoba klien. Scrum dan Kanban adalah kerangka kerja paling populer di keluarga ini. Nilai, prinsip, dan perbandingannya dengan Waterfall kami bahas lengkap di artikel Agile adalah.

Model	Kebutuhan di awal	Klien melihat hasil	Toleransi perubahan	Contoh proyek yang cocok
Waterfall	Lengkap dan beku	Menjelang akhir	Rendah	Proyek tender
V-Model	Lengkap dan beku	Menjelang akhir	Rendah	Perangkat medis
Iteratif/inkremental	Garis besar	Tiap putaran	Sedang	Sistem per modul
Spiral	Berkembang tiap putaran	Tiap putaran	Sedang–tinggi	Teknologi baru
Prototype	Belum jelas	Sejak awal (purwarupa)	Tinggi di awal	Aplikasi untuk pengguna awam
RAD	Garis besar	Tiap 60–90 hari	Tinggi	Aplikasi bisnis internal
Agile	Garis besar	Tiap 1–4 minggu	Tinggi	Produk digital

Cara Memilih Model SDLC untuk Proyek Anda

Memilih model SDLC sebaiknya berangkat dari kondisi proyek, bukan dari model yang sedang populer. Lima pertanyaan berikut bisa Anda pakai sebagai patokan praktis:

1. Seberapa jelas kebutuhannya? Jika lebih dari 80% kebutuhan bisa ditulis dan disetujui di awal, Waterfall atau V-Model sudah memadai. Jika klien baru bisa menjelaskan setelah melihat contoh, mulai dengan prototype atau Agile.
2. Berapa lama proyeknya? Proyek di bawah tiga bulan dengan ruang lingkup tetap cukup dijalankan sekali putaran. Proyek di atas enam bulan hampir pasti mengalami perubahan kebutuhan, jadi pilih model iteratif dengan rilis setiap dua sampai empat minggu.
3. Seberapa besar risiko teknisnya? Bila proyek memakai teknologi atau integrasi yang belum pernah dicoba tim, uji dulu bagian tersulitnya lewat prototype teknis atau model spiral.
4. Apakah ada tuntutan audit? Sistem medis, keuangan, dan pemerintahan membutuhkan jejak dokumen verifikasi. V-Model cocok di sini, atau Agile dengan dokumentasi yang disiplin.
5. Seberapa sering klien bisa ditemui? Agile dan RAD membutuhkan perwakilan klien yang hadir setiap satu sampai dua minggu. Jika klien hanya bisa ditemui di awal dan akhir proyek, model iteratif akan tersendat.

Untuk aplikasi klinik di contoh tadi, kebutuhannya cukup jelas dan proyeknya tiga bulan. Namun, resepsionis belum pernah memakai aplikasi antrean. Kombinasi yang masuk akal adalah prototype untuk desain layar di dua minggu pertama, lalu dilanjutkan model inkremental per fitur.

Mengapa SDLC Penting? Kelebihan bagi Tim dan Klien

Manfaat SDLC paling terasa pada proyek yang melibatkan lebih dari dua orang:

1. Biaya dan jadwal lebih bisa diperkirakan: ruang lingkup yang ditulis di tahap perencanaan menjadi dasar estimasi, sehingga klien tahu apa yang dibayar.
2. Setiap orang tahu perannya: analis, desainer, developer, dan penguji punya hasil kerja masing-masing yang bisa diperiksa.
3. Kesalahan ditemukan lebih awal: salah paham kebutuhan terlihat saat SRS ditinjau, bukan saat aplikasi sudah dipakai pasien.
4. Ada jejak dokumen: dokumen kebutuhan dan desain memudahkan audit serta serah terima ke developer baru.
5. Kualitas punya ukuran: kriteria lulus uji sudah ditetapkan sejak analisis, sehingga "selesai" tidak lagi berarti "menurut developer sudah jalan".

Kekurangan SDLC dan Hal yang Perlu Anda Pertimbangkan

SDLC juga punya sisi lain yang perlu Anda pertimbangkan:

1. Dokumentasi bisa berlebihan: halaman promosi yang dikerjakan satu minggu tidak membutuhkan SRS 40 halaman. Semakin kecil proyeknya, semakin ringkas dokumennya.
2. Proses bisa menjadi tujuan: tim sibuk melengkapi formulir setiap tahap, sementara pengguna tetap tidak puas dengan hasilnya.
3. Lambat merespons perubahan: pada model berurutan, perubahan kebutuhan di tengah jalan memaksa tim mundur ke tahap analisis dan desain.
4. Butuh keterampilan, bukan sekadar templat: menyalin templat SRS dari internet tanpa memahami kebutuhan pengguna tetap menghasilkan software yang salah sasaran.

Selain itu, ada satu klaim populer yang perlu diluruskan. Anda mungkin pernah membaca bahwa memperbaiki bug di production "100 kali lebih mahal" dibanding saat tahap desain, lengkap dengan grafik dari "IBM Systems Sciences Institute".

Angka itu ditelusuri peneliti Laurent Bossavit dan Hillel Wayne ke catatan kursus pelatihan internal IBM yang dikutip buku Roger Pressman tahun 1987. Data aslinya tidak pernah ditemukan. Gagasan umumnya tetap masuk akal, terutama bila perbaikan menyentuh desain, tetapi angka 100 kali tidak punya dasar penelitian yang bisa diperiksa.

Secure SDLC: Keamanan di Setiap Tahap

Secure SDLC adalah praktik menempelkan aktivitas keamanan ke setiap tahap SDLC, alih-alih mengujinya sekali menjelang rilis. Pada aplikasi klinik, penerapannya kira-kira seperti ini:

1. Analisis kebutuhan: menulis kebutuhan keamanan, misalnya data rekam medis dienkripsi dan hanya dokter terkait yang bisa membacanya.
2. Desain: melakukan threat modeling (pemodelan ancaman), yaitu memetakan siapa yang mungkin menyerang dan lewat jalur mana.
3. Implementasi: code review keamanan dan pemeriksaan celah di library pihak ketiga.
4. Pengujian: pemindaian kerentanan otomatis dan penetration testing sebelum aplikasi dibuka untuk umum.
5. Deployment dan pemeliharaan: konfigurasi server yang aman, kunci API di luar kode, dan penambalan cepat saat celah baru diumumkan.

Acuan yang paling banyak dipakai adalah NIST SP 800-218 atau Secure Software Development Framework (SSDF) versi 1.1, terbit Februari 2022. SSDF mengelompokkan praktiknya menjadi empat: menyiapkan organisasi (PO), melindungi software (PS), menghasilkan software yang aman (PW), dan merespons kerentanan (RV).

Untuk aplikasi pemerintah di Indonesia, acuannya adalah Peraturan BSSN Nomor 4 Tahun 2021. Pasal 25 mewajibkan pengujian keamanan aplikasi SPBE secara berkala, termasuk mengidentifikasi kerentanan dan mengelola ancaman sejak awal siklus pengembangan. Pasal 26 merinci 13 fungsi keamanan untuk aplikasi web, sedangkan Pasal 28 memuat 7 fungsi untuk aplikasi mobile. Vendor yang mengerjakan aplikasi instansi sebaiknya memasukkan daftar ini ke SRS sejak tahap analisis kebutuhan.

SDLC di Era DevOps dan AI

DevOps tidak menghapus tahapan SDLC, tetapi memendekkan setiap putarannya. Lewat pipeline CI/CD, kode yang selesai ditulis langsung diuji dan dirilis secara otomatis. Satu putaran implementasi sampai deployment yang dulu memakan berminggu-minggu kini bisa selesai dalam hitungan jam.

AI kini juga hadir di hampir setiap tahap. Laporan DORA 2025 dari Google, yang mensurvei hampir 5.000 profesional teknologi, mencatat 90% responden sudah memakai AI dalam pekerjaannya. Namun, hanya 24% yang sangat memercayai hasil AI, sementara 30% hanya sedikit percaya atau tidak percaya sama sekali.

Angka itu menunjukkan ke mana AI menggeser SDLC. AI mempercepat implementasi, pembuatan skenario uji, dan penulisan dokumentasi. Sebaliknya, analisis kebutuhan, code review, dan pengujian justru semakin penting, karena kode buatan AI tetap harus dibuktikan benar sebelum dirilis.

SDLC, STLC, GDLC, dan ALM: Apa Bedanya?

Beberapa istilah berikut sering muncul berdampingan dengan SDLC dan mudah tertukar:

Istilah	Kepanjangan	Cakupan	Hubungan dengan SDLC
SDLC	Software Development Life Cycle	Software dari ide sampai dirawat	Kerangka utama
SDLC (sistem informasi)	System Development Life Cycle	Software, hardware, data, prosedur	Versi yang lebih luas
STLC	Software Testing Life Cycle	Seluruh proses pengujian	Berjalan di dalam tahap pengujian SDLC
GDLC	Game Development Life Cycle	Game, termasuk playtest	Turunan SDLC khusus game
ALM	Application Lifecycle Management	Aplikasi sampai dipensiunkan	Payung yang memuat SDLC

Pertanyaan Umum seputar SDLC

Apakah SDLC hanya untuk proyek besar?

Tidak. Proyek kecil tetap melewati tahapan yang sama, hanya hasil kerjanya lebih ringkas. SRS bisa cukup satu halaman berisi daftar fitur dan kriteria selesai, sedangkan desainnya cukup sketsa layar.

Model SDLC apa yang paling cocok untuk skripsi?

Waterfall dan prototype paling sering dipakai di tugas akhir. Waterfall mudah dipetakan ke bab laporan, karena setiap tahap punya hasil yang bisa dilampirkan. Prototype cocok bila pengguna, misalnya staf tata usaha sekolah, bisa ditemui dua sampai tiga kali untuk mengevaluasi purwarupa. RAD dan Scrum sulit dibuktikan oleh satu orang, karena keduanya mengandaikan tim dengan peran berbeda.

Apakah Scrum termasuk model SDLC?

Scrum adalah kerangka kerja di keluarga Agile, sedangkan Agile termasuk model SDLC. Jadi, tim yang memakai Scrum tetap menjalankan seluruh tahapan SDLC, hanya dipadatkan dalam sprint satu sampai empat minggu.

Apakah SDLC sama dengan manajemen proyek?

Tidak. Manajemen proyek mengatur waktu, biaya, orang, dan risiko sebuah proyek, apa pun jenisnya. SDLC mengatur tahapan teknis yang dilalui software itu sendiri. Dalam praktiknya keduanya berjalan bersamaan: manajer proyek memakai tahapan SDLC sebagai dasar jadwal dan pembagian tugas.

Kesimpulan

SDLC adalah daftar tahapan yang harus dilalui software agar layak dipakai: perencanaan, analisis kebutuhan, desain, implementasi, pengujian, deployment, dan pemeliharaan. Model seperti Waterfall, V-Model, spiral, prototype, dan Agile hanyalah cara berbeda untuk menjadwalkan tahapan tersebut. Pilih model berdasarkan seberapa jelas kebutuhannya, berapa lama proyeknya, besarnya risiko teknis, dan seberapa sering klien bisa terlibat.

Semoga artikel ini membantu.