Pertemuan 2 Review Analisis Sistem

Presentasi berjudul: "Pertemuan 2 Review Analisis Sistem"— Transcript presentasi:

1 Pertemuan 2 Review Analisis Sistem

2 Materi Analisis Permasalahan Analisis Kebutuhan
Definisi dan konsep analisis sistem Tujuan Analisis Sistem Hal yang perlu diprhatikan Langkah-langkah analisis sistem Tools yang digunakan Analisis Kebutuhan Apa itu kebutuhan Kebutuhan fungsional Kebutuhan non fungsional Penggunaan diagram use case dalam menganalisis kebutuhan

3 Definisi Analisis Sistem
Penguraian dari suatu Sistem Informasi yang utuh ke dalam bagian-bagian komponennya dengan maksud untuk mengidentifikasikan dan mengevaluasi permasalahan, kesempatan, hambatan yang terjadi dan kebutuhan yang diharapkan sehingga dapat diusulkan perbaikannya

4 Analisis sistem Tahap analisis merupakan tahap yang paling kritis dan sangat penting, karena kesalahan di tahapan ini akan menyebabkan kesalahan di tahap selanjutnya Hasil dari analisis sistem adalah: laporan yang dapat menggambarkan sistem yang telah dipelajari dan diketahui bentuk permasalahannya serta rancangan sistem baru yag akan dibuat atau dikembangakan.

5 Tujuan Analisis Sistem
Memberikan pelayanan kebutuhan informasi kepada fungsi manajerial di dalam pengendalian pelaksanaan kegiatan operasional perusahaan Membantu para pemngambil keputusan Mengevaluasi sistem yang telah ada Merumuskan tujuan yang ingin dicapai berupa pengolahan data maupun pembuatan laporan baru Menyusun suatu tahap rencana pengembangan sistem

6 Analisis Sistem Tugas utama dari menganalisis sistem meliputi:
Menentukan lingkup sistem Mengumpulkan fakta Menganalisis fakta Mengkomunikasikan temuan-temuan tersebut melalui laporan analisis sistem Fakta merupakan bagian dari informasi yang menunjukkan realita, situasi dan relasi yang menjamin analisis dan pemodelan.

7 Analisis Sistem Yang perlu diperhatikan dalam melakukan analisis, adalah: Mempelajari permasalahan yang ada secara terinci Menentukan pendekatan yang akan digunakan dalam memecahkan masalah Membuat suatu pertimbangan apakah perlu atau tidak menggunakan cara komputerisasi

8 Analisis Sistem Langkah-langkah dalam melakukan analisis, yaitu:
Mengidentifikasi masalah Mengidentifikasi penyebab masalah Analisis sistem Mengidentifikasi solusi dari masalah Analisis Kebutuhan Mengidentifikasi data apa dan proses apa yang dibutuhkan pada sistem baru. Menentukan kebutuhan fungsional dan non-fungsional dari sistem baru.

9 PIECES PIECES (performance, information, economics, control, efficiency) P Kebutuhan untuk mengoreksi atau memperbaiki informasi performance/performa. I Kebutuhan untuk mengoreksi atau memperbaiki informasi/ information (dan data). E Kebutuhan untuk mengoreksi atau memperbaiki economics/ekonomi, mengendalikan biaya, atau meningkatkan keuntungan. C Kebutuhan untuk mengoreksi atau memperbaiki control/control atau keamanan Kebutuhan untuk mengoreksi atau memperbaiki efficiency/efisiensi orang dan proses. S Kebutuhan untuk mengoreksi atau memperbaiki service/layanan ke pelanggan, pemasok, rekan kerja, karyawan dan lain-lain.

10 fishbone diagram Diagram tulang ikan atau fishbone diagram adalah salah satu metode / tool di dalam meningkatkan kualitas. Sering juga diagram ini disebut dengan cause effect diagram. Penemunya adalah seorang ilmuwan jepang pada tahun 60-an. bernama Dr. Kaoru Ishikawa, ilmuwan kelahiran 1915 di Tokyo Jepang yang juga alumni teknik kimia Universitas Tokyo

