FASE PENGEMBANGAN - 1

1. FASE PENGEMBANGAN - 1 Pertemuan 8 Proyek Sistem Informasi Viska Armalina, ST., M.Eng

2. Pendahuluan Inti dari fase pengembangan : Metode untuk pelaksanaan proyek sistem informasi yang sering digunakan adalah metode SDLC (Software Development Life Cycle) dengan model pengembangan “The Waterfall Model”. “membuat produk yang bisa memenuhi apa yang dikehendaki klien, yang telah disusun dan diorganisir pada fase sebelumnya.”

3. Tahapan The Waterfall Model Requirements Desain Sistem dan Software Pembangunan Software Quality Assurance (QA) Dokumentasi

4. 1. Requirements Yang sudah harus ada dalam tahap requirements ini adalah: - System Requirements Spesification (dokumen SRS) - Project Scope Document (PSD) Pada fase pengembangan, requirements sudah tidak ada perubahan yang signifikan (perubahan kecil masih dapat diterima).

5. 2. Desain Sistem dan Software Konsepnya : Menyusun deskripsi struktur komponen software yang akan digunakan dalam pengembangan software tersebut. Pada fase pengembangan, sistem dan software berkaitan erat karena software menjadi bagian utama dari suatu sistem informasi.

6. Tahapan Pada Proses Desain Sistem dan Software Spesifikasi Fungsional dan Teknis Resiko dan Mitigasi Desain Sistem Pemodelan (Modelling) Desain Software Desain Antarmuka Pengguna Desain Database

7. a. Spesifikasi Fungsional dan Teknis (1) Spesifikasi fungsional dapat dideskripsikan melalui Functional Spesification Document (FSD) : - menggambarkan bagaimana nantinya software akan berfungsi. - fungsi-fungsi apa yang harus dimiliki oleh software tersebut agar dapat memenuhi requirements  cara kerja/interaksi software dengan pengguna. FSD harus jelas dan akurat dalam menggambarkan hal-hal teknis yang diperlukan oleh sistem dan software yang akan dibangun.

8. a. Spesifikasi Fungsional dan Teknis (2) Contoh deskripsi dalam FSD tentang pengisian faktur penjualan : “Isi data pelanggan dengan memilih dari daftar Master Pelanggan, setelah itu isi data barang dengan memilih dari daftar Master Barang. Setelah selesai pengisian, klik tombol Simpan untuk menyimpan data yang telah diisi.”

9. a. Spesifikasi Fungsional dan Teknis (3) Spesifikasi teknis dituangkan dalam Software Technical Spesification (STS). STS dapat dilengkapi dengan skema dan diagram agar lebih memperjelas deksripsi yang diberikan. FSD dan STS ditujukan untuk penggunaan internal tim pengembang software, sehingga format penyusunannya tidak terlalu formal, yang penting jelas dalam mendeksripsikan kebutuhan pelaksanaan proyek dan sebagai dokumentasi.

10. Perbedaan FSD dengan STS 1. STS lebih mendeskripsikan aspek teknis dari software yang akan didesain, seperti : - platform yang digunakan - bahasa pemrograman - database - struktur data - koneksi software dengan database, dsb. 2. FSD ditujukan untuk desainer sofware, sedangkan STS ditujukan untuk desainer sistem dan pemrogram.

11. b. Resiko dan Mitigasi (1) Potensi resiko ada di setiap fase  perlu identifikasi resiko. - misalnya: Sama halnya dengan requirements analysis, pada proses desain sistem dan software, jika tidak dilakukan dengan tepat memungkinkan kegagalan proyek semakin tinggi  kegagalan deliverables. Rencana Mitigasi harus dipersiapkan dari awal agar jika terjadi masalah saat proses desain telah diselesaikan dan siap ke tahap pengembangan, kegagalan deliverables bisa dicegah, sehingga menghindari kegagalan proyek (tertunda).

