Tugas Analisis Sistem Informasi 5q3j55

1

Jawaban Tugas Literature Review Assessment Nama : Trino Antonius NIM : 1304508 Tugas : Analisis Sistem Informasi 1.

Apa itu analisis sistem informasi dan desain? Valacich, George & Hoffer (2012, p4), menyatakan sistem analisis dan desain merupakan metodologi yang telah terbukti yang membantu usaha baik besar maupun kecil menuai manfaat dari memanfaatkan informasi untuk kapasitas penuh. Sistem informasi analisis dan desain adalah metode yang digunakan oleh perusahaan mulai dari IBM untuk PepsiCo ke Sony untuk menciptakan dan memelihara sistem informasi yang melakukan fungsi bisnis dasar seperti melacak pelanggan nama dan alamat, memproses pesanan, dan membayar karyawan. Tujuan utama sistem analisis dan desain adalah untuk meningkatkan sistem organisasi, biasanya melalui penerapan perangkat lunak yang dapat membantu karyawan mencapai bisnis utama tugas lebih mudah dan efisien. Sebagai seorang analis sistem, Anda akan berada di pusat pengembangan software ini. Analisis dan desain sistem informasi berdasarkan:  Pemahaman tentang tujuan organisasi, struktur, dan proses  Pengetahuan tentang bagaimana memanfaatkan teknologi informasi untuk keuntungan Analisis sistem Analisis sistem adalah mendefinisikan kebutuhan atau persyaratan terkait sistem yang akan dikembangkan. Pada fase ini menjawab pertanyaan siapa pengguna sistem, apa yg sistim akan lakukan, kapan dan dimana sistim akan diterapkan. Dengan cara menganalisis system yg sedang berjalan, mencari celah celah perbaikan,dan membangun konsep untuk sistim yg baru. Desain sistem Tahap desain memutuskan bagaimana sistem akan beroperasi, dalam hal perangkat keras, perangkat lunak, dan jaringan infrastruktur; antarmuka pengguna, formulir dan laporan, dan program khusus, database, dan file yang akan dibutuhkan.

2.

Daftar dan menjelaskan fase yang berbeda dalam siklus hidup pengembangan sistem. Valacich, George & Hoffer (2012, p17), menjelaskan meskipun setiap siklus hidup muncul pada pandangan pertama menjadi berurutan memerintahkan set fase, sebenarnya tidak. Langkah-langkah spesifik dan urutan mereka dimaksudkan untuk disesuaikan seperti yang diperlukan untuk proyek. Misalnya, dalam setiap fase SDLC yang diberikan, proyek tersebut bisa kembali ke fase awal, jika perlu. Demikian pula, jika produk

2

komersial tidak melakukan dengan baik setelah diperkenalkan, mungkin dihapus sementara dari pasar dan diperbaiki sebelum diperkenalkan kembali. Dalam siklus hidup pengembangan sistem, juga memungkinkan untuk menyelesaikan beberapa kegiatan dalam satu fase secara paralel dengan beberapa kegiatan fase lain. Kadang-kadang siklus hidup adalah iteratif, yaitu, fase yang berulang yang diperlukan sampai suatu sistem yang dapat diterima ditemukan. Beberapa analis sistem mempertimbangkan siklus hidup menjadi spiral, di mana kita terus siklus melalui fase pada berbagai tingkat detail. Sepanjang siklus hidup pengembangan sistem, pengembangan sistem proyek itu sendiri perlu hati-hati direncanakan dan dikelola. Semakin besar sistem proyek, semakin besar kebutuhan untuk manajemen proyek. Beberapa proyek manajemen teknik telah dikembangkan dalam seperempat abad terakhir, dan banyak telah ditingkatkan melalui otomatisasi

3

Sistem Enterprise Resource Planning (ERP) Valacich, George & Hoffer (2012, p31), ERP adalah sebuah sistem berbasis komputer yang mengintegrasikan sistem pemrosessan transaksi, SIM dan DSS ke dalam satu sistem yang akan berfungsi sebagai satu unit terkoordinasi. Manfaatnya : Memudahkan manajemen dalam mengambil keputusan, waktu respon terhadap pesanan pelanggan cepat, efektif dan efisien. Kerugiannya : ERP membutuhkan adanya komitmen keuangan yang besar dari perusahaan. Keuntungan dari implementasi ERP antara lain:

3