11 Analisis Kebutuhan Tujuan: Tantangan
Memahami sistem lama & benar-benar memahami persyaratan sistem baru mengembangkan sistem yang akan dibuat menetapkan dan menjaga kesepakatan dengan Kustomer dan stakeholder lain tentang apa yang harus dilakukan oleh Sistem memberikan pemahaman yang lebih baik kepada pengembang tentang kebutuhan sistem membuat dasar perencanaan kegiatan & biaya Bagaimana mengumpulkan & mengintegrasikan informasi yang akurat dan bermanfaat Bagaimana menemukan orang yang tepat untuk berpartisipasi Tantangan PROGRAM STUDI SISTEM INFORMASI STMIK GLOBAL INFORMATIKA MDP

12 Apa itu Kebutuhan....? Kebutuhan (requirement):
rumusan user mengenai kondisi/kemampuan yang harus dimiliki oleh suatu software aplikasi Kebutuhan software aplikasi dibedakan menjadi: kebutuhan fungsional (functional requirement) kebutuhan non-fungsional (non-functional requirement)

13 Analisis Kebutuhan

14 Analisis Kebutuhan Requirement analisis perangkat lunak adalah penting untuk keberhasilan project. Requirements pembangunan harus didokumentasikan, ditindaklanjuti, terukur, dapat diuji, dapat dilacak, terkait dengan kebutuhan bisnis diidentifikasi atau peluang, dan ditetapkan untuk tingkat detail yang cukup untuk desain sistem. Persyaratan dapat arsitektur, struktural, perilaku, fungsional, dan non-fungsional.

15 Permasalahan pada Fase Analisis Kebutuhan
Pengguna (stakeholders) tidak mengetahui apa yang mereka butuhkan Pengguna menjelaskan kebutuhan dengan cara mereka sendiri sehingga sulit untuk dipahami Pengguna yang berbeda memiliki konflik kebutuhan Faktor politik dan organisasi yang dapat mempengaruhi kebutuhan sistem Perubahan kebutuhan selama proses analisis. Perubahan proses atau lingkungan bisnis

16 Apa itu Kebutuhan....? Kebutuhan fungsional:
tindakan yang harus dapat dimainkan oleh software mencakup: fitur, kemampuan (capabilities), masukan, keluaran, faktor keamanan dimodelkan dlm bentuk use-case – use case dalam use-case model

17 Kebutuhan non-fungsional:
Apa itu Kebutuhan....? Kebutuhan non-fungsional: atribut dari software dan lingkungannya biasanya terwujud dalam properti dari use-case dibagi menjadi: Kebutuhan pemakaian (usability requirement) Kebutuhan reliabilitas (reliability requirement) Kebutuhan kinerja (performance requirement) Kebutuhan dukungan (supportability requirement)

18 Pengantar Pemodelan Use-Case
Salah satu tantangan utama dalam proses pengembangan sistem adalah memahami dengan benar kebutuhan sistem menurut sudut pandang stakeholders, kemudian menyampaikannya kembali kepada mereka agar dapat diverifikasi dan divalidasi Model data dan model proses, prototypes, spesifikasi kebutuhan pengguna Dipahami oleh desainer, tapi tidak oleh pengguna Bisa mengakibatkan kekeliruan ruang lingkup, keterlambatan jadwal, biaya membengkak Conversion Notes The material in this chapter is an expansion of material previously found in Chapter 6 and Module A. This slide explains the industry problem that this material addresses. Teaching Notes If possible, the instructor should share real-life experiences in misunderstood or mis-specified system requirements. To illustrate the inadequacy of data and process models, show the students some of the models from chapters 8 and 9. As them as novices if they can understand them. Chapter 7 - Modeling System Requirements With Use Cases