12. b. Resiko dan Mitigasi (2) Rencana Mitigasi lebih praktis jika dimasukkan ke fase pengembangan dan menjadi bagian dari tahap desain, dengan tujuan agar jika pada fase ini terjadi masalah, mitigasi yang sejalan dengan desain dapat memperkecil kemungkinan penundaan proyek. Mitigasi dalam desain ditujukan untuk mempersiapkan solusi dan alterbatif agar kendala-kendala dalam tahap pengembangan dapat dihindari.

13. Penyebab Terjadinya Kendala/Masalah dalam Proses Desain Desain terlalu kompleks Membutuhkan teknologi yang sulit diperoleh/diluar anggaran Fungsi yang dibutuhkan tidak didukung oleh bahasa pemrograman yang digunakan Pertentangan antara satu fungsi dengan fungsi lain sehingga menyebabkan konflik sistem Desainnya ambigu sehingga sistem tidak stabil Desain tampilan tidak ergonomis/user friendly sehingga menyulitkan pengguna.

14. c. Desain Sistem (1) Desain sistem adalah proses mendefinisikan arsitektur, komponen, modul, antarmuka, dan data untuk memenuhi requirements. Desain sistem dalam manajemen proyek  dasar bagi konstruksi sistem yang akan dibangun. System Flow : aliran informasi dari awal hingga akhir yang merepresentasikan requirements.

15. c. Desain Sistem (2) Ada 2 jenis desain sistem : - Desain Logikal - Desain Fisikal

16. Desain Logikal Desain secara logikal : melakukan representasi abstrak sistem dengan diagram, gambar, dan bagan, sehingga aliran data, input dan output sistem dapat dipahami oleh pemrogram. Representasi sistem harus memenuhi 3 pertimbangan: - Fungsi : apa yg dilakukan oleh sistem - Waktu : apa yg terjadi dan kapan - Informasi : informasi apa yang digunakan sistem

17. Desain Fisikal Desain fisikal : desain yang berkaitan dengan bagaimana proses input dan output sebenarnya dalam sistem. Pertimbangan dalam desain fisikal : - bagaimana data diinput dalam sistem - bagaimana melakukan verifikasi dan otentifikasi data - bagaimana data diproses - seperti apa penyajian output yg dihasilkan. Penggambaran desain fisikal : desain dasar form input, urutan verifikasi data, bagan proses, laporan hasil.

18. Metode Desain Sistem (1) Yourdon System Method (YSM) - Metode generasi ketiga - Dirintis oleh Edward Yourdon, tahun 1970 sampai 1900-an. - Menggunakan context diagram yang menggambarkan hasil analisis dalam bentuk sumber data, aliran dan batasan sistem. - Desain sistem lebih diperinci dengan teknik-teknik tradisional  ERD (Entity Relationship Diagram), normalisasi, DFD (Data Flow Diagram), dsb.

19. Metode Desain Sistem (2) b. Metode Analisis dan Desain Sistem Berorientasi Obyek (Object Oriented System Analysis and Design Method) • Alat bantu yang digunakan pada metode ini adalah Unified Modelling Language (UML).

20. d. Pemodelan (Modelling) - 1 Model  representasi abstrak dari sistem yang akan dibangun. Tidak semua sistem memerlukan pemodelan. Kriteria sistem sederhana yang tidak perlu memakai pemodelan : Lingkup sistem telah dikenal baik Sistem relatif mudah untuk dibangun Hanya sedikit/hanya 1 orang yang membangun/menggunakan sistem. Sistem hanya butuh perawatan yang minimal. Kemungkinan pengembangan sistem lebih lanjut sangat kecil.

21. d. Pemodelan (Modelling) - 2 Pemodelan diterapkan pada : - sistem yang lebih kompleks - memiliki resiko lebih besar - tidak tersedianya sistem sejenis untuk digunakan langsung secara praktis. (sistem baru/belum ada sebelumnya).