a. Integrasi data keuangan untuk mengintegrasikan data keuangan sehingga top management bisa melihat dan mengontrol kinerja keuangan perusahaan dengan lebih baik. b. Standarisasi Proses Operasi untuk menstandarkan proses operasi melalui implementasi best practice sehingga terjadi peningkatan produktivitas, penurunan inefisiensi dan peningkatan kualitas produk. c. Standarisasi Data dan Informasi untuk menstandarkan data dan informasi melalui keseragaman pelaporan, terutama untuk perusahaan besar yang biasanya terdiri dari banyak business unit dengan jumlah dan jenis bisnis yang berbeda-beda Kerugian yang mungkin terjadi ketika salah menerapkan ERP antara lain: a. Strategi operasi tidak sejalan dengan business process design dan pengembangannya. b. Waktu dan biaya implementasi yang melebihi anggaran. c. Karyawan tidak siap untuk menerima dan beroperasi dengan sistem yang baru. d. Persiapan implementation tidak dilakukan dengan baik. e. Berkurangnya fleksibilitas sistem setelah menerapkan ERP. 4.

Diskusikan alasan mengapa organisasi melaksanakan proyek-proyek sistem informasi. Valacich, George & Hoffer (2012, p45) menyatakan perlunya melaksanakan proyekproyek sistem organisasi dikarenakan; a. Organisasi melaksanakan proyek sistem informasi apabila organisasi membutuhkan pengembangan sistem informasi yang dibutuhkan untuk menjalankan tugas pokok dan fungsi dari organisasi itu tersebut. b. Ketika sumber daya organisasi tidak memungkinkan untuk melakukan pengembangan sistem in house (swakelola) maka organisasi melakukan proyek sistem nformasi dengan menggunakan perusahaan penyedia jasa pembangunan sistem informasi.

5 Yang menyebabkan hubungan didahulukan antara kegiatan proyek Valacich, George & Hoffer (2012, p72), Merupakan suatu upaya dimana setiap tahapan-tahapan dalam proyek tersturuktur dan mungkin dapat diselaraskan antar satu kegiatan dengan kegiatan lainnya. Selain itu sebagai pedoman dalam mengambil tindakan dan keputusan dalam meminimalisir resiko yang ada, serta sebagai acuan waktu dimana dalam hal ini kegiatan proyek dapat dilaksanakan sesuai dengan target waktu yang ditetapkan. Software Manajemen Proyek komersial, tiga kegiatan yang diperlukan:  Membangun proyek tanggal awal atau akhir  Masukkan tugas dan menetapkan hubungan tugas  Pilih metode penjadwalan untuk meninjau laporan proyek

4

6 Faktor kelayakan proyek : Valacich, George & Hoffer (2012, p90), faktor kelayakan proyek adalah; i. Ekonomis Tujuan untuk menilai kelayakan ekonomi adalah untuk mengidentifikasi manfaat keuangan dan biaya yang terkait dengan proyek pembangunan. Kelayakan ekonomi sering disebut sebagai analisis biaya-manfaat. Maksudnya apakah proyek yang dikerjakan bermanfaat bagi organisasi dan apakah biaya yang diperlukan untuk proyek tersebut tersedia dan tidak melebihi dari anggaran yang ada. ii. Operasional Kelayakan operasional adalah proses pemeriksaan kemungkinan bahwa proyek ini akan mencapai tujuan yang diinginkan. Tujuan dari penelitian ini adalah untuk memahami sejauh mana sistem yang diusulkan kemungkinan akan memecahkan masalah bisnis atau mengambil keuntungan dari peluang yang digariskan dalam permintaan layanan sistem atau studi identifikasi proyek. iii. Teknis Tujuan dari kelayakan teknis adalah untuk memahami kemampuan pengembangan organisasi untuk membangun sistem yang diusulkan. Analisis ini harus mencakup penilaian terhadap pemahaman kelompok pengembangan terhadap kemungkinan target hardware, perangkat lunak, dan lingkungan operasi yang akan digunakan, serta ukuran sistem, kompleksitas, dan pengalaman kelompok dengan sistem yang serupa. iv. Jadwal kelayakan Jadwal merupakan proses menilai sejauh mana potensi kerangka waktu dan penyelesaian tanggal untuk semua kegiatan utama dalam proyek memenuhi batas waktu dan kendala organisasi mempengaruhi perubahan. v. Hukum dan kontrak Yaitu proses menilai konsekuensi potensi hukum dan kontrak karena pembangunan sistem. Pertimbangan mungkin termasuk hak cipta atau menjaga rahasia pelanggaran, hukum perburuhan, undang-undang antitrust (yang mungkin membatasi penciptaan sistem berbagi data dengan organisasi lain), peraturan perdagangan luar negeri (misalnya, beberapa negara membatasi akses ke data karyawan oleh perusahaan asing), dan pelaporan keuangan standar serta saat ini atau kewajiban apabila kontrak tidak sesuai jadwal. vi. Politik Yaitu proses memahami bagaimana stakeholder kunci dalam organisasi melihat sistem yang diusulkan. Karena sistem informasi dapat mempengaruhi distribusi informasi

