Analisis Sistem Informasi - 1 1 PENGANTAR AnalisIS DAN PERANCANGAN Sistem INTRODUCTION TO SYSTEM AnalysIS AND DESIGN WELLIA Shinta Sari, M.Kom AGUS Winarno, M.Kom FAJRIAN Nur Adnan, MCS TIM PENGAMPU: Analisis Sistem Informasi - 1

Bahan Ajar Content 1 Pengantar Analisis dan Perancangan Sistem Introduction to System Analysis and Design 7 Pemodelan Proses Process Modeling 2 Analis Sistem System Analyst 8 Pemodelan Data Data Modeling 3 Analisis Kemungkinan Feasibility Analysis 9 Dokumentasi Kebutuhan Requirement Documentation 4 Penentuan Kebutuhan Requirement Determination 10 Desain Interaksi Manusia-Komputer HCI Design 5 Tekhnik Pengumpulan Kebutuhan Requirement Elicitation Techniques 11 Spesifikasi Kebutuhan Perangkat Lunak Software Requirement Specification 6 Strategi Analisis Kebutuhan Requirement Analysis Strategy

Konten Materi – 1 Content - 1 Software Engineering Definition SE vs CS vs System Engineering Tanggung Jawab SE Issues of professional responsibility Myths SDLC Plan Analysis Design Implementation SD Methodologies Structured Object Oriented RAD JAD Agile Pemilihan Metodologi Pengembangan

Rekayasa Perangkat Lunak Software Engineering Software engineering adalah suatu disiplin rekayasa (rancang-bangun) yang terkait dengan semua aspek produksi perangkat lunak. Engineer perangkat lunak mengadopsi pendekatan sistematis dan terorganisir untuk pekerjaan mereka dan menggunakan teknik dan tools yang disesuaikan dengan masalah yang dihadapi untuk dipecahkan, batasan pengembangan, dan sumber daya tersedia.

Rekayasa Perangkat Lunak Software Engineering Software engineering adalah: *IEEE (Institute of Electrical and Electronic Engineers) Definition Aplikasi dari sebuah pendekatan yang bersifat kuantifiabel, disiplin, dan sistematis bagi pengembangan, operasi, dan pemeliharaan perangkat lunak. Studi tentang pendekatan-pendekatan seperti pada (1)

Rekayasa Perangkat Lunak Software Engineering SE vs CS SE Vs System Engineer Computer science mempunyai kaitan dengan theory and fundamentals; software engineering mempunyai kaitan dengan practicalities of developing and delivering useful software. Computer science sekarang ini tidak cukup lengkap untuk bertindak sebagai tiang penyokong software engineering. System engineering mempunyai kaitan dengan semua aspek pengembangan sistem berbasis-komputer yang mencakup perangkat keras, perangkat lunak ,dan yang terkait dengan proses bisnis. Software engineering berkonsentrasi pada komponen perangkat lunak sistem yang lebih besar. System engineers mencakup spesifikasi sistem, desain arsitektur, pengintegrasian, dan penyebaran.

Rekayasa Perangkat Lunak Software Engineering Tanggung Jawab Software Engineer Software engineering melibatkan tanggung-jawab lebih luas dibanding hanya aplikasi kecakapan teknis. Software engineer harus bertindak secara etis, bertanggung jawab, dan jujur jika mereka diharapkan untuk terhormat sebagai seorang profesional. Perilaku etis tidak hanya sekedar menegakkan hukum saja tetapi harus lebih dari itu (lih. hal. berikutnya).

Rekayasa Perangkat Lunak Software Engineering Issues of professional responsibility Confidentiality (Kerahasiaan) Engineer seharusnya menghormati kerahasiaan dari klien mereka tanpa tergantung dengan ya atau tidaknya suatu persetujuan kerahasiaan formal ditandatangani. Competence (Kemampuan) Engineer mestinya tidak salah menggambarkan tingkatan kemampuannya. Mereka mestinya tidak dengan sadar menerima pekerjaan yang di luar kemampuannya.

Rekayasa Perangkat Lunak Software Engineering Issues of professional responsibility Intellectual property rights (Hak milik intelektual) Engineers harus sadar akan hukum lokal yang mengatur penggunaan dari properti intelektual seperti hak paten, hak cipta, dll. Mereka harus seksama untuk memastikan bahwa intelektual properti klien harus dilindungi. Computer misuse (Penyalahgunaan Komputer) Software engineers mestinya tidak menggunakan kecakapan teknis mereka untuk menyalahgunakan komputer orang lain. Penyalahgunaan komputer dari yang relatif sepele (misal untuk bermain game) sampai yang serius (pemberian virus). ***

