METODOLOGI - METODOLOGI PENGEMBANGAN SISTEM

Presentasi berjudul: "METODOLOGI - METODOLOGI PENGEMBANGAN SISTEM"— Transcript presentasi:

1 METODOLOGI - METODOLOGI PENGEMBANGAN SISTEM

2 Pembahasan Metodologi Berbasis Proses Metodologi Berbasis Object
Metodologi Campuran Metodologi Pengembangan Cepat Metodologi Berorientasi Organisasi dan Manusia

3 Metodologi Berbasis Proses
STRADIS (Structured Analysis, Design, and Implementation of Information Systems) YSM (Yourdon Systems Method)

4 1. STRADIS (Structured Analysis, Design, and Implementation of Information Systems)
STRADIS dikemukakan oleh Gane dan Sarson (1979) STRADIS dianggap dapat diterapkan dalam pengembangan SI, tanpa memperhatikan ukuran sistem dan apakah sistem akan diotomasikan atau tidak Dalam kenyataannya, STRADIS terutama dimanfaatkan dalam lingkungan di mana sebagian dari sistem informasi diotomasikan STRADIS juga dianggap relevan untuk situasi di mana terdapat sistem yang pengembangannya tertunda sedangkan tidak tersedia cukup sumber daya untuk semua sistem baru yang potensial

5 Tahapan STRADIS Studi Awal Studi Detil
Overview DFD of existing system, estimates of time, costs and benefits, report to determine if proceed to next stage Studi Detil Detailed investigation of existing system, current logical DFDs, statement of costs/benefits, impact on staff/procedures Definisi dan rancangan Solusi Alternatif System objective, new logical DFDs, alternative design options Rancangan Fisik Transform/transaction analysis, normalisation, physical file/DB design, design details of error handling, report and screen formats etc

6 2. YSM (Yourdon Systems Method)
Dikemukakan oleh Edward Yourdon (1993) YSM mirip dengan STRADIS yang berorientasi proses Walaupun berbasis pada dekomposisi fungsional/top- down, YSM cenderung menggunakan pendekatan partisi kejadian (event partitioning) yang sering disebut “middle-out” Analis memulai dengan diagram konteks Wawancarai pengguna untuk mendapatkan kejadian-kejadian yang harus ditanggapi sistem YSM melingkupi organisasi dan sistemnya

7 Fase YSM

8 Metodologi Berbasis Object
OOA (Object-Oriented Analysis) RUP (Rational Unified Process)

9 3. OOA (Object-Oriented Analyst)
Diusulkan oleh Coad dan Yourdon (1991) Metode ini berbasiskan pada teknik SOSAS yang terdiri dari 5 aktifitas utama: Subject Dasarnya DFD untuk obyek Object Identifikasi object class dan class hirarki Structure Mendekomposisi menjadi struktur klasifikasi dan komposisi Attriutes Services Atribut dan servis adalah perilaku atau metode untuk masing- masing class yang dikenali Aktifitas berikut tidak harus dilaksanakan secara berurutan, bisa saja dilaksanakan berulang dengan urutan yang berbeda

10 4. RUP (Rational Unified Process)
Jika UML adalah bahasa pemodelan standar, maka RUP merupakan proses atau metodologi pengembangan sistem yang akan menjelaskan bagaimana memanfaatkan UML RUP merupakan proses “proprietary” dari Rational Software. RUP merupakan proses yang bersifat “use-case driven, architecture-centric, iterative and incremental”

11 Sturuktur RUP RUP memiliki sejumlah siklus yang membentuk proyek
Tiap siklus terdiri dari fase: Inception, Elaboration, Construction, dan Transition Workflow adalah deretan aktifitas yang menghasilkan nilai yang dapat diperiksa Terdapat 9 workflow yang dibedakan sebagai 6 workflow rekayasa dan 3 workflow pendukung

12 Ilustrasi Struktur RUP

13 Workflow dalam RUP Business Modeling Workflow Requirement Workflow
Mengembangkan model bisnis dengan menetapkan konteks sistem dan jangkauan organisasi yang menerapkan sistem Mengidentifikasikan masalah yang ada, area desain dan rekayasa ulang, aturan bisnis, dll. Workflow ini tidak wajib terutama jika pengembangan hanya bertujuan menambahkan fitur baru untuk sistem Requirement Workflow Menetapkan bersama stakeholder, apa yang seharusnya dilakukan sistem dan mengapa; mendefinisikan batasan sistem, dan memperkirakan biaya dan jangka waktu Mengumpulkan dan menganalisis kebutuhan fungsional dan nonfungsional