5

dalam organisasi, dan dengan demikian distribusi kekuasaan, pembangunan SI dapat memiliki konsekuensi politik. Stakeholder yang tidak mendukung proyek ini dapat mengambil langkah-langkah untuk memblokir, mengganggu, atau mengubah fokus proyek dimaksud. 7.

Analisis sistem Valacich, George & Hoffer (2012, p13-15) menjelaskan Analisis sistem adalah mendefinisikan kebutuhan atau persyaratan terkait sistem yang akan dikembangkan. Pada fase ini menjawab pertanyaan siapa pengguna sistem, apa yg sistim akan lakukan, kapan dan dimana sistim akan diterapkan. Dengan cara menganalisis system yg sedang berjalan, mencari celah celah perbaikan,dan membangun konsep untuk sistim yg baru. Siklus Hidup Pengembangan Sistem (SDLC) yang digunakan dalam chapter ini memiliki empat fase utama : Tahap 1: Sistem Perencanaan dan Seleksi Sistem perencanaan dan seleksi Tahap pertama dari SDLC, di mana kebutuhan total informasi sistem organisasi dianalisis dan diatur, dan di mana informasi proyek sistem potensial diidentifikasi dan argumen untuk melanjutkan atau tidak melanjutkan proyek disajikan. Tahap 2: Analisis Sistem Sistem analisis Tahap dari SDLC dimana sistem yang sekarang dipelajari dan sistem pengganti alternatif yang diusulkan. Tahap 3: Desain Sistem Sistem desain Tahap SDLC dimana sistem yang dipilih untuk pembangunan dalam analisis sistem ini pertama kali dijelaskan secara independen dari platform komputer, (desain logis) dan kemudian berubah menjadi teknologi-rincian spesifik (desain fisik) dari mana semua program dan sistem konstruksi dapat dicapai. Tahap 4: Sistem Implementasi dan Operasi Sistem pelaksanaan dan tahap operasi Akhir SDLC, di mana sistem informasi diimplementasikan, diuji, dan diinstal dalam organisasi, dan di mana sistem informasi secara sistematis diperbaiki dan ditingkatkan. Tahap akhir dari SDLC adalah proses dua langkah: Implementasi sistem dan operasi, Implementasi meliputi coding, pengujian, dan instalasi. Selama coding, programmer menulis program yang membentuk sistem

6

8.

Apa yang dimaksud dengan diagram aliran data? Mengapa analis sistem menggunakan diagram aliran data? Valacich, George & Hoffer (2012, p153-154), menjelaskan tentang DFD; Diagram aliran data (DFD) Sebuah grafik yang menggambarkan pergerakan data antara entitas eksternal dan proses dan menyimpan data dalam suatu sistem. Data-flow diagram adalah salah satu dari beberapa teknik analisis terstruktur digunakan untuk meningkatkan produktivitas pengembangan perangkat lunak. Meskipun tidak semua organisasi menggunakan setiap teknik analisis terstruktur, kolektif, teknik ini, seperti diagram dataflow, memiliki dampak yang signifikan terhadap kualitas proses pengembangan sistem. Menggunakan Data-Flow Diagram dalam Proses Analisis Mempelajari mekanisme menggambar diagram aliran data yang penting bagi Anda karena diagram aliran data adalah alat penting untuk proses analisis terstruktur. Selain menarik DFDs yang mekanis benar, Anda harus khawatir tentang apakah DFD yang lengkap dan konsisten di seluruh tingkatan. Anda juga perlu mempertimbangkan bagaimana Anda dapat menggunakannya sebagai alat untuk analisis.

9. Jelaskan aturan untuk menggambar diagram aliran data yang baik. Valacich, George & Hoffer (2012, p155-156) menjelaskan diagram aliran data juga menunjukkan proses yang mengubah atau mengubah data. Karena diagram aliran data berkonsentrasi pada pergerakan data antara proses, diagram ini disebut model proses Modeling. Pemodelan proses melibatkan grafis mewakili proses, atau tindakan, yang menangkap, memanipulasi, menyimpan, dan mendistribusikan data antara sistem dan lingkungan dan antar komponen dalam sistem. Bentuk umum dari model proses adalah diagram aliran data (DFD). Aturan Pemerintahan Data-Arus Diagram a. Proses  Tidak ada proses yang hanya dapat memiliki output. Hal ini membuat data dari apa-apa (mukjizat). Jika suatu benda hanya memiliki output, maka harus sumber.  Tidak ada proses yang hanya dapat memiliki input (lubang hitam). Jika suatu benda hanya memiliki input, maka harus wastafel.  Sebuah proses memiliki label verba-frase.

