**Metodologi pengembangan sistem**
----------------------------------

Istilah siklus hidup sistem dan metodologi pengembangan sistem sering kali dipertukarkan secara tidak tepat. Sebagian besar proses pengembangan sistem berasal dari siklus hidup sistem alamiah, sedangkan siklus hidup sistem terjadi begitu saja. Gambar 1 mengilustrasikan dua tahapan siklus hidup. Perhatikan bahwa ada dua peristiwa penting yang memicu perubahan dari satu tahap ke tahap lainnya. Ketika sebuah sistem berputar dari pengembangan ke operasi dan pemeliharaan, konversi harus dilakukan. Pada suatu saat, keusangan terjadi (atau akan segera terjadi) dan siklus sistem dari operasi dan pemeliharaan ke pengembangan ulang.

Sebenarnya, sebuah sistem dapat berada pada lebih dari satu tahap pada saat yang sama, misalnya, satu versi mungkin tidak beroperasi dan mendukung sementara versi berikutnya adalah pengembangan. Jadi, apa bedanya hal ini dengan metodologi pengembangan sistem? Metodologi pengembangan sistem **"menjalankan"** tahap pengembangan sistem dari siklus hidup sistem, setiap sistem informasi individu memiliki siklus hidup sistemnya sendiri, metodologi adalah proses standar untuk membangun dan memelihara sistem tersebut dan semua sistem informasi lainnya melalui siklus hidup mereka, konsisten dengan tujuan CMM, metodologi memastikan hal itu:

* Pendekatan yang konsisten dan dapat direproduksi diterapkan pada semua proyek.

* Risiko yang terkait dengan jalan pintas dan kesalahan berkurang.

* Dokumentasi yang lengkap dan konsisten dihasilkan dari satu proyek ke proyek  berikutnya.

* Analis sistem, perancang, dan pembangun dapat dengan cepat ditugaskan kembali di antara proyek-proyek karena semua menggunakan proses yang sama.

* Karena tim pengembangan dan staf terus berubah, hasil pekerjaan sebelumnya dapat dengan mudah diambil dan dipahami oleh mereka yang mengikuti.

Metodologi dapat dibeli atau dikembangkan sendiri. Mengapa membeli metodologi? Banyak organisasi sistem informasi tidak mampu mendedikasikan staf untuk pengembangan, dan peningkatan berkelanjutan dari metodologi yang dikembangkannya sendiri. Vendor metodologi memiliki kepentingan untuk menjaga agar metodologi mereka tetap mutakhir dengan tren bisnis dan teknologi terbaru. Metodologi buatan sendiri biasanya didasarkan pada metodologi, dan teknik umum yang didokumentasikan dengan baik dalam buku dan situs Web.

**Prinsip yang diperlukan oleh Metodologi untuk Mengembangkan Sistem**

Sebelum kita membahas sebuah metodologi (dalam hal ini yang disebut FAST), terdapat beberapa prinsip umum yang harus mendasari semua metodologi pengembangan sistem:

**Prinsip 1**: **Libatkan Pengguna Sistem**

Para analis, pemrogram, dan spesialis teknologi informasi lainnya sering kali mengacu pada "sistem saya". Sikap ini, sebagian telah menciptakan konflik "kita versus mereka" antara staf teknis dengan pengguna, dan manajemen. Meskipun para analis dan programmer bekerja keras untuk menciptakan solusi teknologi yang mengesankan, solusi tersebut sering kali menjadi bumerang karena tidak mengatasi masalah organisasi yang sebenarnya. Terkadang mereka bahkan menimbulkan masalah organisasi yang baru. Untuk alasan ini, keterlibatan pengguna sistem adalah kebutuhan mutlak untuk pengembangan sistem yang sukses. Pikirkan pengembangan sistem sebagai kemitraan antara pengguna sistem, analis, perancang, dan pembangun. Analis, perancang, dan pembangun bertanggung jawab atas pengembangan sistem, tetapi mereka harus melibatkan pemilik dan pengguna sistem, meminta partisipasi mereka, dan mencari persetujuan dari semua pemangku kepentingan mengenai keputusan yang dapat mempengaruhi mereka.

