METODOLOGI PENGEMBANGAN SISTEM INFORMSI

1. METODOLOGI PENGEMBANGAN SISTEM INFORMSI

2. Pentingnya Metodologi dalam Pengembangan Sistem • Pendekatan dalam Pengembangan Sistem • Metodologi Pengembangan Sistem

3. Pendahuluan Metode pengembangan sistem informasi (information systems development methods, ISDM) dibuat untuk menjamin bahwa SI yang dikembangkan dapat diselesaikan tepat waktu, sesuai dengan anggaran, dan sesuai dengan spesifikasi yang ditetapkan

4. System Development Proses Perencanaan Sistem yang ada Analisis Perancangan Permasalahan Kesempatan Instruksi Implementasi Pemeliharaan PengembanganSistem Memecahkanmasalahmeraihkesempatanmemenuhiinstruksi Sistem yang baru

5. Pentingnya Metodologi Pengembangan Sistem • Menjamin adanya konsistensi proses • Diterapkan dalam berbagai jenis proyek • Mengurangi resiko keslahan dan pengambilan jalan pintas • Menuntut adanya dokumentasi yang konsisten yang bermanfaat bagi personal baru dalam tim proyek

6. Pendekatan Pengembangan Sistem Terdapat beberapa pendekatan yang digunakan untuk pengembangan sistem dan dapat dilihat dari beberapa sudut pandang, antara lain: • Metodologi yang digunakan • Sasaran yang ingin dicapai • Cara menentukan kebutuhan dari sistem • Cara mengembangkannya • Teknologi yang digunakan

7. Metodologi yang digunakan • Pendekatan klasik: pendekatan di dalam pengembangan sistem mengikuti tahapan daur/siklus hidup sistem tanpa dibekali alat-alat dan teknik-teknik yang memadai. Permasalahan yang akan timbul antara lain pengembangan software akan sulit, biaya perawatan dan pemeliharaan mahal, kemungkinan kesalahan sistem besar dan keberhasilan sistem kurang terjamin. • Pendekatan terstruktur: pendekatan di dalam pengembangan sistem mengikuti tahapan daur/siklus hidup sistem dan dibekali alat-alat dan teknik-teknik yang memadai.

8. Sasaran yang ingin dicapai • Pendekatan sepotong: pendekatan di dalam pengembangan sistem yang menekankan pada suatu kegiatan atau aplikasi tertentu saja. Dilihat hanya pada sasaran aplikasi saja. • Pendekatan sistem: pendekatan ini memperhatikan sistem informasi sebagai satu kesatuan yang terintegrasi untuk masing-masing kegiatan atau aplikasinya.

9. Cara menentukan kebutuhan dari sistem • Pendekatan bawah-naik (bottom – up), dalam pendekatan ini dilakukan perumusan untuk menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan informasi berdasarkan pada transaksinya. • Pendekatan atas-turun(top – down), pendekatan ini mulai mendefinisikan sasaran dan kebijaksanaan organisasi.

10. Cara mengembangkannya • Pendekatan sistem-menyeluruh, pendekatan yang mengembangkan sistem secara serentak dan menyeluruh. • Pendekatan moduler, pendekatan yang memecah sistem yang rumit menjadi beberapa bagian atau modul yang lebih sederhana.

11. Teknologi yang digunakan • Pendekatan lompatan jauh (great loop approach), menerapkan perubahan secara menyeluruh dengan serentak menggunakan teknologi canggih. • Pendekatan berkembang (evolutionary approach), pendekatan yang menggunakan teknologi canggih hanya untuk aplikasi-aplikasi yang memerlukan saja pada saat itu dan akan terus berkembang dengan mengikuti kebutuhan.

12. Metodologi Pengembangan Sistem

13. Metodologi • Metodologi adalah kesatuan metode-metode, prosedur-prosedur, konsep pekerjaan, aturan yang digunakan oleh suatu ilmu pengetahuan, seni dan disiplin ilmu lainnya.

14. Metode • Metode adalah suatu cara atau teknik sistematis untuk mengerjakan sesuatu. Urut-urutan prosedur untuk penyelesaian masalah ini dikenal dengan istilah Algoritma.