19 Pengembangan Berorientasi Pengguna dan Pemodelan UC
User-centered development (Pengembangan berorientasi pengguna) – suatu proses pengembangan sistem berdasar pada pemahaman akan kebutuhan stakeholders (pihak-pihak terkait) dan alasan mengapa sistem perlu dikembangkan Use-case modeling (pemodelan use-case) – proses pemodelan fungsi-fungsi dari suatu sistem dalam bentuk kejadian bisnis (business events), siapa yang menginisiasi kejadian tersebut, dan bagaiman sistem merespon kejadian tersebut. No additional notes Chapter 7 - Modeling System Requirements With Use Cases

20 Manfaat Pemodelan Use-Case
Alat bantu untuk memahami kebutuhan fungsional Membantu mendekomposisi sistem ke dalam lingkup yang lebih mudah dikelola Alat bantu komunikasi dengan pengguna dan stakeholder Membantu manajemen proyek, terutama dalam pengembangan yang incremental dan iteratif dsb Teaching Notes Using use-case modeling encourages user involvement. By the same token, for use cases to be successful participation by the user is imperative. Chapter 7 - Modeling System Requirements With Use Cases

21 Konsep Pemodelan Use-Case
Diagram use-case – suatu diagram yang menggambarkan interaksi antara sistem dan pengguna dan sistem lain di luar sistem tersebut. Scr grafis menggambarkan siapa pengguna sistem itu dan dgn cara bagaimana pengguna berharap berinteraksi dengan sistem Narasi use-case – deskripsi tekstual dari kejadian bisnis dan bagaimana pengguna akan berinteraksi dengan sistem untuk menyelesaikan tugas tersebut Use case – Urutan langkah-langkah perilaku (suatu skenario), baik terotomasi maupun manual, untuk menyelesaikan suatu tugas bisnis tertentu. Deskripsi fungsi-fungsi dari sistem menurut perspektif pengguna Teaching Notes use-case diagrams and use-case narratives are two views of the same sequence of steps that make up a conceptual use-case. The use-case diagram communicates at a high level the scope of the business events that make up the Use-case. The use-case narrative communicates at a more detailed level exactly how the user interacts with the system. A use-case itself is not considered a functional requirement, but the use-case’s story, or scenario, consists of one or more requirements. Chapter 7 - Modeling System Requirements With Use Cases

22 Contoh Diagram Model Use-Case

23 Contoh Diagram Model Use-Case

24 Simbol Dasar dalam Use-Case
Use case – bagian dari fungsionalitas sistem secara keseluruhan Direpresentasikan secara grafis dalam bentuk elips, dengan nama use case di atas, di dalam, atau di luar elips Aktor – sesuatu yang berinteraksi dengan sistem untuk bertukar informasi Dapat berupa orang, organisasi, sistem informasi lain, piranti eksternal, atau bahkan waktu Kejadian temporal (temporal event) – kejadian dalam sistem yang dipicu oleh waktu Aktornya adalah waktu Teaching Notes Use cases are the results of deconstructing the scope of system functionality into many smaller statements of system functionality. Use cases describe the system functions from the perspective of external users and in the manner and terminology in which they understand. An actor initiates system activity, a use case, for the purpose of completing some business task. An actor represents a role fulfilled by a user interacting with the system and is not meant to portray a single individual or job title. Have students provide examples of temporal events (nightly download, monthly billing, etc.). Chapter 7 - Modeling System Requirements With Use Cases

