Tugas Analisis Masalah
Wednesday, September 9, 2020
Edit
Analisis Masalah
Tahap analisis duduk kasus menyediakan kepada analis perihal pemahaman masalah, peluang, ataupun perintah yang memicu terlaksanya proyek pengembangan sistem.. Tujuan dari analisis duduk kasus yaitu untuk mempelajari dan memahami domain duduk kasus dan untuk menganalisis masalah, peluang dan batasan masalah
Tahapan analisis duduk kasus terdiri dari 6 tugas:
Tugas 2.1 Memahami domain masalahTugas 2.1 Memahami domain masalah
Setiap stakeholder yang terlibat dalam tahap analisis duduk kasus 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 kasus dan istilah bisnis.Untuk memahami domain duduk kasus 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 kasus dan peluang
Analisis alasannya yaitu dan akibat: teknik yang mempelajari duduk kasus dengan menetapkan 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 kasus Analisis alasannya yaitu dan akhir sanggup dilakukan dengan sumbangan 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 menilik 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 menetapkan 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 jadwal Pembatalan proyek yang disebabkan: Kurangnya sumber daya dalam pengembangan sistem.Realisasi dari duduk kasus dan peluang dalam penyelesaian duduk kasus 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 analisiTugas 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 kejadian bisnis dimana sistem harus menyediakan jawaban 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 penggalan 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 diubahsuaikan 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, anutan data, dan antarmuka pengguna (menggunakan model objek).Tahapan analisis duduk kasus 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 jadwal 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 rencana 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: usulan 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 menunjukkan 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 Menganalisis 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 jadwal – 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 jadwal 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, jadwal 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 tamat 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 pembiasaan 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 usulan sistem yang direkomendasikan (system proposal)