14 Workflow dalam RUP cont.
Analysis and Design Workflow Tujuannya adalah mengubah persyaratan menjadi spesifikasi implementasi Analis memastikan bahwa persyaratan fungsional dipenuhi, dengan mengabaikan persyaratan nonfungsional dan lingkungan run-time Desainer mengambil hasil analisis dan mengadaptasikannya terhadap batasan arsitektur dan persyaratan nonfungsional Implementation Workflow Mengubah rancangan menjadi implementasi Mencakup: perencanaan proses, mengubah kelas dan objek menjadi komponen, menguji tiap komponen, dan membangun versi operasional dari sistem per bagian Tiap komponen perangkat lunak yang terpisah ini akan diintegrasikan meningkat menjadi sistem lengkap Test Workflow Menguji dan memverifikasi interaksi komponen, bahwa semua persyaratan telah diimplementasikan, dan produk berkualitas dalam arti tidak ditemukan cacat dan memenuhi tujuan Sistem akan diuji dalam hal kehandalan, fungsionalitas, dan kinerja

15 Workflow dalam RUP cont.
Deployment Workflow Menyerahkan perangkat lunak kepada pemakai dan mencakup: pengujian dalam lingkungan operasi (beta-testing), pelatihan pemakai, migrasi dari sistem berjalan, pemaketan perangkat lunak, dan instalasi Deployment sangat bergantung pada sifat dari pengembangan perangkat lunak Configuration and Change Management Workflow Menelusuri dan memelihara keutuhan proyek dengan mengawasi dan mengelola permintaan perubahan, biaya perubahan, dan berbagai versi yang ada atas produk dan artefak; termasuk konfigurasi perangkat keras dan lunak Produk dan artefak harus diidentifikasikan, disimpan, dikontrol sejarah dan versinya Project Management Workflow Menyediakan kerangka untuk mengelola proyek dan risiko Menyediakan arahan untuk perencanaan, perekrutan SDM, pengawasan, dan manajemen proyek Environment Workflow Mengenai dukungan proses, metode, dan tool yang relevan dalam proyek

16 Metodologi Berbasis Campuran
SSADM (Structured Systems Analysis and Design Method) IE (Information Engineering)

17 5. SSADM (Structured Systems Analysis and Design Method)
Dikembangkan oleh LBMS (Learmonth and Burchett Management Systems) – konsultan di Inggris – dan CCTA (Central Computing and Telecommunications Agency) – agen pemerintah Inggris dalam layanan sipil. Pendekatan pengembangan sistem yang mendalam dan terstruktur yang merupakan standar untuk aplikasi pemerintah Inggris sejak tahun 1981 Versi modern dari pendekatan SDLC Digunakan biasanya untuk proyek berskala menengah ke atas Didukung CASE tool

18 Tahapan SSADM Tahap 0 - Studi Kelayakan
Untuk menentukan apakah suatu proyek layak diberikan, harus ada bentuk investigasi ke tujuan dan implikasi proyek Tahap 1 Investigasi Lingkungan Saat Ini Untuk tujuan sistem yang baru meungkin beda dengan yang lama , fata yang digunakan mungkin berubah sangat sedikit. Perlu pemahaman dengan dasar peryaratan tahap awal, analisis dan perancangan yang kuat Tahap 2 Sistem Bisnis Pilihan Memutuskan perancangan sistem baru dengan menggunakan output dari tahap sebelumnya Tahap 3 Persyaratan spesifikasi Spesifikasi harus bebas dari kesalahan, ambiguitas dan inkonsistensi Tahap

19 Tahapan SSADM - lanjut Tahap 4 Sistem Pilihan Teknis
Tahapan pertaa menuju implementasi sistem baru dimana pilihan implementasi sistem yang baru dapat dihasilkan Tahap 5 Desain Logis Outputnya adalah implementasi –independe dan berkosentrasi pada persyaratan untuk antarmuka manusia dengan komputer Tahap 6 Desain Fisik Tahap akhir dimana semua spesifikasi logis dari sistem dikonversi ke deskripsi sistem dari sistem perangkat luna

20 6. IE (Information Engineering)
Terdiri dari beberapa versi: Martin and Finkelstein (1981), Martin (1989), dll. Metodologi yang berorientasi ke data namun juga berfokus ke proses/aktifitas dalam tahapan-tahapannya Modelkan data terlebih dulu karena data lebih stabil Mencakup siklus penuh dalam pengembangan sistem Mengandung pandangan organisasional dalam perencanaan teknologi dan sistem informasi Analisis dan pengembangan aplikasi organisasi dilakukan secara top-down Didukung oleh tool khusus seperti IEF (IE Facilities) Menggunakan diagram sebagai alat komunikasi dan penyajian

21 Evolusi IE (Penggunaan yang Luas)
Teknologi basis data Analisis dan manajemen data Model data strategis dan pembentukan prosedur 4GL dan “productivity tool”, seperti: code generator Penyelarasan antara perencanaan sistem informasi dengan perencanaan bisnis strategis Teknik pemodelan proses Teknologi CASE, “encyclopedia”, koordinator pengetahuan RAD (Rapid Application Development) Konsep orientasi objek