25 Empat Tipe Aktor Aktor bisnis primer Aktor sistem primer
Stakeholder yang mendapatkan manfaat utama dari ekseskusi suatu use case Contoh karyawan yang menerima slip pembayaran Aktor sistem primer Stakeholder yang berinteraksi secara langsung dengan sistem untuk memicu/menginisiasi kejadian atau sistem bisnis Contoh teller bank yang memasukkan data tabungan Aktor server eksternal Stakeholder yang merespon permintaan dari suatu use case Contoh biro kredit yang mengesahkan tagihan kartu kredit Aktor penerima eksternal Stakeholder yang bukan aktor primer namun menerima sesuatu yang bermanfaat dari use case Contoh gudang yang menerima slip pengepakan barang No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

26 Hubungan Asosiasi Asosiasi – suatu hubungan antara aktor dan use case di mana ada interaksi antar mereka Asosiasi dimodelkan sebagai garis lurus menghubungkan aktor dan use case Asosiasi dengan ujung panah menyentuh use case mengindikasikan bahwa use case tsb diinisiasi oleh aktor Asosiasi tanpa panah menunjukkan aktor penerima Asosiasi bisa 2 arah (bidirectional) atau searah (unidirectional) No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

27 Hubungan Extends antar Use Case
Extension use case (use case perluasan) – suatu use case yang memuat langkah-langkah yang diekstraksi dari use case yang lebih kompleks untuk menyederhanakan case aslinya dan memperluas fungsionalitasnya Hubungan antara use case perluasan (extension use case) dengan use case yang diperluas disebut hubungan extends Direpresentasikan sebagai garis berpanah mulai dari extension use case dan menunjuk ke use case yang diperluas Hubungan diberi label “<<extends>>.” No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

28 Hubungan Uses antar Use Case
Abstract use case (use case abstrak) – suatu use case yang dibuat untuk mengurangi redundansi antara dua atau lebih use case dengan menggabungkan langkah-langkah umum yang ada pada kedua use case Suatu use case abstrak dapat dipergunakan oleh use case lain yang membutuhkan fungsionalitasnya. Hubungan antara use case abstrak dengan use case yang mempergunakannuya disebut hubungan uses (atau includes). Digambarkan dengan panah mulai dari use case aslinya dan menunjuk ke use case yang digunakan Hubungan diberi label “<<uses>>.” No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

29 Hubungan Uses antar Use Case
No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

30 Hubungan Depends On Depends On – suatu hubungan use case yang menyatakan bahwa suatu use case harus dijalankan sebelum use case tersebut Membantu menentukan urutan use case mana yang perlu dibuat lebih dulu DIgambarkan dengan garis panah mulai dari satu use case dan menunjuk ke use case lain dengan mana dia tergantung Digambarkan sebagai garis panah mulai dari satu use case dan menunjuk ke use case dengan mana dia tergantung Diberi label “<<depends on>>.” No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

31 Hubungan Depends On No additional notes.
Chapter 7 - Modeling System Requirements With Use Cases

32 Proses Membangun Model Use-Case
Tujuannya adalah untuk menguraikan dan menganalisa informasi kebutuhan yang memadai untuk menyiapkan model yang dapat: mengkomunikasikan apa yang dibutuhkan pengguna dari perspektif pengguna itu sendiri tidak memuat detil spesifikasi bagaimana sistem akan dibangun atau diimplementasikan Langkah: Identifikasi aktor bisnis Identifikasi use case bisnis Buat diagram model use-case Buat narasi use-case Teaching Notes The individual steps will be discussed on the following slides. Chapter 7 - Modeling System Requirements With Use Cases

33 Langkah 1: Identifikasi Aktor Bisnis
Pertanyaan panduan untuk menentukan aktor bisnis: Siapa atau apa yang menyediakan input bagi sistem? Siapa atau apa yang menerima output dari sistem? Apakah ada hubungan dengan sistem lain? Apakah ada kejadian yang otomatis dipicu pada suatu waktu tertentu? Siapa yang akan merawat informasi dalam sistem? Teaching Notes By focusing first on actors, you concentrate on how the the system will be used instead of how it will be built. Focusing on actors helps refine and further define the scope and boundaries of the system. Also, by first identifying actors you find candidates to interview and observe so you can develop and validate the use cases. Chapter 7 - Modeling System Requirements With Use Cases

