Rangkuman Part 2 Buku System Analysis and Design
BAB 3
Analisis
Analisis berfokus pada menangkap kebutuhan bisnis untuk sistem. Analisis mengidentifikasi dari sistem “apa”, dan mengarah langsung ke tahap perancangan, sistem “bagaimana” yang ditentukan. Banyak kiriman dibuat selama tahap analisis, termasuk definisi persyaratan, use cases, model proses, dan model data. Pada akhir analisis, semua kiriman ni, bersamaan dengan perencanaan yang telah direvisi dan kiriman manajemen proyek, digabungkan ke dalam proposal sistem dan diserahkan ke pihak yang berhak untuk mensetujui dan memutuskan apakah akan melanjutkan proyek ini atau tidak.
Analisis
Analisis berfokus pada menangkap kebutuhan bisnis untuk sistem. Analisis mengidentifikasi dari sistem “apa”, dan mengarah langsung ke tahap perancangan, sistem “bagaimana” yang ditentukan. Banyak kiriman dibuat selama tahap analisis, termasuk definisi persyaratan, use cases, model proses, dan model data. Pada akhir analisis, semua kiriman ni, bersamaan dengan perencanaan yang telah direvisi dan kiriman manajemen proyek, digabungkan ke dalam proposal sistem dan diserahkan ke pihak yang berhak untuk mensetujui dan memutuskan apakah akan melanjutkan proyek ini atau tidak.
Penentuan Persyaratan
Penentuan persyaratan adalah bagian dari analisis di mana tim proyek mengubah penjelasan tingkat tinggi mengenai persyaratan bisnis yang tercantum dalam permintaan sistem ke dalam daftar kebutuhan yang lebih tepat. Persyaratan hanyalah pernyataan tentang apa yang harus dilakukan sistem atau karakteristik apa yang harus dimiliki. Persyaratan bisnis menggambarkan sistem “apa”, dan persyaratan sistem menggambarkan sistem “bagaimana” yang akan diterapkan. Persyaratan fungsional berhubungan langsung dengan proses yang harus dilakukan atau informasi yang harus ada. Persyaratan non-fungsional mengacu pada sifat perilaku yang harus dimiliki sistem, seperti kinerja dan kegunaan. Semua persyaratan bisnis fungsional dan non-fungsional yang sesuai dengan ruang lingkup sistem ditulis dalam definisi persyaratan.
Penentuan persyaratan adalah bagian dari analisis di mana tim proyek mengubah penjelasan tingkat tinggi mengenai persyaratan bisnis yang tercantum dalam permintaan sistem ke dalam daftar kebutuhan yang lebih tepat. Persyaratan hanyalah pernyataan tentang apa yang harus dilakukan sistem atau karakteristik apa yang harus dimiliki. Persyaratan bisnis menggambarkan sistem “apa”, dan persyaratan sistem menggambarkan sistem “bagaimana” yang akan diterapkan. Persyaratan fungsional berhubungan langsung dengan proses yang harus dilakukan atau informasi yang harus ada. Persyaratan non-fungsional mengacu pada sifat perilaku yang harus dimiliki sistem, seperti kinerja dan kegunaan. Semua persyaratan bisnis fungsional dan non-fungsional yang sesuai dengan ruang lingkup sistem ditulis dalam definisi persyaratan.
Persyaratan Teknik Elicitation
Lima teknik dapat digunakan untuk memperoleh kebutuhan bisnis untuk sistem yang diusulkan: wawancara, pengembangan aplikasi gabungan, kuesioner, analisis dokumen, dan observasi. Wawancara melibatkan pertemuan dengan satu atau banyak orang dan mengajukan pertanyaan kepada mereka. Ada lima langkah dasar dalam proses wawancara: memilih orang yang diwawancarai, merancang pertanyaan wawancara, mempersiapkan wawancara, melakukan wawancara, dan tindak lanjut pasca wawancara. Joint Application Development (JAD) memungkinkan tim proyek, pengguna, dan manajemen bekerja sama untuk mengidentifikasi persyaratan sistem. JAD elektronik mencoba mengatasi masalah umum yang terkait dengan kelompok dengan menggunakan groupware. Kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu. Kuesioner sering digunakan bila dibutuhkan pendapat dan informasi dari banyak orang. Analisis dokumen memerlukan pengkajian dokumentasi yang ada dan memeriksa sistem itu sendiri. Ini bisa memberi wawasan tentang sistem formal dan informal. Pengamatan, tindakan mengamati proses yang sedang dilakukan, adalah alat yang ampuh untuk mengumpulkan informasi tentang sistem seperti apa dan memungkinkan analis untuk melihat realitas suatu situasi secara langsung.
Lima teknik dapat digunakan untuk memperoleh kebutuhan bisnis untuk sistem yang diusulkan: wawancara, pengembangan aplikasi gabungan, kuesioner, analisis dokumen, dan observasi. Wawancara melibatkan pertemuan dengan satu atau banyak orang dan mengajukan pertanyaan kepada mereka. Ada lima langkah dasar dalam proses wawancara: memilih orang yang diwawancarai, merancang pertanyaan wawancara, mempersiapkan wawancara, melakukan wawancara, dan tindak lanjut pasca wawancara. Joint Application Development (JAD) memungkinkan tim proyek, pengguna, dan manajemen bekerja sama untuk mengidentifikasi persyaratan sistem. JAD elektronik mencoba mengatasi masalah umum yang terkait dengan kelompok dengan menggunakan groupware. Kuesioner adalah serangkaian pertanyaan tertulis yang dikembangkan untuk mendapatkan informasi dari individu. Kuesioner sering digunakan bila dibutuhkan pendapat dan informasi dari banyak orang. Analisis dokumen memerlukan pengkajian dokumentasi yang ada dan memeriksa sistem itu sendiri. Ini bisa memberi wawasan tentang sistem formal dan informal. Pengamatan, tindakan mengamati proses yang sedang dilakukan, adalah alat yang ampuh untuk mengumpulkan informasi tentang sistem seperti apa dan memungkinkan analis untuk melihat realitas suatu situasi secara langsung.
Strategi Analisis Persyaratan
Analis seringkali harus membantu pengguna bisnis berpikir kritis tentang persyaratan sistem baru mereka. Beberapa strategi sangat membantu. Analisis masalah dan analisis akar permasalahan adalah dua strategi yang dapat membantu pengguna bisnis dalam memahami permasalahan dan permasalahan pada sistem saat ini yang memerlukan perbaikan. Analisis waktu, activity-based costing, dan benchmarking informal adalah tiga strategi analisis populer yang membantu tim menemukan proses yang paling membutuhkan perancangan ulang. Akhirnya, analisis hasil, analisis teknologi, dan penghapusan aktivitas adalah tiga strategi yang dapat digunakan untuk "memaksa" pengguna bisnis untuk memikirkan proses bisnis dengan cara baru dan baru, mungkin menemukan cara baru untuk menyelesaikan proses bisnis.
Analis seringkali harus membantu pengguna bisnis berpikir kritis tentang persyaratan sistem baru mereka. Beberapa strategi sangat membantu. Analisis masalah dan analisis akar permasalahan adalah dua strategi yang dapat membantu pengguna bisnis dalam memahami permasalahan dan permasalahan pada sistem saat ini yang memerlukan perbaikan. Analisis waktu, activity-based costing, dan benchmarking informal adalah tiga strategi analisis populer yang membantu tim menemukan proses yang paling membutuhkan perancangan ulang. Akhirnya, analisis hasil, analisis teknologi, dan penghapusan aktivitas adalah tiga strategi yang dapat digunakan untuk "memaksa" pengguna bisnis untuk memikirkan proses bisnis dengan cara baru dan baru, mungkin menemukan cara baru untuk menyelesaikan proses bisnis.
BAB 4
Use Case
Use case berisi semua informasi yang dibutuhkan untuk membangun satu bagian dari model proses, yang dinyatakan secara informal dan sederhana. Use case memiliki nama, nomor, tingkat kepentingan, deskripsi singkat, aktor utama, pemicu (trigger), prasyarat (precondition), postcondition, inputan utama dan keluaran (output), dan daftar langkah utama yang diperlukan untuk menjalankannya. Use case dapat diidentifikasi dengan meninjau persyaratan fungsional. Daftar kejadian dan respon juga berguna dalam mengidentifikasi peristiwa penting yang harus dijelaskan dalam use case. Setelah use case selesai, seringkali persyaratan fungsional baru dan perluasan dapat diturunkan.
Use Case
Use case berisi semua informasi yang dibutuhkan untuk membangun satu bagian dari model proses, yang dinyatakan secara informal dan sederhana. Use case memiliki nama, nomor, tingkat kepentingan, deskripsi singkat, aktor utama, pemicu (trigger), prasyarat (precondition), postcondition, inputan utama dan keluaran (output), dan daftar langkah utama yang diperlukan untuk menjalankannya. Use case dapat diidentifikasi dengan meninjau persyaratan fungsional. Daftar kejadian dan respon juga berguna dalam mengidentifikasi peristiwa penting yang harus dijelaskan dalam use case. Setelah use case selesai, seringkali persyaratan fungsional baru dan perluasan dapat diturunkan.
Membuat Use Cases
Saat menulis use case, pertama-tama kenali kejadian pemicu (eksternal atau temporal) dan aktor utama. Selanjutnya, kembangkan daftar langkah langkah utama yang terlibat dalam menggunakan input untuk menghasilkan keluaran yang dibutuhkan dan respon yang diinginkan terhadap kejadian tersebut. Sekarang, pikirkan lebih dalam tentang setiap langkah dan identifikasi input dan keluaran spesifik untuk setiap langkah. Akhirnya, mintalah pengguna memainkan peran use case untuk memverifikasi bahwa itu benar seperti yang tertulis.
Saat menulis use case, pertama-tama kenali kejadian pemicu (eksternal atau temporal) dan aktor utama. Selanjutnya, kembangkan daftar langkah langkah utama yang terlibat dalam menggunakan input untuk menghasilkan keluaran yang dibutuhkan dan respon yang diinginkan terhadap kejadian tersebut. Sekarang, pikirkan lebih dalam tentang setiap langkah dan identifikasi input dan keluaran spesifik untuk setiap langkah. Akhirnya, mintalah pengguna memainkan peran use case untuk memverifikasi bahwa itu benar seperti yang tertulis.
BAB 5
Data Flow Diagram Sintaks
Empat simbol digunakan pada data flow diagram (proses, data flow, data store, dan entitas eksternal). Proses adalah aktivitas yang melakukan sesuatu. Setiap proses memiliki nama (frase kata kerja), deskripsi, dan angka yang menunjukkan dimana hal itu terhubung dengan proses lain dan proses anak-anaknya. Setiap proses harus memiliki setidaknya satu keluaran dan biasanya memiliki setidaknya satu masukan. Data flow adalah sepotong data atau objek dan memiliki nama (kata benda) dan deskripsi yang dimulai atau berakhir pada suatu proses (atau keduanya). Data store adalah file manual atau komputer, dan memiliki nomor, nama (kata benda), dan setidaknya satu data flow masukan dan satu data flow keluaran (kecuali jika penyimpanan data dibuat oleh proses di luar data flow diagram [DFD]). Entitas eksternal adalah orang, organisasi, atau sistem di luar ruang lingkup sistem dan memiliki nama (kata benda) dan deskripsi. Setiap rangkaian DFD dimulai dengan diagram konteks dan DFD tingkat 0 dan memiliki DFD tingkat 1, DFD tingkat 2, dan seterusnya. Setiap elemen pada DFD tingkat tinggi (yaitu, data flow, data store, dan entitas eksternal) harus muncul di DFD tingkat rendah, atau tidak seimbang.
Data Flow Diagram Sintaks
Empat simbol digunakan pada data flow diagram (proses, data flow, data store, dan entitas eksternal). Proses adalah aktivitas yang melakukan sesuatu. Setiap proses memiliki nama (frase kata kerja), deskripsi, dan angka yang menunjukkan dimana hal itu terhubung dengan proses lain dan proses anak-anaknya. Setiap proses harus memiliki setidaknya satu keluaran dan biasanya memiliki setidaknya satu masukan. Data flow adalah sepotong data atau objek dan memiliki nama (kata benda) dan deskripsi yang dimulai atau berakhir pada suatu proses (atau keduanya). Data store adalah file manual atau komputer, dan memiliki nomor, nama (kata benda), dan setidaknya satu data flow masukan dan satu data flow keluaran (kecuali jika penyimpanan data dibuat oleh proses di luar data flow diagram [DFD]). Entitas eksternal adalah orang, organisasi, atau sistem di luar ruang lingkup sistem dan memiliki nama (kata benda) dan deskripsi. Setiap rangkaian DFD dimulai dengan diagram konteks dan DFD tingkat 0 dan memiliki DFD tingkat 1, DFD tingkat 2, dan seterusnya. Setiap elemen pada DFD tingkat tinggi (yaitu, data flow, data store, dan entitas eksternal) harus muncul di DFD tingkat rendah, atau tidak seimbang.
Membuat Data Flow Diagram
DFD dibuat dari use case. Pertama, tim membangun diagram konteks yang menunjukkan semua entitas eksternal dan data flow masuk dan keluar dari sistemnya. Kedua, tim membuat fragmen DFD untuk setiap use case yang menunjukkan bagaimana use case mentransformasikan data flow dengan entitas eksternal dan data store. Ketiga, fragmen DFD ini disusun ke dalam DFD level 0. Keempat, tim mengembangkan DFD tingkat 1 berdasarkan langkah langkah dalam setiap kasus penggunaan untuk menjelaskan dengan lebih baik bagaimana mereka beroperasi. Kelima, tim memvalidasi kumpulan DFD untuk memastikannya lengkap dan benar dan tidak mengandung kesalahan sintaks atau semantik. Analis jarang membuat DFD secara sempurna untuk pertama kalinya. Jadi iterasi penting untuk memastikan DFD satu halaman atau lebih, jelas dan mudah dibaca.
DFD dibuat dari use case. Pertama, tim membangun diagram konteks yang menunjukkan semua entitas eksternal dan data flow masuk dan keluar dari sistemnya. Kedua, tim membuat fragmen DFD untuk setiap use case yang menunjukkan bagaimana use case mentransformasikan data flow dengan entitas eksternal dan data store. Ketiga, fragmen DFD ini disusun ke dalam DFD level 0. Keempat, tim mengembangkan DFD tingkat 1 berdasarkan langkah langkah dalam setiap kasus penggunaan untuk menjelaskan dengan lebih baik bagaimana mereka beroperasi. Kelima, tim memvalidasi kumpulan DFD untuk memastikannya lengkap dan benar dan tidak mengandung kesalahan sintaks atau semantik. Analis jarang membuat DFD secara sempurna untuk pertama kalinya. Jadi iterasi penting untuk memastikan DFD satu halaman atau lebih, jelas dan mudah dibaca.
BAB 6
Dasar Entity Relationship Diagram Syntax
Diagram hubungan entitas (entity relationship diagram / ERD) adalah teknik yang paling umum untuk menggambar model data, cara formal untuk mewakili data yang digunakan dan diciptakan oleh sistem bisnis. Ada tiga elemen dasar dalam bahasa pemodelan data, masing masing diwakili oleh simbol grafis yang berbeda. Entitas adalah blok bangunan dasar untuk model data. Ini adalah orang, tempat, atau hal tentang data yang dikumpulkan. Atribut adalah beberapa jenis informasi yang ditangkap tentang suatu entitas.
Dasar Entity Relationship Diagram Syntax
Diagram hubungan entitas (entity relationship diagram / ERD) adalah teknik yang paling umum untuk menggambar model data, cara formal untuk mewakili data yang digunakan dan diciptakan oleh sistem bisnis. Ada tiga elemen dasar dalam bahasa pemodelan data, masing masing diwakili oleh simbol grafis yang berbeda. Entitas adalah blok bangunan dasar untuk model data. Ini adalah orang, tempat, atau hal tentang data yang dikumpulkan. Atribut adalah beberapa jenis informasi yang ditangkap tentang suatu entitas.
Atribut yang secara unik dapat mengidentifikasi satu instance dari suatu entitas disebut identifier. Komponen model data ketiga adalah hubungan (relationship), yang menyampaikan hubungan antar entitas. Hubungan memiliki kardinalitas (rasio contoh orang tua terhadap kejadian di anak) dan modalitas (orang tua perlu ada jika ada anak). Informasi tentang semua komponen ditangkap oleh metadata dalam kamus data.
Membuat Entity Relationship Diagram
Langkah dasar dalam membangun ERD adalah (1) mengidentifikasi entitas, (2) menambahkan atribut yang sesuai ke setiap entitas, dan (3) menarik hubungan antar entitas untuk menunjukkan bagaimana hubungan mereka satu sama lain. Ada tiga jenis entitas khusus yang mengandung ERD. Sebagian besar entitas independen, karena satu atribut (atau lebih) dapat digunakan untuk mengidentifikasi instance secara unik. Entitas yang mengandalkan atribut dari entitas lain untuk mengidentifikasi sebuah instance yang bergantung dengan lainnya. Sebuah persimpangan entitas ditempatkan di antara dua entitas untuk menangkap informasi tentang hubungannya. Secara umum, model data didasarkan pada interpretasi; Oleh karena itu, penting untuk menyatakan dengan jelas asumsi asumsi yang mencerminkan peraturan bisnis.
Memvalidasi Entity Relationship Diagram
Normalisasi, proses dimana serangkaian peraturan diterapkan pada model data logis untuk menentukan seberapa baik terbentuknya. Model data logis ada dalam bentuk normal pertama (1NF) jika tidak mengandung atribut berulang, yang merupakan atribut yang menangkap beberapa nilai untuk satu instance. Bentuk normal kedua (2NF) mensyaratkan bahwa semua entitas berada dalam 1NF dan hanya berisi atribut yang nilainya bergantung pada keseluruhan pengenal (yaitu, tidak ada ketergantungan parsial). Bentuk normal ketiga (3NF) terjadi ketika sebuah model berada dalam 1NF dan 2NF dan tidak ada atribut yang dihasilkan bergantung pada atribut non-identifier (yaitu, tidak ada ketergantungan transitif). Dengan setiap pelanggaran, entitas tambahan harus dibuat untuk menghapus atribut yang berulang atau ketergantungan yang tidak semestinya dari entitas yang ada. Akhirnya, ERD harus diimbangi dengan data flow diagram (DFD) dengan memastikan bahwa entitas model data dan atribut sesuai dengan data store dan data flow pada model proses. Matriks CRUD adalah alat yang berharga untuk digunakan saat menyeimbangkan proses dan model data.
Normalisasi, proses dimana serangkaian peraturan diterapkan pada model data logis untuk menentukan seberapa baik terbentuknya. Model data logis ada dalam bentuk normal pertama (1NF) jika tidak mengandung atribut berulang, yang merupakan atribut yang menangkap beberapa nilai untuk satu instance. Bentuk normal kedua (2NF) mensyaratkan bahwa semua entitas berada dalam 1NF dan hanya berisi atribut yang nilainya bergantung pada keseluruhan pengenal (yaitu, tidak ada ketergantungan parsial). Bentuk normal ketiga (3NF) terjadi ketika sebuah model berada dalam 1NF dan 2NF dan tidak ada atribut yang dihasilkan bergantung pada atribut non-identifier (yaitu, tidak ada ketergantungan transitif). Dengan setiap pelanggaran, entitas tambahan harus dibuat untuk menghapus atribut yang berulang atau ketergantungan yang tidak semestinya dari entitas yang ada. Akhirnya, ERD harus diimbangi dengan data flow diagram (DFD) dengan memastikan bahwa entitas model data dan atribut sesuai dengan data store dan data flow pada model proses. Matriks CRUD adalah alat yang berharga untuk digunakan saat menyeimbangkan proses dan model data.
Opmerkings
Plaas 'n opmerking