Miskomunikasi, dan kesalahpahaman terus menjadi masalah yang signifikan dalam banyak proyek pengembangan sistem. Namun, keterlibatan pemilik, dan pengguna serta edukasi dapat meminimalisir masalah tersebut. Membantu untuk mendapatkan penerimaan atas ide-ide baru serta perubahan teknologi. Karena orang cenderung menolak perubahan, teknologi informasi sering dipandang sebagai ancaman. Cara terbaik untuk mengatasi ancaman tersebut adalah melalui komunikasi yang konstan, menyeluruh dengan pemilik dan pengguna.

**Prinsip 2**: **Gunakan Pendekatan Pemecahan Masalah**

Metodologi pengembangan sistem, pertama dan terutama, adalah pendekatan pemecahan masalah untuk membangun sistem. Istilah masalah digunakan secara luas untuk mencakup (1) masalah nyata, (2) peluang untuk perbaikan, dan (3) arahan dari manajemen. Pendekatan pemecahan masalah klasik adalah sebagai berikut:

* Mempelajari dan memahami masalah, konteks, dan dampaknya.

* Tentukan persyaratan yang harus dipenuhi oleh setiap solusi.

* Mengidentifikasi kandidat solusi yang memenuhi persyaratan, dan memilih solusi yang terbaik.

* Merancang dan/atau mengimplementasikan solusi yang dipilih.

* Mengamati dan mengevaluasi dampak dari solusi tersebut, dan menyempurnakan solusi tersebut.

**Prinsip 3**: **Tetapkan Fase dan Aktivitas Semua metodologi menetapkan fase dan aktivitas.**

Jumlah dan cakupan fase dan aktivitas bervariasi dari satu penulis ke penulis lainnya, dari satu ahli ke ahli lainnya, dari satu metodologi ke metodologi lainnya, dan dari satu bisnis ke bisnis lainnya. Fase-fase tersebut tercantum di sisi paling kanan dari ilustrasi. Pada setiap fase, fokusnya adalah pada blok-blok pembangun dan pemangku kepentingan yang berada di sebelah kiri fase tersebut. Fase-fase tersebut adalah: definisi ruang lingkup, analisis masalah, analisis persyaratan, desain logis, analisis keputusan, desain fisik dan integrasi, konstruksi dan pengujian, serta instalasi dan pengiriman. Masing-masing fase ini akan dibahas nanti dalam bab ini. Fase-fase ini tidak sepenuhnya berurutan.  Fase-fase tersebut cenderung tumpang tindih satu sama lain, seperti yang diilustrasikan pada Gambar 2. Selain itu, fase-fase tersebut dapat disesuaikan dengan kebutuhan khusus dari suatu proyek (misalnya, tenggat waktu, kompleksitas, strategi, sumber daya).

**Sejarah Singkat Metodologi Pengembangan Sistem**
--------------------------------------------------

**Metodologi Siklus Hidup Pengembangan Perangkat Lunak**

Metodologi SDLC (A System or Software development life cycle) dapat dibagi menjadi dua kategori besar. Kategori pertama adalah metodologi tradisional atau klasik yang lebih berkonsentrasi pada pengumpulan semua persyaratan di awal sebelum pengembangan dan membuat produk secara bertahap. Selain itu, salah satu karakteristik utama dari pendekatan SDLC ini adalah adanya tinjauan komprehensif oleh para pemangku kepentingan utama di akhir setiap fase. Pendekatan untuk SDLC adalah Agile. Pendekatan ini menghargai hubungan antara pelanggan dan pemangku kepentingan dengan tim untuk menghasilkan produk secara bertahap menggunakan sprint. Pada bagian berikut, beberapa metode tradisional dan agile yang umum akan dibahas.

