Anda di halaman 1dari 15

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.

Anda mungkin juga menyukai