7

b. Data Toko/Store  Data tidak bisa bergerak langsung dari satu toko data untuk menyimpan data lain. Data harus dipindahkan oleh suatu proses.  Data tidak bisa bergerak langsung dari sumber luar untuk menyimpan data. Data harus dipindahkan oleh suatu proses yang menerima data dari sumber dan tempat data ke data store.  Data tidak bisa bergerak langsung ke wastafel di luar dari toko data. Data harus dipindahkan oleh suatu proses.  Sebuah toko data memiliki label benda-frase. c. Sumber / Sink  Data tidak bisa bergerak langsung dari sumber ke wastafel. Mereka harus dipindahkan dengan proses jika data menjadi perhatian apapun untuk sistem kami. Jika tidak, aliran data tidak ditampilkan pada DFD.  Sebuah sumber / wastafel memiliki label benda-frase. d. Aliran Data  Sebuah aliran data hanya memiliki satu arah aliran antara simbol. Ini mungkin mengalir di kedua arah antara proses dan menyimpan data untuk menunjukkan membaca

sebelum

update.

Yang

terakhir

ini

biasanya

ditunjukkan,

bagaimanapun, dengan dua panah yang terpisah karena membaca dan memperbarui biasanya terjadi pada waktu yang berbeda.  garpu dalam aliran data berarti bahwa data yang sama persis pergi dari lokasi umum untuk dua atau lebih proses yang berbeda, menyimpan data, atau sumber / tenggelam (biasanya menunjukkan salinan yang berbeda dari data yang sama akan ke lokasi yang berbeda).  bergabung dalam aliran data berarti bahwa data yang sama persis berasal dari salah satu dari dua atau lebih proses yang berbeda, menyimpan data, atau sumber / tenggelam ke lokasi umum.  Sebuah aliran data tidak bisa langsung kembali ke proses yang sama ia meninggalkan. Setidaknya satu proses lain harus menangani aliran data, menghasilkan beberapa aliran data lainnya, dan mengembalikan aliran data asli untuk proses awal.  Sebuah aliran data untuk menyimpan data berarti update (menghapus atau mengubah).  Sebuah aliran data dari data store berarti mengambil atau menggunakan. P. Sebuah aliran data memiliki label benda-frase. Lebih dari satu aliran data frase

8

nomina dapat muncul pada panah tunggal asalkan semua arus pada panah yang sama bergerak bersama sebagai satu paket. 10. Konsistensi DFD Valacich, George & Hoffer (2012, p167), Konsistensi DFD menjelaskan sejauh mana informasi yang terdapat pada satu tingkat dari serangkaian diagram aliran data bersarang juga disertakan pada tingkat lain. Konsep konsistensi DFD mengacu pada apakah penggambaran sistem yang ditunjukkan pada satu tingkat dari DFD yang kompatibel dengan penggambaran sistem yang ditunjukkan pada tingkat lainnya. Contoh : Sebuah pelanggaran berat konsistensi akan menjadi level-1 diagram tanpa tingkat-0 diagram. Contoh lain dari inkonsistensi akan menjadi aliran data yang muncul pada DFD tingkat yang lebih tinggi tetapi tidak pada tingkat yang lebih rendah (pelanggaran balancing). Namun, contoh lain adalah aliran data yang melekat pada satu objek pada diagram tingkat yang lebih rendah tetapi melekat pada obyek lain pada tingkat yang lebih tinggi. Misalnya, aliran data bernama Pembayaran, yang berfungsi sebagai masukan untuk Proses 1 pada tingkat-0 DFD, muncul sebagai masukan untuk Proses 2.1 pada tingkat-1 diagram untuk Proses 2. Anda dapat menggunakan fasilitas analisis CASE tools untuk mendeteksi inkonsistensi tersebut di bersarang (atau membusuk) diagram aliran data. Misalnya, untuk menghindari membuat kesalahan konsistensi DFD ketika Anda menggambar DFD menggunakan alat CASE, alat yang paling otomatis akan menempatkan arus masuk dan keluar dari sebuah proses pada DFD Anda buat ketika Anda menginformasikan alat untuk menguraikan proses tersebut. Dalam memanipulasi diagram tingkat rendah, Anda secara tidak sengaja bisa menghapus atau mengubah aliran data, yang akan menyebabkan diagram untuk keluar dari keseimbangan, dengan demikian, fasilitas konsistensi cek dengan alat kasus cukup membantu. Kelengkapan DFD Sejauh mana semua komponen yang diperlukan dari sebuah diagram aliran data telah dimasukkan dan sepenuhnya dijelaskan. Kelengkapan Konsep kelengkapan DFD mengacu pada apakah DFD Anda mencakup semua komponen yang diperlukan untuk sistem Anda pemodelan. Jika Anda berisi DFD arus data yang tidak mengarah ke mana pun, atau menyimpan data, proses, atau entitas eksternal yang tidak terhubung ke hal lain, DFD Anda tidak lengkap. Kebanyakan alat CASE memiliki built-in fasilitas untuk membantu menemukan ketidaklengkapan dalam DFD Anda. Ketika Anda menarik banyak DFD untuk sistem, tidak jarang membuat kesalahan, baik fungsi analisis KASUS-alat atau penelusuran dengan analis lainnya dapat membantu Anda