**Metodologi SDLC Tradisional**

Metodologi SDLC tradisional yang dibahas di sini adalah model Waterfall, model Spiral, dan model RAD. Juga, beberapa kelebihan dan kekurangan yang dimiliki dan kapan model tersebut paling baik diterapkan.

**Model Waterfall**

Metodologi waterfall dianggap sebagai upaya pertama oleh industri TI untuk memiliki struktur dalam desain dan pengembangan sistem yang kompleks. Metodologi waterfall terdiri dari menyelesaikan setiap langkah sebelum pindah ke langkah berikutnya. Fase-fase dari model waterfall adalah perencanaan, analisis, desain logis, desain fisik, implementasi, dan pemeliharaan. Namun demikian, langkah-langkah tersebut berubah antara tim dan penulis karena poin utama dari pendekatan ini adalah fase-fase tersebut dilakukan secara berurutan dan tidak ada jalan untuk kembali. Sebagai contoh, penulis lain menganggap fase-fase waterfall sebagai definisi, konstruksi, dan implementasi.

Beberapa kekuatan dari model ini antara lain:

* Mudah dipahami dan dikelola.
* Model ini bekerja dengan baik dengan aplikasi kompleks yang besar.
* Model ini bekerja dengan baik ketika anggota tim berada di lokasi yang berbeda.
* Tidak membutuhkan pengalaman yang baik dari anggota tim.

Kelemahan dari Model Waterfall yang dapat mempengaruhi pengembangan proyek adalah:

* Perubahan sangat sulit untuk diakomodasi dan diimplementasikan.

* Semua persyaratan harus diketahui sebelum memulai proyek.

* Tidak memungkinkan tim untuk melakukan perubahan pada fase sebelumnya.
* Hanya ada sedikit komunikasi antara pengguna, pemangku kepentingan, dan tim.

Model Waterfall dapat bekerja dengan baik untuk situasi berikut:

* Semua kebutuhan sudah diketahui sebelumnya, dan tidak akan berubah.

* Semua hal yang berisiko tinggi dalam persyaratan telah diselesaikan.

* Ada cukup waktu untuk melakukan pekerjaan secara berurutan dan tim memiliki pengalaman dengan proyek yang sama atau serupa.

**Model Spiral**

Model spiral dikembangkan oleh Dr. Barry W. Boehm, dan merupakan model berbasis risiko yang mencoba untuk mengatasi masalah-masalah pada Model Waterfall. Model spiral menambahkan potensi pengembangan yang cepat pada pendekatan waterfall dengan mengembangkan perangkat lunak dalam serangkaian rilis evolusioner. Nama untuk model ini adalah karena model ini dipandang sebagai spiral ketika mengembangkan produk dan setiap revolusi mencakup peningkatan pada versi perangkat lunak sebelumnya. Aktivitas model spiral ditentukan oleh tim teknik sehingga ketika mereka menyelesaikan sebuah revolusi, mereka dapat mengembangkan atau menambah prototipe.

Kelebihan dari model spiral dirangkum sebagai:

* Memungkinkan para pemangku kepentingan untuk meninjau proyek dan membuat keputusan untuk melanjutkan atau tidak.

* Model ini memungkinkan perubahan tidak seperti Model Waterfall karena, setelah satu siklus, model ini dapat mengadopsi perubahan baru dalam siklus berita.

* Perkiraan waktu menjadi lebih akurat selama beberapa siklus dan sisanya dikeluarkan dari proyek.

* Hal ini baik untuk masalah yang besar dan kompleks karena dapat menangani umpan balik dari pelanggan. Rilis perangkat lunak awal dalam siklus hidup.

Kekurangan dari model spiral meliputi:

* Bisa jadi lebih mahal daripada model air terjun ketika diimplementasikan. Keberhasilan proyek sangat bergantung pada fase analisis risiko.