22. Alat Bantu Pemodelan Integrated Development Environment (IDE) Software pengembangan menyediakan lingkungan yang membantu pemodelan sebelum dilakukan proses pemrograman. Unified Modelling Language (UML) - standar dalam pemodelan - bahasa spesifikasi standar untuk medokumentasikan, menspesifikasikan dan membangun sistem software. - hasil pengembangan dari bahasa pemodelan berorientasi objek (Object Oriented Modelling Language).

23. Mengapa Sistem Informasi Perlu Pemodelan? (1) Awal perkembangan SI : - sederhana, sistem dibangun untuk memecahkan satu masalah saja - bentuk awal pemodelan sudah ada (sistem analis merangkap jadi desainer sistem yang membuat flowchart berupa gambaran logika sistem untuk memudahkan programmer memahami apa yang harus dibangunnya), - belum banyak alat bantu pemodelan

24. Mengapa Sistem Informasi Perlu Pemodelan? (2) Perkembangan SI selanjutnya sampai sekarang - Sistem Informasi menjadi lebih kompleks dan terintegrasi. - Interaksi dalam Sistem Informasi tidak hanya dalam satu organisasi/perusahaan, tapi juga tersebar secara geografis. - Pemodelan mutlak diperlukan untuk sistem yang semakin kompleks agar programmer lebih mudah memahami apa yang akan dibangunnya.

25. Manfaat Pemodelan bagi Programmer Dapat memahami sistem yang membutuhkan contoh perwujudannya lebih dulu yaitu dengan mendefinisikan proses-prosesnya dalam bentuk model. Memahami bagaimana suatu proses bekerja + asumsi-asumsi yang menjadi dasar proses kerja tersebut. Memudahkan dalam mendefinisikan sumber input sistem, baik dari luar maupun dari dalam sistem. Menentukan representasi dari keterhubungan antara komponen-komponen sistem  memudahkan memahami sistem secara keseluruhan. Menelusuri kembali requirements untuk memastikan sistem yang dibangun telah sesuai.

26. Faktor Penghambat dalam Membentuk Model Sistem (1) Asumsi  digunakan utk mengurangi dugaan dan berbagai kemungkinan tentang hal-hal yg belum diketahui. Simplifikasi  agar tidak terjebak ketika menyusun model yg terlalu kompleks sehingga memakan banyak waktu. Batasan  melingkupi sistem agar model menjadi terfokus dan tidak melebar.

27. Faktor Penghambat dalam Membentuk Model Sistem (2) Hambatan  membantu menentukan kebutuhan sumberdaya dan dukungan untuk mewujudkan sistem. Pilihan  menentukan arsitektur yang akan digunakan seperti data, fungsi, teknologi.

28. e. Desain Software Bentuk detail dari desain sistem  sistem yang telah dibuat modelnya kemudian diperinci dalam bentuk yang lebih mudah dipahami programmer. Aktivitas yang dilakukan adalah menyusun bentuk representasi software yg akan digunakan (arsitektural maupun desain detailnya). Biasanya digambarkan menggunakan flowchart.

29. Konsep Dasar Desain Software Abstraksi Coupling Cohesion Dekomposisi dan Modularisasi Encapsulation Pemisahan antarmuka dan implementasi

30. Abstraksi Proses atau hasil generalisasi suatu permasalahan - tujuan : agar hanya informasi yang relevan saja yang digunakan untuk menyusun solusi.

31. Coupling Tingkat relasi (ketergantungan) antara satu modul dengan modul lain, antar komponen maupun servis.

32. Cohesion Tingkat independensi (ketidak-tergantungan/kemandirian) antar modul, komponen maupun servis.

33. Dekomposisi dan Modularisasi Memecahkan entitas/satuan software besar menjadi beberapa komponen yang independen/mandiri. - tujuan : agar komponen memiliki tingkat cohesion tinggi secara fungsional.

34. Encapsulation Menutupi informasi - menutupi detail internal dari abstraksi sehingga detail tersebut tidak dapat diakses.

35. Pemisahan Antarmuka dan Implementasi Mendefinisikan komponen publik yang dapat diakses oleh pengguna dan memisahkan detail bagaimana komponennya bekerja.