Rekayasa Perangkat Lunak Software Engineering Software Myths Software Miths (mitos-mitos perangkat lunak) adalah asumsi-asumsi permasalahan yang kebenarannya tidak dapat dipertanggungjawabkan berkaitan dengan pengembangan perangkat lunak Tiga kelompok yang terkait dalam pengembangan perangkat lunak Management : manajer yang bertanggungjawab terhadap pengembangan perangkat lunak Customer : pelanggan yang memesan perangkat lunak Practitioner’s : praktisi yang mengembangkan perangkat lunak

Rekayasa Perangkat Lunak Software Engineering Management Myths Dengan memiliki buku berisi standard dan prosedur yang banyak untuk pengembangan perangkat lunak, maka pekerjaan pasti lancar. Buku-buku itu memang lengkap, tapi apakah digunakan ? Apakah praktisi perangkat lunak sadar dengan keberadaannya. Apakah cocok dengan pengembangan yang modern ? Apakah benar-benar lengkap ? Untuk menghasilkan perangkat lunak yang berkualitas, maka kita perlu membeli komputer terbaru. Untuk mendapatkan perangkat lunak yang berkualitas, CASE tools lebih penting daripada perangkat keras. Bila terlambat maka tambahlah jumlah programer Penambahan programmer semakin menambah keterlambatan.

Rekayasa Perangkat Lunak Software Engineering Customer Myths Tujuan sistem secara umum cukup untuk memulai menulis program, rincian belakangan saja. Definisi awal yang buruk merupakan sebab utama gagalnya kerja perangkat lunak Rincian kebutuhan sistem sangat penting: fungsi performance antar-muka batasan rancangan kriteria validasi dll Perangkat lunak bersifat fleksibel, perubahan kebutuhan mudah diakomodasi oleh pengembang perangkat lunak Dampak perubahan sangat bergantung pada tahap mana perubahan terjadi

Rekayasa Perangkat Lunak Software Engineering Practitioner’s Myths Program selesai, pekerjaan selesai 50% - 70% usaha dihabiskan setelah program diserahkan ke user untuk pertama kalinya. Kualitas hanya bisa diketahui setelah program berjalan (running) Kualitas dapat dijaga sejak PL dikembangkan. Yang diserahkan ke user adalah program Yang diserahkan adalah program, dokumen, dan data. ***

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC Plan Analysis Design Implementation 4 Fase Utama SDLC

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC Perencanaan Planning Tujuan memahami mengapa system perlu dikembangkan Menentukan cara kerja tim proyek Tahapan Perencanaan Project Inisiation: Identifikasi apakah sistem yang akan dikembangkan akan mengurangi biaya, atau meningkatkan pendapatan Project Management Membuat Workplan Perekrutan sumber daya manusia Menetapkan ruang lingkup proyek, tujuan, jadwal dan anggaran yang diperlukan Plan Analysis Design Implementation

Siklus Hidup Pengembangan Sistem System Development Life Cycle - SDLC Perencanaan Planning Plan Analysis Design Implementation

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC Analisis Analysis Tujuan memahami 5W Tahapan Analisis Strategi Analisis Pengumpulan Kebutuhan Penyusunan Proposal Sistem Membuat Workplan Perekrutan sumber daya manusia Plan Analysis Design Implementation

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC Perancangan Design Tujuan Menentukan bagaimana system akan beroprasi, terkait Infrastuktur HW, SW, jaringan, UI,database, file, dan spesifik program Tahapan Perancangan Penentuan Strategi Perancangan Perancangan Arsitektur, dan Interface Pembuatan database dan spesifikasi file Perancangan Program Plan Analysis Design Implementation

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC Implementasi Implementation Tahapan Implementasi Pembuatan dan Pengujian Sistem Installasi Sistem Perencanaan Support dan Maintenance Plan Analysis Design Implementation

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC Plan Analysis Design Implementation

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC

Siklus Hidup Pengembangan Software Software Development Life Cycle - SDLC

Metodologi Pengembangan Perangka Lunak Software Development Methodology Stuctured Analysis Waterfall model Paralel Development Model

Modified Waterfall Model (M.Kochanski) Sashimi Waterfall with Subprojects Waterfall with Spiral Introduction

Metodologi Pengembangan Perangka Lunak Software Development Methodology Agile Spiral Methodology Agile Programming Extreme Programming (XP) Incremental Model Extreme Programming Spiral Methodology

Metodologi Pengembangan Perangka Lunak Software Development Methodology Agile Spiral Methodology Agile Programming Extreme Programming (XP) Incremental Model Incremental Model