* Analisis risiko membutuhkan keahlian yang sangat tinggi dari analis.
* Model ini tidak cocok untuk proyek-proyek kecil.
* Model spiral bekerja dengan baik untuk jenis proyek yang dilakukan oleh waterfall, tetapi dengan keuntungan bahwa model ini juga bekerja untuk proyek-proyek berisiko tinggi dan proyek-proyek yang dapat mengubah persyaratan selama pengembangan.

**Model RAD**

Rapid Application Development (RAD) adalah sebuah metodologi yang muncul pada tahun 1990-an dan mencoba untuk mengatasi kelemahan dari metodologi sebelumnya dengan memodifikasi fase SDLC untuk mengembangkan bagian-bagian dari sistem dengan cepat dan merilisnya kepada pengguna. Dengan pendekatan ini, pengguna dapat memahami apa yang dilakukan oleh sistem dan bagaimana sistem melakukannya serta memberikan umpan balik kepada para insinyur tentang apa yang harus diperbaiki. Metode ini terdiri dari empat fase yaitu perencanaan kebutuhan, desain pengguna, konstruksi, dan peralihan. Selain itu, terdapat interaksi yang berkelanjutan antara fase desain pengguna, dan fase konstruksi. Kode dibuat secara interaktif dan bertahap sambil mengurangi banyak perencanaan. Fase "cutover" sangat mirip dengan tugas akhir dari waterfall, dan ini mencakup konversi data, pengujian, dan implementasi sistem baru yang dipadatkan ke dalam satu fase.

Keuntungan dari model RAD adalah:

* Sistem dapat dikembangkan lebih cepat daripada pendekatan tradisional SDLC.
* Dengan melibatkan pelanggan dan pemangku kepentingan sebagai partisipan aktif dalam pendefinisian kebutuhan, maka akan mengurangi kemungkinan untuk meninggalkan fitur-fitur penting dari sistem.
* Hal ini mendorong rasa memiliki pelanggan karena pengguna bekerja bersama tim selama pengembangan dan pembuatan prototipe sistem.
* Memungkinkan penguji untuk menangkap bug lebih awal dalam pengembangan fungsionalitas utama.

Namun, seperti halnya metodologi lainnya, RAD memiliki kekurangan. Ketika pengembang membuat prototipe sistem, pengguna mungkin berpikir bahwa pekerjaan hampir selesai, dan mengharapkan sistem lebih awal dari yang direncanakan.

Metodologi RAD bekerja dengan baik ketika tim terdiri dari pengembang dan analis yang berpengalaman. Selain itu, metodologi ini lebih disukai daripada model-model yang telah disebutkan sebelumnya ketika pengguna sudah mahir dan terlibat dalam proyek.

**Metodologi Agile**

Pengembangan tangkas mengacu pada pendekatan pengembangan perangkat lunak yang lebih berkonsentrasi pada reaksi cepat terhadap perubahan kebutuhan pengguna sambil memberikan nilai kepada pelanggan melalui pembaruan produk tambahan. Metodologi agile merupakan reaksi terhadap kegagalan pendekatan model SDLC tradisional yang lebih berkonsentrasi pada pengumpulan kebutuhan pengguna terlebih dahulu dan membuat dokumentasi yang besar daripada benar-benar memberikan produk lebih awal dan mengumpulkan umpan balik dari pengguna yang sebenarnya. Beberapa model yang paling populer berdasarkan prinsip-prinsip agile adalah Scrum, Extreme Programming (XP), dan Kanban.

**Scrum**