15. Metodologi Pengembangan Sistem • Metodologi pengembangan sistem adalah metode-metode, prosedur-prosedur, konsep-konsep pekerjaan, aturan-aturan yang akan digunakan sebagai pedoman bagaimana dan apa yang harus dikerjakan selama pengembangan ini.

16. Information Systems Development Method (ISDM)

17. Kategorisasi ISDM Secara garis besar Beynon-Davies dan Williams (2003) membagi ISDM ke dalam tiga kelompok utama, yaitu • Metode Terstruktur (structured methods) • Metode Rapid Application Development (RAD) • Metode Berorientasi Obyek (object-oriented methods).

18. Metode Terstruktur (structured methods) Metode terstruktur diperkenalkan pertama kali pada tahun 1980an dan menggunakan model linier dalam proses pengembangan. Input dan output setiap tahap diidentifikasi dengan jelas. Pemodelan data dan proses dilakukan dengan kerangka kerja yang terstruktur. Structured Systems Analysis and Design Method (SSADM) adalah salah satu contoh metode ini.

19. Metode Rapid Application Development (RAD) Metode RAD menggunakan model iterasi proses pengembangan dan secara umum menspesifikasikan tahap berdasar beberapa bentuk prototype (Stapleton, 1997, dalam Beynon-Davies dan Williams, 2003) ). Metode RAD secara umum dapat disesuaikan dengan situasi yang ada karena tidak memberikan detil teknik yang digunakan. Dynamic Systems Development Method (DSDM) adalah contoh metode ini (Avison dan Fitzgerald, 2003).

20. Metode Berorientasi Obyek (object-oriented methods) Metode berorientasi-obyek merupakan metode yang relatif baru dan sekarang menjadi cukup populer di kalangan pengembang sistem informasi (e.g. Iivari dan Maansaari, 1998). Metode ini berfokus pada obyek yang konsisten mulai tahap analisis, perancangan, dan implementasi sistem informasi. Salah satu varian metode ini yang paling komtemporer adalah Unified Modelling Language (UML) yang diperkenalkan oleh (Rumbaugh, Jacobson, dan Booch, 1999).

21. Kategorisasi ISDM Avison dan Fitzgerald (2003) menggunakan pendekatan lain dalam mengelompokkan ISDM. Mereka mendasarkan pada filosofi dasar yang digunakan oleh ISDM. Menurut mereka terdapat enam kelompok ISDM, yaitu: • Metodologi berorientasi proses (process-oriented methodologies) • Metodologi berorientasi obyek (object-oriented methodologies) • Metodologi pengembangan cepat (rapid development methodologies) • Metodologi berorientasi orang (people-oriented methodologies) • Metodologi berorientasi organisasi (organizational-oriented methodologies) • Metodologi campuran (blended methodologies)

22. Kategorisasi ISDM • Metodologi berorientasi proses (process-oriented methodologies) seperti Structured Analysis, Design, and Implementation of Information Systems (STRADIS) dan Yourdon Systems Method (YSM); • Metodologi berorientasi obyek (object-oriented methodologies) seperti Object Oriented Analysis (OOA) dan Rational Unified Process (RUP); • Metodologi pengembangan cepat (rapid development methodologies) seperti Extreme Programming (XP) dan Dynamic Systems Development Method (DSDM);

23. Kategorisasi ISDM • Metodologi berorientasi orang (people-oriented methodologies) seperti Effective Technical and Human Implementation of Computer-Based Systems (ETHICS); • Metodologi berorientasi organisasi (organizational-oriented methodologies) seperti Soft Systems Methodology (SSM) dan Information Systems Work and Analysis Changes (ISAC); dan • Metodologi campuran (blended methodologies) seperti Merise dan Information Engineering (IE).

24. Adopsi ISDM Menurut Iivari dan Maansaari (1998, hal. 504) terdapat beberapa tujuan penggunaan ISDM. ISDM dapat digunakan sebagai • constitutive rule untuk menentukan langkah yang dilakukan; • regulative rule untuk mengatur langkah yang dilakukan; • sumberdaya untuk mendukung langkah yang dilakukan; • reminder untuk mengingatkan langkah apa yang harus dilakukan; • model proses yang ideal, bahkan meski dalam prakteknya sulit diikuti; • media pembelajaran untuk membandingkan praktek yang dilakukan dengan model yang diidealkan