9

mengidentifikasi masalah tersebut. Tidak hanya harus semua elemen penting dari DFD hadir, masing-masing komponen harus sepenuhnya dijelaskan dalam kamus proyek. Bagi kebanyakan alat KASUS, ketika Anda mendefinisikan sebuah proses, aliran, sumber / wastafel, atau menyimpan data data pada DFD, entri secara otomatis dibuat dalam repositori alat untuk elemen. Anda kemudian harus memasukkan repositori dan melengkapi keterangan elemen. Informasi deskriptif yang berbeda dapat disimpan tentang masing-masing empat jenis elemen pada DFD, dan masing-masing alat KASUS memiliki informasi masuk yang berbeda. Sebuah entri repositori aliran data meliputi:  Label atau nama untuk aliran data yang dimasukkan pada DFD  Sebuah deskripsi singkat mendefinisikan aliran data  Sebuah daftar objek repositori lainnya dikelompokkan ke dalam kategori berdasarkan jenis objek  Komposisi atau daftar elemen data yang terdapat dalam aliran data  Catatan melengkapi ruang terbatas untuk deskripsi yang melampaui mendefinisikan aliran data untuk menjelaskan konteks dan sifat obyek repositori  Daftar lokasi (nama-nama DFD) yang ini aliran data muncul dan nama-nama sumber dan tujuan untuk aliran data pada masing-masing DFDs ini. 11. Apa karakteristik data yang direpresentasikan dalam sebuah diagram ER? Valacich, George & Hoffer (2012, p189) karakteristik data dalam ERD adalah; a. Karakteristik data yang diambil selama pemodelan data sangat penting dalam desain database, program, layar komputer, dan laporan dicetak. Misalnya, fakta seperti-a ini elemen data berupa angka, produk dapat berada di satu lini produk pada satu waktu, item baris pada pesanan pelanggan tidak pernah bisa dipindahkan ke pelanggan lain order-semua penting dalam memastikan informasi sistem integritas data. b. Data daripada proses adalah aspek yang paling kompleks banyak sistem informasi modern. Sebagai contoh, sistem pemrosesan transaksi dapat memiliki kompleksitas yang cukup besar dalam memvalidasi data, mendamaikan kesalahan, dan koordinasi pergerakan data ke berbagai database. Sistem informasi manajemen (seperti pelacakan penjualan), sistem pendukung keputusan (seperti investasi kas jangka pendek), dan sistem pendukung eksekutif (seperti perencanaan produk) c. Ketiga, karakteristik tentang data (seperti format dan hubungan dengan data lain) agak permanen. Sebaliknya, yang menerima data yang, format laporan, dan laporan apa yang digunakan selalu berubah dari waktu ke waktu. Sebuah model data menjelaskan sifat yang melekat pada organisasi, bukan bentuk transien. Jadi, desain sistem informasi berdasarkan data, bukan dari proses atau logika, harus memiliki

10