Metodologi Pengembangan Perangka Lunak Software Development Methodology Rapid Application Development - RAD Tujuan RAD: memotong waktu dan biaya pengembangan melibatkan pengguna di setiap fase pengembangan sistem. memungkinkan tim pengembangan untuk melakukan modifikasi yang diperlukan dengan cepat, sebagai desain berevolusi. penting membatasi biaya perubahan yang biasanya terjadi dalam perkembangan yang panjang dan berlarut-larut. Selain keterlibatan pengguna, tim RAD yang sukses harus memiliki sumber daya IT, keterampilan, dan dukungan manajemen. Karena itu adalah proses yang dinamis, yang digerakkan oleh pengguna, Cocok digunakan pada perusahaan membutuhkan sistem informasi untuk mendukung fungsi bisnis baru. RAD

Rapid Application Development (RAD) Model Adaptasi dari waterfall model yang: Menciptakan sistem fungsional yang utuh dalam waktu 60-90 hari. Untuk aplikasi sistem konstruksi Menekankan komponen program yang bisa dipakai kembali / reusabilitas.

Throw-away Prototyping Metodologi Pengembangan Perangka Lunak Software Development Methodology Rapid Application Development - RAD Phased Development Phased Development Prototyping Throw-away Prototyping Prototyping Throw-away Prototyping

Prototyping Model Dipakai jika: Sistem mempunyai resiko tinggi tidak jelas permasalahannya Lebih fokus pada perancangan dialog user - komputer bagaimana membuat dialog yang baik, ramah, mudah ? Sistem diminati oleh banyak pemakai mencari kesepakatan (dasar untuk menyamakan persepsi) User ingin cepat selesai user tidak sabar menunggu prototipe segera memperlihatkan bentuk kerja sistem Masa pakai singkat sistem hanya dipakai beberapa kali saja Ingin menunjukkan inovasi pengembang dapat menunjukkan kecanggihan Kebutuhan berubah-ubah user sulit menjelaskan kebutuhan

Diskusi Buat Perbandingan 2 Metodologi Kelebihan Kelemahan Time Searching : 15 minutes Time Discussion : 10 minutes Buat Perbandingan 2 Metodologi

Metodologi Pengembangan Perangka Lunak Software Development Methodology Structured Object Oriented Agile Deskripsi Merepresentasikan Sistem dalam bentuk data dan proses Merepresentasikan system sebagai objek yang mengkombinasikan data dan proses Proses pengembangan berupa siklus, dimana dalam setiap iterasi terdapat perancangan, pembuatan dan pengujian Biasanya menggunakan spiral Model Alat Pemodelan Data Flow Diagrams UML Tool yang meningkatkatkan komunikasi seperti collaborative software, brainstorming

Metodologi Pengembangan Perangka Lunak Software Development Methodology Structured Object Oriented Kelebihan Mudah didokumentasikan Lebih fleksibel Terintegrasi dengan mudah Program bersifat modular dan reusable Hemat waktu dan biaya pengembangan system Mudah dalam maintain program Kekurangan Perubahan Requirement memerlukan biaya lebih besar Kompleksitas object dan class pada Sistem yang lebih besar

Metodologi Pengembangan Perangka Lunak Software Development Methodology Joint Application Development Rapid Application Development Agile Kelebihan memungkinkan pengguna kunci untuk berpartisipasi secara efektif dalam proses pemodelan kebutuhan menghasilkan pernyataan kebutuhan sistem yang lebih akurat, pemahaman yang lebih baik tentang tujuan bersama, dan komitmen yang lebih kuat untuk keberhasilan sistem baru. Dibandingkan dengan metode terstruktur sistem dapat dikembangkan lebih cepat dengan penghematan biaya yang signifikan. Sangat fleksibel dan effisien terhadap perubahan Lebih mengutamakan interaksi tim pengembang Dapat mengurangi resiko Kekurangan Dibandingkan dengan metode tradisional, JAD lebih mahal dan dapat menjadi rumit jika kelompok itu terlalu besar dibandingkan dengan ukuran proyek. Lebih menekankan pada mekanisme sistem itu sendiri dan tidak menekankan kebutuhan bisnis strategis perusahaan, sehingga tujuan perusahaan dan jangka panjang untuk sistem mungkin tidak terpenuhi. waktu yang dipercepat memicu kelemahan pada segi kualitas konsistensi, dan standar desain. Dibutuhkan kemampuan komunikasi yang baik Lemahnya dokumentasi memicu resiko Project memungkinkan berubah selama kebutuhan user berubah

Panduan Pengembangan Sistem System Development Guidelines Buat Perencanaan yang matang Libatkan User dan dengarkan kebutuhan User Gunakan Teknik dan Tool Manjemen Proyek Buat Informasi Biaya dan Manfaat dengan Tepat Flexible terhadap framework dan workplan

Pemilihan Metodologi Pengembangan Selecting Development Methodology