25. Fakta Tentang ISDM • Penelitian yang dilakukan oleh Jenkins (1984) pada 23 perusahaan di Amerika menemukan bahwa penggunaan ISDM justru membengkakkan biaya. • Gumaraes (1985) dan Summer dan Sitek (1986) menemukan bahwa metode terstruktur (structured method) untuk pengembangan sistem informasi tidak banyak digunakan di Amerika. • Kasus serupa juga ditemukan di Eropa. Holt (1997) dan Hardy et al. (1995) menemukan bahwa sekitar 31% perusahaan di Inggris tidak menggunakan metode terstruktur dan secara umum adopsi ISDM masih rendah.

26. Fakta Tentang ISDM • Penelitian lain di Malaysia juga menemukan hal serupa. Selamat et al. (1994) menemukan bahwa dari 40 perusahaan yang disurvei, hanya 8% perusahaan yang menggunakan metode terstruktur dalam mengembangkan sistem informasi. • Penelitian lain (Fitzgerald, 1998) di Amerika menemukan bahwa hanya 40% dari perusahaan yang disurvei menggunakan ISDM, baik dalam bentuk aslinya, dalam bentuk yang telah dimodifikasi, maupun dalam ISDM yang dikembangkan sendiri. Sisanya, 60% tidak menggunakan ISDM dalam mengembangkan sistem informasi.

27. Pertanyaan Pertanyaan yang muncul adalah, mengapa beberapa perusahaan mengadopsi ISDM sedang yang lainnya tidak?

28. Beberapa penelitian telah dilakukan untuk menjawab pertanyaan ini • Kozar (1989) dalam penelitiannya di Amerika menemukan bahwa adopsi ISDM tergantung proyek yang sedang dikerjakan, karakteristik perusahaan, dan karakteristik individu dalam perusahaan. Pada tingkat individual, pengguna ISDM cenderung lebih muda, belum lama bergabung dengan perusahaan, berani mengambil risiko (risk taker), optimis mempunyai kemampuan menggunakan ISDM serta yakin bahwa ISDM sesuai dengan yang diinginkan perusahaan. • Penggunaan teknologi juga ditemukan menpengaruhi adopsi ISDM. Sebuah penelitian di Finlandia (Iivari dan Maansaari, 1998) menemukan bahwa munculnya computer aided software engineering (CASE) tools telah mengubah penggunaan ISDM. Sebelum CASE tools digunakan, sebagian besar perusahaan menggunakan SSADM, namun setelah CASE tools diadopsi, OOA lebih banyak digunakan.

29. Beberapa penelitian telah dilakukan untuk menjawab pertanyaan ini • Penelitian lain yang dilakukan oleh Rahim, Seyal, dan Rahman (1998) di Brunei Darussalam menemukan bahwa adopsi ISDM oleh perusahaan publik lebih tinggi daripada perusahaan swasta. Kematangan dan pengalaman dalam pengembangan sistem informasi juga ditemukan berpengaruh dalam adopsi ISDM. Penelitian sebelumnya menemukan bahwa adopsi ISDM di banyak negara sangat beragam.

30. Adopsi ISDM

31. Alokasi waktu untuk setiap tahap pengembangan SI

32. Keahlian yang Dibutuhkan

33. Manfaat dan Kerugian Adopsi ISDM

34. Kerugian Adopsi ISDM

35. Rapid Aplication Development (RAD)

36. Metodologi RAD • Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari).

37. Rapid Aplication Development (RAD) • Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut : • Business modeling. Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya? • Data modeling. Aliran informasi yang didefinisikan sebagai bagian dari fase business modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan. • Proses modeling. Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data. • Application Generation. RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak. • Testing and turnover.Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

39. Kekurangan model RAD • Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik. • RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

40. Metodologi Waterfall

41. Linear Sequential Model • Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini adalah model yang muncul pertama kali yaitu sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). • Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement.

42. System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition. • Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan. • Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software. • Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer. • Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya. • Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

43. Kekurangan model Waterfall • Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE. • Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya. • Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.