kehidupan berguna. Akhirnya, informasi tentang struktur data sangat penting untuk menghasilkan program secara otomatis. Misalnya, fakta bahwa pesanan pelanggan memiliki banyak item baris sebagai lawan hanya satu mempengaruhi desain otomatis bentuk komputer di Microsoft Access bagi masuknya pesanan pelanggan. 12 Apa elemen diagram aliran data harus dianalisis sebagai bagian dari pemodelan data? Valacich, George & Hoffer (2012, p190-191) menerangkan sebuah model data konseptual adalah representasi data organisasi. Tujuan dari model data konseptual adalah untuk menunjukkan banyak aturan tentang makna dan hubungan antara data yang terlepas dari sistem manajemen database atau pertimbangan pelaksanaan lainnya. Entity-relationship (ER) merupakan model data yang umum digunakan diagram yang menunjukkan bagaimana data disusun dalam suatu sistem informasi. Tujuan utama dari pemodelan data konseptual adalah untuk membuat diagram ER akurat. Sebagai seorang analis sistem, Anda biasanya melakukan pemodelan data konseptual pada waktu yang sama seperti analisis persyaratan lain dan langkah-langkah penataan selama analisis sistem. Anda dapat menggunakan metode seperti wawancara, kuesioner, dan sesi JAD untuk mengumpulkan informasi pemodelan data konseptual. Pada tim pengembangan sistem yang lebih besar, bagian dari tim proyek berkonsentrasi pada pemodelan data sementara anggota tim lainnya memusatkan perhatian pada proses atau model logika. Anda mengembangkan (atau gunakan dari pengembangan sistem sebelumnya) model data konseptual untuk sistem saat ini dan membangun model data konseptual yang mendukung ruang lingkup dan persyaratan untuk sistem yang diusulkan atau ditingkatkan. 13 Menjelaskan hubungan antara kardinalitas minimum dan partisipasi opsional dan wajib. Valacich, George & Hoffer (2012, p203) hubungan kardinalitas minimum dan partisipasi opsional adalah;  Jumlah kasus entitas B yang dapat dikaitkan dengan masing-masing instance dari entitas A  Kardinalitas minimum Jumlah minimum contoh entitas B yang mungkin terkait dengan masing-masing instance dari entitas A  Kardinalitas maksimum Jumlah maksimum contoh entitas B yang mungkin terkait dengan masing-masing instance dari entitas A

11

14 Jelaskan perbedaan antara kunci kandidat dan identifier dari suatu entity. Valacich, George & Hoffer (2012, p199); Candidate key  Atribut (atau kombinasi atribut) yang secara unik mengidentifikasi setiap instance dari suatu entity Identifikasi a. Sebuah kunci kandidat yang telah dipilih sebagai karakteristik unik untuk mengidentifikasi suatu entity b. Aturan seleksi untuk identifier  Pilih kunci kandidat yang tidak akan berubah nilainya  Pilih kunci kandidat yang tidak akan null  Hindari menggunakan tombol cerdas  Mempertimbangkan mengganti nilai kunci pengganti tunggal untuk kunci komposit besar 15 Jelaskan proses prototyping merancang bentuk dan laporan. Kiriman apa yang dihasilkan dari proses ini? Apakah kiriman ini sama untuk semua jenis proyek sistem? Mengapa atau mengapa tidak? Valacich, George & Hoffer (2012, p234) menjelaskan sistem input dan outputformulir dan laporan-diproduksi pada akhir tahap analisis sistem dari SDLC. Selama analisis sistem, namun Anda mungkin belum peduli dengan penampilan yang tepat bentuk dan laporan. Sebaliknya, Anda tetap fokus pada bentuk dan laporan yang diperlukan untuk eksis dan konten yang mereka butuhkan untuk mengandung. Anda mungkin telah didistribusikan kepada pengguna prototipe bentuk dan laporan yang muncul selama analisis sebagai cara untuk mengkonfirmasi persyaratan. Formulir dan laporan secara integral terkait dengan diagram DFD dan ER dikembangkan selama persyaratan penataan. Misalnya, setiap bentuk masukan dikaitkan dengan aliran data yang masuk proses pada DFD, dan setiap bentuk keluaran atau laporan adalah aliran data yang dihasilkan oleh sebuah proses di DFD. Oleh karena itu, isi atau bentuk laporan sesuai dengan elemen data yang terdapat dalam terkait aliran data. Selanjutnya, data pada semua bentuk dan laporan harus terdiri dari elemen data di toko-toko data dan pada model data ER untuk aplikasi atau dihitung dari elemen-elemen data. (. Pada kasus yang jarang, data yang cukup masuk dari input ke output sistem sistem tanpa disimpan dalam sistem) Adalah umum untuk menemukan kelemahan dalam DFD dan ER diagram yang Anda bentuk desain dan laporan; diagram ini harus diperbarui sebagai desain berkembang.

12

