1

Jawaban Tugas Literature Review Assessment

Nama

NIM

Tugas

:

:

:

Trino Antonius

1304508

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 proyek-

proyek 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 output-

formulir 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 user, 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.