22 Empat Tingkatan IE Perencanaan strategi informasi Analisis area bisnis
Perencanaan dan perancangan sistem Konstruksi dan cutover

23 Metodologi Pengembangan Cepat
RAD (Rapid Application Development) XP (Extreme Programming)

24 7. RAD (Rapid Application Development)
JMRAD (James Martins RAD) Model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). Menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem di mana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

25 Penerapan RAD Pembangunan dalam waktu singkat yang dicapai dengan menerapkan : Component based construction pemrograman berbasis komponen bukan prosedural Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada. Pembangkitan kode program otomatis/semi otomatis Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tetapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun. Catatan : Jika pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

26 Kelemahan & Kelebihan RAD
Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar. Model ini cocok untuk proyek dengan skala besar. Model RAD memerlukan komitmen yang kuat antara pengembang dan user, bahkan keduanya bisa tergabung dalam 1 tim kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus. sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini. penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras. proyek bisa gagal karena waktu yang disepakati tidak dipenuhi risiko teknis yang tinggi juga kurang cocok untuk model ini.

27 8. XP (Etreme Programming)
Extreme Programming (XP) adalah metode pengembangan software yang cepat, efisien, beresiko rendah, fleksibel, terprediksi, scientific, dan menyenangkan.. Kenapa Extreme Programming ? karena Extreme Programming cukup banyak digunakan, terutama untuk pengembangan mobile apps dan mobile games dengan jumlah programmer sedikit, dan menuntut banyak perubahan dalam pengembangannya. Model ini menggunakan pendekatan Object-Oriented. Tahapan-tahapan yang harus dilalui antara lain: Planning, Design, Coding, dan Testing.  Sasaran Extreme Programming adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat. Extreme Programming merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal.

28 Core Value XP

29 Core Value XP Communication Simplicity
Memfokuskan diri pada hubungan komunikasi yang baik antar tim- klien, anggota tim, dan manajer proyek. Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Klien harus dilibatkan dalam proses pengembangan perangkat lunaknya dengan tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem yang dibangun. Simplicity Melakukan semua pekerjaan dengan sederhana dan praktis tanpa mengurangi fungsi utamanya. Dalam pengerjaan, metode yang dipilih adalah metode yang pendek dan simpel. Jangan terlalu rumit dalam membuat desain, hilangkan fitur yang tidak ada gunanya atau hapus fungsi yang tidak terpakai. Dengan kata lain lebih baik melakukan hal yang sederhana saat sekarang (sesuai kebutuhan) dan mengembangkannya nanti jika diperlukan

30 Core Value XP - lanjutan
Feedback Selalu evaluasi perkembangan perangkat lunak yang sedang dikerjakan. Segala informasi harus dikumpulkan setiap interval waktu yang konsisten dan kesalahan-kesalahan yang muncul selama proses pengembangan harus dibahas dan dicari solusinya. Umpan balik berfungsi sebagai indikator kemajuan proyek dan menginformasikan pemimpin proyek apabila perubahan perlu dibuat. Courage Programmer Extreme Programming (XP) didorong untuk berani bereksperimen dan menulis ulang kode jika mereka tidak puas dengan kode atau desain yang sudah ada.

31 Extreme Programming tepat untuk dipergunakan untuk pembuatan program yang:
Membutuhkan perubahan yang cepat (misalnya: Game Mobile) Proyek beresiko tinggi dengan tantangan yang berat Tim programmer sedikit, yaitu sekitar 2–10 orang Adanya permintaan dari pelanggan secara langsung

32 Kelebihan Extreme Programming
Meningkatkan kepuasan kepada klien Pembangunan system dibuat lebih cepat Menjalin komunikasi yang baik dengan client. Meningkatkan komunikasi dan sifat saling menghargai antar developer.

33 Kelemahan Extreme Programming
Cerita-cerita yang menunjukkan requirements dari pelanggan kemungkinan besar tidak lengkap sehingga Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga). XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

34 Ketika Mengembangkan Perangkat Lunak, perlu diingat !!!

35 Ujian (take home) Buat masing-masing membuat artikel tentang : Perancangan perangkat lunak : (Pilih salah satu….) Perbankan Kepegawaian Kependudukan  Akademis Dan lain - lain Pengembangan strategi yang digunakan dapat berupa DFD maupun metode- metode pengembangan yang lain. Sertakan pustaka yang dijadikan rujukan Dicetak dan Dikumpulkan pada pertemuan terakhir (25 Mei 2018) Tiga Langkah Pembahasan : I.  Pendefinisian masalah. II.  Pengembangan strategi solusi. III. Rencana proses pengembangan.