bentuk Sebuah dokumen bisnis yang berisi beberapa data yang telah ditetapkan dan dapat mencakup beberapa daerah di mana data tambahan yang harus diisi, biasanya berdasarkan satu catatan database. Laporkan Sebuah dokumen bisnis yang berisi data hanya standar, yang merupakan dokumen pasif hanya digunakan untuk membaca atau melihat, biasanya berisi data dari banyak catatan atau transaksi yang tidak terkait. 16. Berikan beberapa contoh di mana variasi dalam , tugas, sistem, dan karakteristik lingkungan mungkin berdampak pada desain bentuk sistem dan laporan. Valacich, George & Hoffer (2012, p236-237), menjelaskan narasi ikhtisar memberikan gambaran umum dari karakteristik target pengguna, tugas, sistem, dan faktor lingkungan di mana bentuk atau laporan akan digunakan. Tujuannya adalah untuk menjelaskan kepada mereka yang benar-benar akan mengembangkan bentuk akhir, mengapa formulir ini ada, dan bagaimana hal itu akan digunakan sehingga mereka dapat membuat keputusan pelaksanaan yang tepat. Pada bagian ini, Anda daftar informasi umum dan asumsi yang membantu membentuk desain. Sebagai contoh, Gambar 8-4 menunjukkan kutipan dari spesifikasi desain untuk bentuk Status Rekening Nasabah untuk Pine Valley Furniture. Bagian pertama dari spesifikasi, Gambar 8-4A, memberikan gambaran narasi yang berisi informasi yang relevan untuk mengembangkan dan menggunakan formulir dalam PVF. Ikhtisar menjelaskan tugas didukung oleh bentuk, di mana dan kapan formulir tersebut digunakan, karakteristik masyarakat menggunakan formulir, teknologi memberikan formulir, dan informasi terkait lainnya. Sebagai contoh, jika bentuk disampaikan pada terminal tampilan visual, bagian ini akan menggambarkan kemampuan perangkat ini, seperti navigasi dan apakah ia memiliki layar sentuh dan apakah warna dan mouse tersedia. Dalam bagian kedua dari spesifikasi, Gambar 8-4B, contoh desain bentuk ditampilkan. Desain ini dapat tangan-diambil menggunakan lembar koding, meskipun, dalam kebanyakan kasus, dikembangkan dengan menggunakan alat pengembangan

standar.

Menggunakan

alat

pembangunan

yang

sebenarnya

memungkinkan desain untuk menjadi lebih teliti diuji dan dinilai. Bagian akhir dari spesifikasi, Gambar 8-4C, menyediakan semua pengujian dan informasi penilaian kegunaan. Beberapa informasi spesifikasi bisa menjadi tidak relevan ketika merancang bentuk dan laporan tertentu. Sebagai contoh, desain sederhana ya / tidak ada bentuk seleksi mungkin begitu mudah bahwa tidak ada penilaian kegunaan yang dibutuhkan.

13

Juga, banyak dari gambaran narasi mungkin tidak diperlukan kecuali dimaksudkan untuk menyoroti beberapa pengecualian yang harus diperhatikan selama pelaksanaan.

17. Apa tujuan dari normalisasi dalam merancang database? Valacich, George & Hoffer (2012, p274) menjalaskan dalam desain database logis anda menggunakan proses yang disebut normalisasi, yang merupakan cara untuk membangun sebuah model data yang memiliki sifat kesederhanaan, non redundancy, dan pemeliharaan minimal. Dalam kebanyakan situasi, banyak keputusan desain database fisik implisit atau dihilangkan bila Anda memilih teknologi manajemen data untuk digunakan dengan aplikasi tersebut. Hoffer, Ramesh, dan Topi (2011) normalisasi bertujuan untuk pengobatan yang lebih menyeluruh teknik untuk logis dan fisik desain database. 18 Apa hubungan antara primary key dari relasi dan dependensi fungsional antara semua atribut dalam relasi itu? Bagaimana kunci asing diwakili dalam relationalnotation? Valacich, George & Hoffer (2012, p282) menjelaskan normalisasi didasarkan pada analisis ketergantungan fungsional. Ketergantungan fungsional adalah hubungan tertentu antara dua atribut. Dalam relasi yang diketahui, atribut B secara fungsional tergantung pada atribut A jika, untuk setiap nilai yang valid dari A, yang nilai A unik menentukan nilai B. fungsional ketergantungan B pada A diwakili oleh panah, sebagai berikut: A : B (misalnya, emp_id: Nama dalam hubungan Gambar 9-5). Ketergantungan fungsional tidak berarti ketergantungan yang matematika nilai satu atribut dapat dihitung dari nilai atribut lain, melainkan, ketergantungan fungsional B pada A berarti bahwa hanya ada satu nilai B untuk setiap nilai A. Jadi, untuk nilai emp_id diberikan, hanya satu nilai Nama dapat dikaitkan dengan itu, nilai Nama, bagaimanapun, tidak dapat diturunkan dari nilai emp_id. Contoh lain dari dependensi fungsional dari Gambar 9-3B dalam

