Analisis Sistem Pada Sitem Imformasi
Tuesday, September 8, 2020
Edit
Analisis Sistem
Menjelaskan sejumlah pendekatan analisis sistem untuk menuntaskan duduk masalah sistem bisnis.
Menjelaskan definisi lingkup, analisis masalah, analisis persyaratan, perancangan logis, dan analisis keputusan. Menjelaskan maksud, partisipan, input, output, teknik, dan langkah-langkah dari definisi lingkup, analisis masalah, analisis persyaratan, perancangan logis, dan analisis keputusan.
1. Analisis sistem Teknik penyelesaian duduk masalah yang memecah sistem menjadi komponen-komponennya dengan maksud mempelajari bagaimana semua komponen ini bekerja dan berinteraksi untuk mencapai tujuan
2. Perancangan sistem
- Teknik penyelesaian duduk masalah yang saling melengkapi (dengan analisis sistem) yang merakit kembali komponen-komponen sistem ke sistem utuh – yang diharapkan sebagai sistem yang lebih baik
- Dalam hal ini, sanggup terjadi penambahan, pengurangan, dan perubahan komponen
3. Analisis sistem informasi
Fase dalam proyek pengembangan sistem informasi yang berfokus kepada duduk masalah dan persyaratan bisnis, bebas dari teknologi yang sanggup atau akan dipakai untuk menerapkan solusi permasalahan
4. Repository
- Merupakan daerah (rangkaian tempat) dimana analis sitem, perancang sistem, dan pembangun sistem menyimpan seluruh dokumentasi yang terkait dengan sistem yang dibangun
- Dapat dipakai untuk menyimpan dokumen dalam satu proyek tunggal atau lebih dari satu proyek
- Repository biasanya merupakan implementasi dari beberapa kombinasi, antara lain:
- Direktori jaringan (network directory) dari word processing, spreadsheet dan file komputer lainnya yang memuat data
- Dokumentasi tercetak (hardcopy) ayng disimpan dalam binder
- Website intranet
Pendekatan Analisis Sistem
- Motode Analisis Model-Driven (Model-Driven Analysis Approach)
- Analisis Sistem Terakselerasi (Accelerated System Analysis Approach)
- Model Penemuan Persyaratan (Requirement Discovery Methods)
Metode Analisis Model-Driven
1. Model
Ialah: representasi dari dunia kasatmata Karena “gambar lebih berarti daripada ribuan kata”, kebanyakan model memanfaatkan gambar.
2. Analisis model-driven Pendekatan penyelesaian duduk masalah yang menekankan penggambaran model sistem untuk mendokumentasikan dan memvalidasi sistem berjalan dan usulan
Pada akhirnya, model sistem menjadi blueprint untuk merancang dan mengkonstruksi sistem yang lebih baik
3. Analisis terstruktur (SA) Menggunakan teknik model-driven yang berpusat ke proses untuk menganalisis sistem berjalan dan memutuskan persyaratan bisnis untuk sistem baru
Model mengandung gambar yang mengilustrasikan potongan-potongan komponen sistem: proses dan input, output, dan file yang terkait dengannya.
4. Rekayasa informasi (IE) Menggunakan teknik model-driven yang berpusat pada data namun peka terhadap proses, untuk perencanaan, analisis, dan perancangan sistem
Model-model IE yaitu gambar-gambar yang mengilustrasikan dan menyinkronkan data dan proses sistem.
5. Analisis berorientasi objek (OOA) Menggunakan teknik model-driven yang menyatukan data dan proses sebagai objek Model-model OOA yaitu gambar-gambar yang menyajikan objek-objek sistem dari aneka macam sudut pandang, seperti: struktur, kelakuan, dan interaksi antarobjek.
6. Objek Pembungkusan data (properti) yang memperlihatkan orang, benda, tempat, kejadian, atau sesuatu, dengan semua proses (metode) yang diperbolehkan untuk memakai atau mengubah data
Jalan satu-satunya untuk mengakses atau mengubah data objek yaitu memakai proses objek yang telah ditetapkan
Analisis Sistem Terakselerasi
- Analisis sistem terakselerasi Pendekatan yang menekankan konstruksi prototipe untuk mengidentifikasikan persyaratan bisnis dan pemakai untuk sistem gres dengan lebih cepat
- Prototipe – potongan berskala kecil, tidak lengkap, namun fungsional dari sistem yang diinginkan
Model Penemuan Persyaratan
Penemuan persyaratan Proses yang dipakai analis sistem untuk mengidentifikasi dan mendapat duduk masalah sistem dan persyaratan solusi dari komunitas pemakai
Terdiri dari: Penemuan fakta – proses mengumpulkan informasi mengenai duduk masalah sistem, peluang, persyaratan solusi, dan prioritas Joint Requirements Planning (JRP) – pemanfaatan lokakarya yang difasilitasi untuk mengumpulkan pemilik, pemakai, dan tim pengembang sistem untuk gotong royong melaksanakan analisis sistem JRP secara umum dianggap sebagai kepingan dari metode Joint Application Development (JAD)
Metodologi FAST
Disebut juga sebagai preliminary investigation phase, initial study phase, survey phase, atau planning phase .Tahapan definisi lingkup terdiri dari 5 acara / tugas:
- Tugas 1.1 Mengidentifikasi duduk masalah awal dan peluang
- Tugas 1.2 Mendiskusikan lingkup dasar
- Tugas 1.3 Menilai kelayakan awal proyek
- Tugas 1.4 Mengembangkan agenda dan anggaran awal
- Tugas 1.5 Menyampaikan planning proyek
Tugas 1.1 Mengidentifikasi Masalah Awal Dan Peluang
Stakeholder yang terlibat adalah: Senior analis sistem (memimpin tim) Pemilik Sistem (sponsor, manager executive).Manager masing – masing divisi Pemicu dari kiprah 1.1 yaitu Project Request or Assignment Merupakan pernyataan tertulis dari tim atau divisi yang mengajukan pengembangan sistem.
Hasil dari kiprah 1.1 yaitu Preliminary Problem Statement Berisi masalah, peluang, dan petunjuk terjadinya masalah
- Urgency, dalam jangka waktu berapa usang masalah, peluang dan petunjuk sanggup direalisasikan
- Visibillity, dalam tingkat apakah solusi atau sistem usulan terrealisasi kepada pelanggan atau administrasi eksekutif
- Benefit, kira – kira berapa banyak sistem usulan sanggup meningkatkan pendapatan atau pengurangan biaya
- Priority, menurut komponen diatas, tentukan peringkat untuk setiap masalah, peluang atau petunjuk
- Possible Solution, solusi yang sanggup diberikan terhadap duduk masalah yang ditemukan, antara lain sanggup berupa: Rancang sistem baru,Merancang ulang sistem berjalan.
Tugas 1.2 Mendiskusikan Lingkup Dasar
Ruang lingkup sanggup berubah sewaktu – waktu
Berdasarkan Preliminary Problem Statement sanggup dilanjutakan dengan menentukan ruang lingkup pembahasan
Dokumen yang dihasilkan dari kiprah 1.2 yaitu Preliminary Problem Statement with scope
Cara yang sanggup dilakukan yaitu dengan memakai metode inovasi fakta (fact finding) dan rapat dengan anggota tim proyek.
Tugas 1.3 Menilai Kelayakan Awal Proyek
Menentukan apakah proyek layak untuk dikerjakan menurut hasil dari kiprah 1.2 sebelumnya.Hasil dari kiprah 1.3 ini yaitu keputusan apakah proyek tetap dilanjutkan atau berhenti dan juga sanggup saj terjadi perubahan terhadap runag lingkup yang dibahas.Hasil dari kiprah 1.3 tidak ada dalam bentuk dokumen fisiknya.
Tugas 1.4 Mengembangkan Jadwal Dan Anggaran Awal
Tahap selanjutnya yaitu merencanakan pelaksanaan proyek, terdiri dari: Preliminary Master Plan, meliputi agenda dan sumber daya yang ditugaskan ke dalam proyek tersebut (disebut juga baseline plan) Detailed plan and schedule
- Proyek manajer yang bertanggung jawab untuk menyelesaikannya
- Hasil dari kiprah 1.4 yaitu Baseline Project Plan dan Schedule
- Dapat memakai pemberian dari project management software,seperti Microsoft Projec
Tugas 1.5 Menyampaikan Rencana Proyek
Pada tahap ini projek akan di presentasikan kepada steering body untuk disetujui Steering body komite eksekutif dan manajer yang mempelajari anjuran proyek untuk menentukan proyek mana yang akan memperlihatkan manfaat terbesar bagi organisasi dan disetujui untuk kelanjutan pengembangan sistem Setelah proyek diterima, maka proyek perlu dikomunikasikan ke business comunity dengan menyelenggarakan project kickoff meeting Meliputi: ruang lingkup proyek, tujuan dan jadwal
Business comunity meliputi: unit bisnis dan tim proyek yaitu pemilik, user, sistem analis dan programmer Hasil dari tahapan ini yaitu Project Charter Project Charter memutuskan lingkup, rencana, metodologi, standar proyek, dan lain-lain Rencana induk awal meliputi agenda dan penetapan sumber daya pendahuluan (juga disebut baseline plan). Rencana dan agenda detil untuk menuntaskan fase selanjutnya.
Analisis Masalah
Tahap analisis duduk masalah menyediakan kepada analis perihal pemahaman masalah, peluang, ataupun perintah yang memicu terlaksanya proyek pengembangan sistem
Tujuan dari analisis duduk masalah yaitu untuk mempelajari dan memahami domain duduk masalah dan untuk menganalisis masalah, peluang dan batasan masalah
Tahapan analisis duduk masalah terdiri dari 6 tugas:
Tugas 2.1 Memahami domain masalah
Setiap stakeholder yang terlibat dalam tahap analisis duduk masalah mempunyai pandangan yang berbeda – beda terhadap detail masalah, penggunaan istilah, persepsi dan pendapat.Garis putus – putus melambangkan pemicu (trigger).Hasil dari tahapan ini yaitu memahami domain duduk masalah dan istilah bisnis.Untuk memahami domain duduk masalah sanggup dengan menggambarkan: Model sistem Building block Knowledge, sanggup dijelaskan melalui model data.Process, sanggup dijelaskan melalui persyaratan fungsional atau dengan DFD Communication, sanggup dijelaskan melalui Use Case Diagram atau Diagram Kontek.
Tugas 2.2 Menganalisis duduk masalah dan peluang
Analisis alasannya yaitu dan akibat: teknik yang mempelajari duduk masalah dengan memutuskan alasannya yaitu dan akibatnya.Analis sistem akan memfasilitasi kiprah ini, sedangkan pemilik dan pemakai sistem harus aktif berpartisipasi lantaran mereka yaitu yang paling memahami domain duduk masalah Analisis alasannya yaitu dan jawaban sanggup dilakukan dengan pemberian Diagram Ishikawa(Fishbone)
Tugas 2.3 Menganalisis proses bisnis
Kegiatan yang dilaksanakan yaitu Business Process Redesign (BPR) terhadap pengembangan sistem yang dilakukan atau dibutuhkan merancang ulang proses bisnis yang diperlukan.Tim pengembangan sistem mengusut proses bisnis organisasi secara rinci untuk menentukan adanya proses yang bernilai tambah (value added) atau adanya proses yang dikurangi.Analis sistem yang memfasilitasi acara ini,Peserta lainnya yang terlibat dalam acara ini yaitu pemilik dan user dalam organisasi,Umumnya pemilik sistem sanggup lebih mempunyai sifat untuk mempertahankan proses bisnis sistem berjalan (existing system),Masukan acara ini yaitu domain masalah.
Hasil dari kiprah 2.3 adalah: Model proses sistem berjalan (as is system) – DFD Aliran data dalam proses Waktu respon dari setiap proses Penundaan dan bottleneck yang terjadi di sistem Analisis proses sistem berjalan (as is system) – menyediakan informasi tambahan seperti: Biaya yang terjadi dari setiap proses Nilai tambah dari setiap proses Konsekuensi terhadap proses yang tereliminasi.Berdasarkan model “as is system” maka dikembangkan “to be system” untuk merancang ulang proses bisnis dengan mengeliminasi redundansi dan birokrasi untuk meningkatkan efisiensi dan servis
Tugas 2.4 Menentukan target peningkatan sistem
Sasaran – ukuran keberhasilan Sesuatu yang diharapkan untuk dicapai sistem baru, menurut sumber daya yang memadai Mengurangi persentase piutang yang tidak tertagih menjadi 30% tahun depan Meningkatkan jumlah permohonan pinjaman yang sanggup diproses sebanyak 25% dalam delapan jam,Buatlah laporan tunggakan piutang (Kurang tepat! Mengapa?)
Batasan – sesuatu yang akan membatasi keluwesan dalam memutuskan solusi terhadap target Contoh: deadline, anggaran dan teknologi yang digunakan
Biasanya, batasan sulit diubah Sistem gres harus dioperasikan pada tanggal 15 April Sistem gres dihentikan berbiaya lebih dari 350 juta Sistem gres harus mendukung web dan memakai MS SQLServer 2000.Sistem gres memakai metode average untuk evaluasi persediaan
Peserta yang terlibat: Analisis sistem sebagai fasilitator : Pemilik,user
Tugas 2.5 Memperbarui Project Plan
Pada acara ini yang dilakukan yaitu memperbarui project plan Karena sepanajang acara analisis dilakukan, maka tidak menutup kemungkinan ruang lingkup akan berubah (bertambah atau berkuruang) sesuai kebutuhan Peserta yang terlibat: Manajer Proyek sebagai fasilitator : Sistem analis, Pemilik sistem
Tugas 2.6 Mengkomunikasikan rekomendasi dan temuan
Pada acara ini tim pengembangan sistem mengkomunikasikan temuan yang dikumpulkan dan rekomendasi dari tim kepada business community.Peserta yang terlibat: Manajer proyek dan sponsor sebagai fasiliator: Pemilik sistem,User, Analis sistem, Programmer.
Hasil dari tahap ini akan dipresentasikan kepada auditor atau peer group (disebut walkthrough)
Kesimpulan dari tahap analisis yaitu salah satu keputusan ini akan diambil yaitu: Persetujuan mengenai proyek: diterima atau tidak menurut tahap analisis persyaratan
Penyesuaian ruang lingkup, biaya atau agenda Pembatalan proyek yang disebabkan: Kurangnya sumber daya dalam pengembangan sistem.Realisasi dari duduk masalah dan peluang dalam penyelesaian duduk masalah tidak sesuai.Realisasi dari manfaat sistem gres melebihi biaya yang dianggarkan.Persetujuan dari pemilik sistem apakah pengembangan sistem sanggup dilanjutkan atau tidak
Analisis Persyaratan
Persyaratan merupakan hal yang sangat kritis untuk sistem informasi yang diusulkan
Tahap analisis persyaratan (requirement): Persyaratan bisnis untuk sistem usulan / sistem gres Tahapan analisis duduk masalah terdiri dari 4 tugas:
Tugas 3.1 Mengidentifikasi Persyaratan Sistem
Persyaratan sistem terbagi menjadi 2 jenis: Persyaratan Fungsional: Deskripsi acara dan layanan yang harus dilakukan sistem.Meliputi: input, output, proses dan data yang tersimpan
Tools yang sanggup digunakan: Use Case Diagram
Persyaratan Non Fungsional: Deskripsi fitur, karakteristik, dan batasan lain yang juga menentukan kepuasan akan sistem.Meliputi: kinerja, kemudahan pakai, anggaran, jatuh tempo, dokumentasi, keamanan, kontrol audit internal.Tools yang sanggup digunakan: Kerangka PIECES .Mengkonsepkan persyaratan fungsional Daftar target peningkatan sistem beserta seluruh input, proses, output, data tersimpan yang terkait dengan target tersebut.Pemodelan Use Case Mengkonsepkan persyaratan nonfungsional Daftar persyaratan dengan pengelompokan PIECES
Use case: Skenario atau tragedi bisnis dimana sistem harus menyediakan tanggapan yang ditentukan.Teknik ini berasal dari analisis berorientasi objek; namun sanggup dipakai dalam aneka macam metodologi pengembangan sistem
Tugas 3.2 Memprioritaskan Persyaratan Sistem
Membuat prioritas persyaratan sanggup dibantu dengan timeboxing.Timeboxing – teknik yang menyajikan fungsionalitas dan persyaratan sistem melalui versioning. Tim pengembang menentukan kepingan terkecil dari sistem, yang jika diimplementasikan maka akan menghasilkan manfaat sesegera mungkin untuk pemilik dan pemakai sistem.Bagian tersebut dikembangkan, idealnya dalam jangka waktu 9 bulan atau kurang Kemudian, versi tambahan dari sistem dikembangkan dalam jangka waktu yang hampir sama Prioritas sanggup dikelompokkan menurut kepentingan: Persyaratan utama harus dipenuhi pada sistem awal, versi 1.0 Persyaratan tambahan tidak begitu penting pada versi awal namun sanggup menjadi penting untuk versi mendatang
Tugas 3.3 Memperbarui Project Plan
Menyesuaikan kembali anatar ruang lingkup pembahasan dengan isi pada project plan Yang perlu diadaptasi antara lain: Jadwal,Anggaran,Ruang lingkup
Pada tahap ini, ruang lingkup proyek harus dipastikan sehingga sanggup dilanjutkan ke tahap berikutnya Yang menjadi pemicu kiprah 3.3 ini yaitu hasil dari kiprah 2.2 yaitu completed requirement and priorities
Tugas 3.4 Mengkomunikasikan Pernyataan Persyaratan
Pada tahap ini acara yang dilakukan yaitu memberikan dan mendiskusikan persyaratan dan prioritas kepada business community.Yang menjadi fasilitator dalam tahapan ini yaitu project manager dan sponsor
Disain Logis
Hasil dari persyaratan yang telah dikumpulan ditahap sebelumnya akan diwujudkan kedalam disain logis.Dalam disain logis, untuk mendokumentasikan persyaratan bisnis memakai model sistem yang menggambarkan struktur data, proses bisnis, pemikiran data, dan antarmuka pengguna (menggunakan model objek).Tahapan analisis duduk masalah terdiri :
Tugas 4.1a Menyusun Persyaratan Fungsional
Menyusun persyaratan fungsional dengan cara menggambar atau memperbarui model sistem untuk mengilustrasikan persyaratan fungsional.Terdiri dari: kombinasi data, proses, dan model objek yang menggambarkan bisnis dan persyaratan pengguna (non teknis)
Peserta yang terlibat: Analis sistem sebagai fasilitator,Pengguna sistem.Hasil dari kiprah ini adalah: Model sistem (system models),Spesifikasi rinci (detailed specifications)
Prototyping merupakan sebuah alternatif (kadang disebut prasyarat) untuk model sistem Salah satu pendekatan alternatif atau suplemen untuk model sistem yaitu dengan membangun prototype Membangun pola input dan output yang sanggup dipakai untuk membantu membangun database dan agenda untuk data masukan dan informasi keluaran dari database.Hasil: prototipe fungsional (functional prototype)
Tugas 4.2 Mengesahkan Persyaratan Fungsional
Model sistem dan prototipe mewakili persyaratan pengguna:Prototipe yang telah dibentuk di kiprah sebelunya perlu disahkan / divalidasi.Analis sistem menjadi fasilitator untuk memastikan masukan pemakai untuk mengidentifikasikan terdapat ketidaksesuaian pada prototipe yang dibentuk atau mengklarifikasi prototi.
Tugas 4.3 Menentukan Acceptance Test
Menentukan planning pengujian sistem yang diusulkan.Peserta yang terlibat adalah: Analis Sistem,Programmer
Analisis Keputusan
Tujuan pada tahapan ini yaitu untuk mengidentifikasi: solusi alternatif menganalisis alternatif kandidat solusi merekomendasikan kandidat solusi yang terpilih memulai acara konstruksi sistem kemudian di implementasi sistem tersebut.Hasil dari tahapan ini adalah: anjuran sistem (system proposal)
Tugas 5.1 Mengidentifikasi Solusi Kandidat
Beberapa kandidat solusi akan disampaikan: Dalam bentuk ilham dan pendapat dari pemilik dan pengguna sistem Sumber lainnya, misal: analis sistem, konsultan TI dan profesional SI lainnya .Beberapa pilihan teknis sanggup dibatasi oleh arsitektur yang telah ditentukan atau arsitektur yang telah disetujui .Peserta dari tahapan ini adalah: Analis sistem sebagai fasilitator : Pemilik sistem, Pengguna sistem.Sumber ilham sanggup berasal dari: database administrator, network administrator, technology architect dan programmer
Pemicu dari kiprah 5.1 adalah: Persetujuan untuk kelanjutan acara pengembangan sistem darianalisis persyaratan. Ide dan pendapat sanggup berasal dari sumber internal maupun eksternal.Banyaknya informasi memperlihatkan karakteristik banyaknya kandidat Tool yang sanggup dipakai yaitu untuk meng-capture, mengelola, dan membandingkan karakteristik perbedaan masing – masing kandidat yaitu Candidate Matrix.Teknik inovasi fakta sanggup dipakai dalam acara ini
Tugas 5.2 Menganaisis Solusi Kandidat
Setiap kandidat solusi perlu dianalisis.Analisis kelayakan sanggup dipakai untuk menganalisis setiap kandidat.Analisis kelayakan terdiri dari: Kelayakan teknis – Apakah solusi sanggup diwujudkan secara teknis? Apakah staf mempunyai keahlian teknis untuk merancang dan membangun solusi ini? Kelayakan operasional – Akankah solusi memenuhi persyaratan pemakai? Seberapa jauh? Bagaimana solusi akan mengubah lingkungan kerja pemakai? Bagaimana perasaan pemakai akan solusi tersebut? Kelayakan ekonomi – Apakah solusi bersifat cost-effective? Kelayakan agenda – Dapatkah solusi dirancang dan diterapkan dalam waktu yang sanggup diterima? Kelayakan risiko – Berapa peluang keberhasilan implementasi solusi tersebut? Peserta dari tahapan ini adalah: Analis sistem sebagai fasilitator Pemilik dan pengguna sistem, biasanya melaksanakan analisis kelayakan operasional, ekonomi, dan agenda Programmer dan perancang sistem, biasanya berkontribusi dalam analisis kelayakan teknis Hasil analisis kelayakan akan disimpan pada repository untuk kemudian sanggup dilanjutkan ke acara perbandingan kandidat Teknik inovasi fakta sanggup dipakai dalam acara ini
Tugas 5.3 Membandingkan Solusi Kandidat
Berdasarkan hasil analisis kelayakan terhadap masing – masing kandidat, maka sanggup dilanjutkan dengan perbandingan kandidat dan menentukan satu atau beberapa solusi yang akan direkomendasaikan kepada pemilik dan pengguna sistem : Kandidat yang tidak layak akan tereliminasi,Perbandingan dilakukan menurut kombinasi dari kelayakan teknis, oeprasional, ekonomi, agenda dan resiko,Peserta dari tahapan ini adalah: Analis sistem sebagai fasilitator,Programmer dan perancang sistem, sanggup berkontribusi terhadap perbandingan kelayakan teknis .Pemilik dan pengguna sistem, sanggup diberdayakan mendorong analisis final dan rekomendasi.
Hasil perbandingan sanggup disajikan dalam Matrik analisis kelayakan (Feasibility Analysis matrix) Hasil dari kiprah 5.3 adalah: rekomendasi solusi (Solutions to be recommended), harus ditentukan prioritas diantara lebih dari satu solusi yang ditawarkan
Tugas 5.4 Memperbarui Project Plan
Project plan akan diperbarui terhadap penyesuaian ruang lingkup.Mempertimbangkan jika terdapat lebih dari satu solusi yang direkomendasikan.Peserta yang terlibat: Yang menjadi fasilitator yaitu manajer proyek, didukung oleh pemilik dan tim pengembangan sistem Analis sistem dan pemilik yaitu orang kunci dalam acara ini Programmer dan perancang sistem.Hasil dari tahapan ini adalah: Project Plan yang telah diperbarui
Tugas 5.5 Merekomendasikan Solusi Yang Terpilih
Merekomendasikan sistem usulan.Peserta yang terlibat: Manajer proyek dan sponsor menjadi fasilitator.Perlu dibentuk rapat yang terlibat didalamnya yaitu seluruh tim proyek, meliputi: pemilik, pengguna sistem, analis sistem, programmer dan perancang sistem Analis sistem menciptakan anjuran sistem yang direkomendasikan (system proposal)