Scrum adalah kerangka kerja agile yang membantu tim untuk merilis produk secara bertahap dengan menggunakan sprint dan mendapatkan umpan balik dari pelanggan dan pemangku kepentingan sedini mungkin. Ini dikembangkan oleh Ken Schwaber dan Jeff Sutherland dengan konsep bahwa pengembangan perangkat lunak bukanlah proses yang terdefinisi dan lebih berfokus pada empirisisme. Seperti yang dijelaskan dalam Scrum Guide, empirisme didasarkan pada gagasan bahwa pengetahuan berasal dari pengalaman, dan keputusan yang perlu diambil selama proyek berlangsung didasarkan pada apa yang diamati. Selain itu, Scrum tidak memiliki peran manajer proyek resmi dan pekerjaan manajer proyek didistribusikan di antara anggota tim. Peran dalam Scrum adalah pemilik produk yang merupakan orang yang memutuskan prioritas proyek berdasarkan umpan balik yang diterima dari para pemangku kepentingan. Scrum Master mengawasi dan memastikan bahwa kerangka kerja Scrum diimplementasikan dengan benar dan menghindari masalah yang menghambat para pengembang untuk menyelesaikan pekerjaan mereka. Terakhir, peran lainnya adalah developer yang merupakan pihak yang membuat increment atau hasil dari proyek.

Keuntungan dari Scrum meliputi:

* Proyek lebih mudah dikelola.
* Peran dan tanggung jawab anggota tim didefinisikan dengan baik sehingga lebih sedikit ruang untuk konflik.
* Semua artefak dan kemajuan proyek dapat dilihat oleh semua orang.
* Komunikasi aktif dari semua orang yang terlibat dalam proyek.
* Kemajuan masih dibuat ketika persyaratan tidak terlalu jelas.

Ada beberapa kelemahan dari penggunaan Scrum adalah:

* Lebih sulit untuk menerapkan Scrum dalam tim yang sangat besar. Tim harus dibagi menjadi beberapa kelompok yang terdiri dari sembilan atau lebih sedikit anggota.
* Koordinasi beberapa tim Scrum pada proyek yang berbeda sangat kompleks.
* Hal ini membutuhkan pemantauan proyek secara konstan dari sisi kuantitatif dan kualitatif.

Scrum bekerja paling baik dalam proyek-proyek kompleks di mana persyaratannya tidak terlalu jelas karena memungkinkan tim menghasilkan produk sambil mengumpulkan umpan balik dari pengguna dan memastikan bahwa perubahan dan peningkatan yang dilakukan pada produk tersebut layak untuk dilakukan.

**Pemrograman Ekstrim**

Extreme Programming atau XP adalah tentang siklus pengembangan yang pendek dan perencanaan tambahan yang terkonsentrasi pada tes otomatis yang ditulis oleh programmer untuk memantau proses pengembangan. XP juga populer karena memungkinkan respon yang cepat terhadap perubahan, dan memiliki dua ide radikal yang populer saat ini: pemrograman berpasangan dan pengembangan berbasis uji coba. Pemrograman berpasangan mengacu pada penggunaan dua pemrogram yang bekerja dan berinteraksi pada kode yang sama dan komputer yang sama untuk saling mengawasi dan menghasilkan perangkat lunak yang mengikuti praktik terbaik. Pengembangan berbasis uji coba adalah tentang membuat pengujian yang memvalidasi kode sebelum melakukan pengkodean, sehingga pengembang memastikan bahwa kode tersebut mengikuti standar kualitas tinggi.

Kekuatan dari model ini adalah:

* Membuat proyek lebih mudah dikelola.
* Ada peningkatan dalam komunikasi tim.

Beberapa kekurangannya antara lain:

* Beberapa programmer yang biasa bekerja sendiri merasa kesulitan untuk beradaptasi dengan pendekatan pemrograman berpasangan.
* Pelanggan harus selalu tersedia karena pelanggan adalah orang yang menggerakkan proyek XP.

Model XP sangat cocok digunakan ketika proyek hanya memiliki tim yang kecil atau menengah dan ketika kebutuhan berubah dengan cepat atau tidak jelas.

**Kanban**