14

PESANAN, ORDER_NUMBER: order_date, dan FAKTUR, Invoice_Number: Invoice_Date dan ORDER_NUMBER Sebuah atribut mungkin fungsional bergantung pada dua (atau lebih) atribut, bukan pada atribut tunggal. Sebagai contoh, perhatikan hubungan EMP COURSE (emp_id, Kursus, Date_Completed) ditunjukkan pada Gambar 9-7. Kami mewakili dependensi fungsional dalam hubungan ini sebagai berikut: emp_id, Lapangan Date_Completed. Dalam kasus ini, Date_Completed tidak dapat ditentukan oleh baik emp_id atau Kursus saja, karena Date_Completed merupakan karakteristik dari seorang karyawan mengambil kursus.

19 Apa saja empat langkah dalam mengubah diagram ER ke dalam hubungan normalisasi? Valacich, George & Hoffer (2012, p284-285) menjalaskan empat langkah dalam mengubah ERD dalam normalisasi; a. Mewakili entitas. Setiap jenis entitas dalam diagram ER menjadi relasi. Identifier dari tipe entitas menjadi kunci utama dari relasi, dan atribut lain dari tipe entitas menjadi non primer atribut kunci dari relasi. b. Mewakili hubungan. Setiap hubungan dalam diagram ER harus diwakili dalam desain database relasional. Bagaimana kami mewakili hubungan tergantung pada sifatnya. Sebagai contoh, dalam beberapa kasus kami mewakili hubungan dengan membuat primary key dari satu relasi foreign key dari relasi lain. Dalam kasus lain, kita menciptakan hubungan yang terpisah untuk mewakili hubungan. c. Menormalkan hubungan. Hubungan dibuat dalam langkah 1 dan 2 mungkin memiliki redundansi yang tidak perlu. Jadi, kita perlu untuk menormalkan hubungan ini untuk membuat mereka terstruktur. d. Gabung hubungan. Sejauh ini dalam desain database yang telah kita buat berbagai hubungan dari kedua normalisasi bottom-up dari pandangan pengguna dan dari mengubah satu atau lebih diagram ER ke dalam set hubungan. Di set ini berbeda dari hubungan, hubungan berlebihan (dua atau lebih relasi yang menggambarkan tipe entitas yang sama) mungkin perlu digabungkan dan renormalized untuk menghapus redundansi.

15

20 Apa kiriman dari coding, pengujian, dan instalasi? Dan menjelaskan proses pengujian untuk kode. Valacich, George & Hoffer (2012, p321) menjelaskan tentang pengertian; Coding, adalah proses melalui mana spesifikasi desain fisik yang diciptakan oleh tim desain diubah menjadi kode komputer bekerja dengan tim pemrograman. Tergantung pada ukuran dan kompleksitas sistem, coding dapat menjadi terlibat, kegiatan intensif. Setelah coding telah dimulai, proses pengujian dapat dimulai dan dilanjutkan secara paralel. Karena setiap modul program yang dihasilkan, dapat diuji secara individual, kemudian sebagai bagian dari program yang lebih besar, dan kemudian sebagai bagian dari sistem yang lebih besar

Tabel 10-1 menunjukkan kiriman dari coding, pengujian, dan proses instalasi. Hasil yang paling jelas adalah kode itu sendiri, tapi sama pentingnya dengan kode adalah dokumentasi kode. Bahasa pemrograman modern, seperti Visual Basic, dikatakan sebagian besar mendokumentasikan diri. Ketika penamaan standar dan konvensi rancangan program yang digunakan, kode itu sendiri merinci banyak tentang logika program, arti dari data dan variabel, dan lokasi dimana data yang diakses dan output. Tetapi bahkan kode terdokumentasi dengan baik dapat menjadi misterius untuk programmer pemeliharaan yang harus mempertahankan sistem selama bertahun-tahun setelah sistem yang asli ditulis dan pemrogram asli telah pindah ke pekerjaan lain. Oleh karena itu, jelas, dokumentasi lengkap untuk semua modul individu dan program sangat penting untuk kelancaran lanjutan sistem. Sumber: Whitten, L Jeffrey & Bentley, D Lonnie (2007), Systems Analysis and Design Methods, Seventh Edition, McGraw-Hill. Valacich, S.J, George, F. J & Hoffer J.A (2012), Essentials of Systems Analysis and Design, Fifth Edition, Pearson.