34 Contoh Daftar Aktor

35 Langkah 2: Identifikasi Use Case Bisnis
Selama fase analisis kebutuhan, identifikasi dan dokumentasikan hanya use case yang paling penting, kompleks, dan esensial Pertanyaan panduan untuk mencari use case: Apa tugas utama aktor? Informasi apa yang dibutuhkan aktor dari sistem? Informasi apa yang disediakan aktor bagi sistem? Apakah sistem perlu menginformasikan pada aktor perubahan atau kejadian yang telah terjadi? Apakah aktor perlu menginformasikan pada sistem perubahan atau kejadian yang telah terjadi? No additional notes. Chapter 7 - Modeling System Requirements With Use Cases

36 Contoh Kasus (Sistem Informasi Rawat Jalan Poliklinik ABC)
Identifikasi Masalah Permasalahan yang terjadi di Poliklinik ABC adalah sebagai berikut: Data-data yang disimpan di poliklinik masih berjalan manual, padahal Kebutuhan akan data-data pasien rawat jalan, rekam medis pasien serta dokter yang menangani tiap pasien meningkat Sistem yang dijalankan belum sepenuhnya membantu pekerjaan, karena kebutuhan akan data yang efektif dan efisien serta ada saat dibutuhkan (availability) belum bisa terpenuhi Penyediaan data yang banyak menyebabkan overload data dan informasi kurang

37 Analisis Sistem Penyimpanan data dalam bentuk kertas atau manual menimbulkan resiko yang cukup besar, seperti kebakaran, rusak atau bencana alam yang bisa mengakibatkan data-data penting itu hilang, sehingga diperlukan sistem yang bisa menyimpan data lebih aman Kebutuhan akan data yang efektif dan efisien serta ada saat dibutuhkan (availability) menjadi alasan utama untuk penyediaan informasi yang akurat

38 Data yang kurang lengkap menyebabkan informasi pelayanan kesehatan juga kurang, karena data tidak tersusun rapi dan susahnya pencarian data yang mengurangi kurangnya informasi dari data tersebut Dari berbagai alasan yang telah diungkapkan di atas, maka pengembangan Sistem Informasi Rawat Jalan Poliklinik ABC ini dibuat untuk membantu menyelesaikan permasalahan-permasalahan yang muncul.

39 Analisis Kebutuhan Data yang dibutuhkan
Data yang dibutuhkan dalam pengembangan Sistem Informasi ini adalah : Data Pasien : nama pasien, alamat, jenis kelamin, tanggal lahir, agama, golongan darah. Data Dokter : nama dokter, alamat, jenis kelamin, tanggal lahir. Data Obat : nama obat, jenis obat, aturan pakai, harga

40 Data Admin/Petugas : nama petugas, alamat, jenis kelamin, tanggal lahir.
Data Pemeriksaan : data pasien, data dokter, keluhan, diagnosa, perlakuan/pemeriksaan, data obat Data Biaya : data pasien, pemeriksaan, total harga obat *) untuk nomor_id, tidak dicantumkan disini tidak apa-apa, dicantumkan juga boleh

41 Fungsi dari sistem ini adalah :
Kebutuhan fungsional Fungsi dari sistem ini adalah : proses login untuk dokter dan petugas proses pengelolaan data pasien, meliputi input, update dan delete proses pengelolaan data dokter, meliputi input, update dan delete proses pengelolaan data petugas, meliputi input, update dan delete

42 proses pendaftaran pasien, baik daftar baru maupun pendaftaran untuk periksa dilakukan oleh user petugas proses searching/pencarian data (data pasien, data dokter, data petugas, data pemeriksaan, data obat) proses pemeriksaan, dilakukan oleh user dokter proses pemberian obat, dilakukan oleh petugas untuk diberikan kepada pasien