Kanban dalam bahasa Jepang berarti kartu cerita dan merupakan metodologi aliran kontinu untuk mengelola dan mengembangkan produk. Perbedaan utama antara Kanban dan Scrum adalah bahwa dalam Scrum, Anda memiliki sprint untuk mengembangkan bagian dari keseluruhan persyaratan sementara dalam Kanban, ada tarikan terus menerus dari unit pekerjaan yang akan dikembangkan. Meskipun ada sprint dalam Scrum yang memungkinkan tim untuk merencanakan dan memprioritaskan item dalam backlog produk, dalam Kanban pengembang hanya menarik item dengan prioritas tertinggi dari backlog pada saat itu juga setelah mereka menyelesaikan pekerjaan sebelumnya. Beberapa manfaat dari Kanban adalah membatasi "pekerjaan yang sedang berjalan" sehingga pengembang dapat memaksimalkan hasil kerja tim. Selain itu, membatasi "pekerjaan yang sedang berjalan" melindungi tim dari perubahan dengan menurunkan biaya cekung jika ada sesuatu yang harus dimodifikasi karena akan diubah sesegera mungkin.

**Metodologi Tradisional vs Metodologi Agile**

Metodologi Agile berbeda dengan SDLC tradisional dalam memprioritaskan pelanggan dan mengharapkan perubahan setiap saat sehingga dapat mengakomodasi kebutuhan baru. Alih-alih mengumpulkan semua persyaratan, kebutuhan sistem sebagai langkah pertama, metodologi Agile hanya mengumpulkan informasi yang cukup untuk memulai dan menunjukkan sesuatu kepada pelanggan. Hal ini memungkinkan pelanggan memahami arah aplikasi dan memberikan umpan balik untuk memperbaiki kesalahpahaman sedini mungkin. Oleh karena itu, metodologi ini membutuhkan keterlibatan pelanggan saat mengembangkan dan memelihara sistem untuk memberikan umpan balik yang tepat waktu. Jika pelanggan tidak tersedia untuk menjawab pertanyaan, metodologi SDLC yang lebih tradisional lebih tepat digunakan.

Biasanya, pasar tidak dapat menunggu lama untuk sebuah sistem yang akan dikirimkan yang merupakan alasan sebagian besar aplikasi dibangun saat ini menggunakan metodologi agile. Mendapatkan umpan balik dari pasar dan memberikan nilai kepada pelanggan adalah satu-satunya cara untuk mengetahui apakah yang dibangun sudah benar dan apa yang akan digunakan oleh pengguna. Segala sesuatu yang mengarah ke rilis ke pelanggan dapat dianggap sebagai investasi dan semakin banyak yang dirilis sedini mungkin, semakin banyak nilai yang dikirim ke pelanggan dan lebih banyak umpan balik yang dikumpulkan untuk meningkatkan aplikasi.

Contoh yang baik untuk merilis lebih awal untuk mendapatkan umpan balik dari pasar dan dapat beradaptasi dengan kebutuhan pengguna adalah Microsoft dengan Word. Microsoft merilis lebih awal ke pasar Microsoft 1.0 dan Word 2.0 meskipun masih terdapat bug di dalam sistemnya. Namun, Microsoft mampu mendengarkan pelanggan dan mengumpulkan semua umpan balik yang diperlukan untuk mengembangkan Word 3.0 yang menggeser WordPerfect sebagai pengolah kata terkemuka pada tahun 1992. Saat itu, tidak ada metodologi Agile yang diterapkan di mana pun. Namun, Microsoft memahami kebutuhan untuk masuk ke pasar dengan cepat untuk belajar dari pengguna. Metodologi Agile memungkinkan Anda untuk masuk ke pasar lebih awal daripada metodologi tradisional sambil menghindari sistem yang penuh dengan bug dan cacat.

Referensi
---------

1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  Jeffrey L. Whitten and Lonnie D. Bentle. (2007). *systems Analysis and Design Methods*. New York: McGraw Hill.  Parameter `|url-status=` yang tidak diketahui akan diabaikan (bantuan)
2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43  Pramono Pido (2024). "Metode Pengembangan Sistem". *Makalah Teknik Perangkat Lunak Universitas Indonesia*.