TIPE SISTEM

Sistem informasi yang dikembangkan untuk tujuan yang berbeda, tergantung pada kebutuhan pengguna manusia
dan bisnis. Sistem pemrosesan transaksi (TPS) fungsi pada tingkat operasional
organisasi; sistem otomatisasi kantor (OAS) dan sistem kerja pengetahuan (KWS) dukungan
bekerja di tingkat pengetahuan. Sistem-tingkat yang lebih tinggi termasuk sistem informasi manajemen
(MIS) dan sistem pendukung keputusan (DSS). Sistem pakar menerapkan keahlian pengambil keputusan
untuk memecahkan yang spesifik, masalah terstruktur. Pada tingkat strategis manajemen kita menemukan eksekutif
sistem pendukung (ESS). Sistem pendukung keputusan kelompok (GDSS) dan lebih umum
sistem kerja kolaboratif yang didukung komputer dijelaskan (CSCWS) keputusan bantuan kelompok-tingkat
pembuatan berbagai semistructured atau tidak terstruktur.
Berbagai sistem informasi yang analis dapat mengembangkan ditunjukkan pada Gambar 1.1. Pemberitahuan
bahwa angka ini menyajikan sistem ini dari bawah ke atas, menunjukkan bahwa operasional, atau terendah,
tingkat organisasi didukung oleh TPS, dan strategis, atau tertinggi, tingkat semiterstruktur
dan keputusan tidak terstruktur didukung oleh ESS, GDSS, dan CSCWS di atas. Teks ini menggunakan
sistem informasi manajemen hal, sistem informasi (IS), informasi yang terkomputerisasi
sistem, dan sistem informasi bisnis komputerisasi secara bergantian untuk menunjukkan komputerisasi
sistem informasi yang mendukung jangkauan luas interaksi pengguna dengan teknologi dan bisnis
kegiatan melalui informasi yang mereka hasilkan dalam konteks organisasi.
Sistem Pengolahan Transaksi
Sistem pemrosesan transaksi (TPS) adalah sistem informasi yang terkomputerisasi yang dikembangkan
untuk memproses data dalam jumlah besar untuk transaksi bisnis rutin seperti daftar gaji dan inventarisasi. SEBUAH
TPS menghilangkan kebosanan transaksi operasional yang diperlukan dan mengurangi waktu yang dibutuhkan sekali
untuk melakukan secara manual, meskipun orang harus tetap input data ke sistem komputerisasi.
Sistem pemrosesan transaksi adalah sistem batas-spanning yang memungkinkan organisasi
untuk berinteraksi dengan lingkungan eksternal. Karena manajer melihat ke data yang dihasilkan oleh TPS
untuk up-to-the-menit informasi tentang apa yang terjadi di perusahaan mereka, adalah penting untuk
operasi sehari-hari dari bisnis yang sistem ini berfungsi dengan lancar dan tanpa gangguan.
Sistem Otomasi kantor dan Pengetahuan Sistem Kerja
Pada tingkat pengetahuan organisasi dua kelas sistem. Sistem otomatisasi kantor
(OAS) pekerja dukungan data, yang biasanya tidak menciptakan pengetahuan baru melainkan menganalisis informasi
untuk mengubah data atau memanipulasinya dalam beberapa cara sebelum berbagi dengan, atau secara resmi
menyebarkan
itu seluruh, organisasi dan, kadang-kadang, di luar. Aspek akrab OAS mencakup pengolah kata, spreadsheet, desktop
publishing, penjadwalan elektronik, dan komunikasi
melalui voice mail, email (surat elektronik), dan telekonferensi.
Sistem kerja pengetahuan (KWS) mendukung para pekerja profesional seperti ilmuwan, insinyur,
dan dokter dengan membantu mereka dalam upaya mereka untuk menciptakan pengetahuan baru (sering di tim) dan
dengan memungkinkan
mereka untuk berkontribusi kepada organisasi mereka atau masyarakat luas.
sistem Informasi Manajemen
Sistem informasi manajemen (MIS) tidak menggantikan sistem pemrosesan transaksi; bukan,
semua MIS termasuk proses transaksi. MIS adalah sistem informasi terkomputerisasi yang bekerja karena
dari interaksi antara tujuan orang dan komputer. Dengan mewajibkan orang, perangkat lunak,
dan perangkat keras berfungsi dalam konser, sistem informasi manajemen mendukung pengguna dalam mencapai
spektrum yang lebih luas dari tugas-tugas organisasi dari sistem pemrosesan transaksi, termasuk
analisis keputusan dan pengambilan keputusan.
Untuk mengakses informasi, pengguna sistem informasi manajemen berbagi database umum.
Toko Database data dan model yang membantu pengguna berinteraksi dengan, menafsirkan, dan menerapkan
Data itu. Manajemen informasi keluaran sistem informasi yang digunakan dalam pengambilan
pembuatan. Sistem informasi Amanagement juga dapat membantu mengintegrasikan beberapa informasi terkomputerisasi
fungsi bisnis.
Sistem Pendukung Keputusan
Kelas ahigher-tingkat sistem informasi komputerisasi adalah sistem pendukung keputusan (DSS). DSS
mirip dengan sistem informasi manajemen tradisional karena mereka berdua tergantung pada database
sebagai sumber data. Adecision sistem pendukung berangkat dari informasi manajemen tradisional
sistem karena menekankan dukungan pengambilan keputusan dalam semua tahapan yang, meskipun
keputusan yang sebenarnya masih provinsi eksklusif pembuat keputusan. Sistem pendukung keputusan yang
disesuaikan lebih dekat kepada orang atau kelompok yang menggunakan mereka daripada adalah informasi manajemen
tradisional
sistem. Kadang-kadang mereka akan dibahas sebagai sistem yang berfokus pada intelijen bisnis.
Artificial Intelligence and expert systems
Kecerdasan buatan (AI) dapat dianggap bidang menyeluruh untuk sistem pakar. Umum
dorong dari AI telah mengembangkan mesin yang berperilaku cerdas. Dua jalan penelitian AI
adalah (1) memahami bahasa alami dan (2) menganalisis kemampuan untuk berpikir melalui
masalah untuk kesimpulan logis. Sistem pakar menggunakan pendekatan penalaran AI untuk memecahkan
masalah yang diajukan kepada mereka dengan bisnis (dan lainnya) pengguna.
Sistem pakar adalah kelas yang sangat khusus sistem informasi yang telah dibuat praktis
untuk digunakan oleh bisnis sebagai akibat dari ketersediaan luas hardware dan software seperti
komputer pribadi (PC) dan kerang sistem pakar. Sistem pakar (juga disebut knowledgebased
sistem) secara efektif menangkap dan menggunakan pengetahuan manusia ahli atau pakar untuk memecahkan
masalah tertentu berpengalaman dalam sebuah organisasi. Perhatikan bahwa tidak seperti DSS, yang meninggalkan
penghakiman utama untuk pengambil keputusan, sistem pakar memilih solusi terbaik untuk masalah
atau kelas tertentu masalah.
Komponen dasar dari sistem pakar adalah basis pengetahuan, mesin inferensi menghubungkan
pengguna dengan sistem oleh permintaan pengolahan melalui bahasa seperti bahasa query terstruktur

(SQL), dan user interface. Orang disebut insinyur pengetahuan menangkap keahlian
ahli, membangun sistem komputer yang mencakup pengetahuan ahli ini, dan kemudian menerapkannya.
Kelompok Pendukung Keputusan Sistem dan Komputer-Didukung Kolaborasi Sistem Kerja
Organisasi menjadi semakin bergantung pada kelompok atau tim untuk membuat keputusan bersama.
Ketika kelompok membuat keputusan semiterstruktur atau tidak terstruktur, sistem pendukung keputusan kelompok dapat
membeli solusi. Sistem pendukung keputusan kelompok (GDSS), yang digunakan dalam ruangan khusus
dilengkapi di sejumlah konfigurasi yang berbeda, memungkinkan anggota kelompok untuk berinteraksi dengan elektronik
dukungan-sering dalam bentuk software-dan khusus fasilitator kelompok khusus. Keputusan kelompok
sistem pendukung dimaksudkan untuk membawa kelompok bersama-sama untuk memecahkan masalah dengan bantuan
berbagai
mendukung seperti polling, kuesioner, brainstorming, dan penciptaan skenario. GDSS software dapat
dirancang untuk meminimalkan perilaku kelompok negatif khas seperti kurangnya partisipasi karena takut
pembalasan untuk mengekspresikan dominasi tidak populer atau diperebutkan sudut pandang, oleh anggota kelompok vokal,
dan "kelompok berpikir" pengambilan keputusan. Kadang-kadang GDSS dibahas di bawah yang lebih umum
sistem kerja kolaboratif jangka komputer-didukung (CSCWS), yang mungkin termasuk dukungan perangkat lunak
disebut groupware untuk tim kolaborasi melalui jaringan komputer. Sistem pendukung keputusan kelompok
juga dapat digunakan dalam pengaturan virtual.
Sistem Pendukung Eksekutif
Ketika eksekutif beralih ke komputer, mereka sering mencari cara untuk membantu mereka membuat keputusan
pada tingkat strategis. Sistem pendukung eksekutif (ESS) membantu eksekutif mengatur interaksi mereka
dengan lingkungan eksternal dengan menyediakan grafik dan teknologi komunikasi
di tempat-tempat yang dapat diakses seperti ruang rapat atau kantor perusahaan pribadi. Meskipun ESS bergantung pada
informasi yang dihasilkan oleh TPS dan MIS, sistem pendukung eksekutif membantu pengguna mereka mengatasi terstruktur
masalah keputusan, yang tidak aplikasi tertentu, dengan menciptakan lingkungan yang
membantu mereka berpikir tentang masalah strategis dengan cara yang tepat. ESS memperluas dan mendukung
kemampuan
eksekutif, memungkinkan mereka untuk memahami lingkungan mereka.
INTEGRASI TEKNOLOGI UNTUK SISTEM
Sebagai pengguna mengadopsi teknologi baru, beberapa pekerjaan sistem analis akan dikhususkan untuk mengintegrasikan
sistem tradisional dengan yang baru untuk memastikan konteks yang berguna, seperti yang ditunjukkan pada Gambar 1.2.
Bagian ini
menjelaskan beberapa informasi baru sistem teknologi analis akan menggunakan sebagai orang
bekerja untuk mengintegrasikan aplikasi e-commerce mereka ke bisnis tradisional mereka atau ketika mereka mulai
ebusinesses yang sama sekali baru.
Aplikasi e-commerce dan Sistem Web
Banyak sistem yang dibahas di sini dapat dijiwai dengan fungsionalitas yang lebih besar jika mereka bermigrasi
sebagai teknologi berbasis Web.
Ada banyak manfaat untuk pemasangan atau perbaikan aplikasi di Web:
1. Meningkatkan kesadaran pengguna ketersediaan layanan, produk, industri, orang, atau kelompok.
2. Kemungkinan akses 24 jam untuk pengguna

3. Meningkatkan kegunaan dan kegunaan dari desain antarmuka.

4. Membuat sistem yang dapat memperpanjang global daripada tetap lokal, sehingga menjangkau orang-orang di
lokasi terpencil tanpa khawatir zona waktu di mana mereka berada.
Sistem Perusahaan
Banyak organisasi membayangkan potensi manfaat dari integrasi sistem informasi banyak
yang ada pada tingkat manajemen yang berbeda dan dalam fungsi yang berbeda. Beberapa penulis membahas integrasi
sebagai arsitektur berorientasi layanan (SOA), yang ada di lapisan. Sistem perusahaan akan
terdiri lapisan atas. Sistem perusahaan, juga disebut perencanaan sumber daya perusahaan (ERP) sistem,
dirancang untuk melakukan integrasi ini. Melembagakan ERP memerlukan komitmen besar
dan perubahan organisasi. Seringkali sistem analis berfungsi sebagai konsultan untuk usaha ERP yang menggunakan
software proprietary. Populer software ERP termasuk yang dari SAP dan Oracle. Beberapa ini
paket yang ditargetkan terhadap perusahaan bergerak ke Web. Biasanya, analis serta
beberapa pengguna memerlukan pelatihan penjual, dukungan, dan pemeliharaan untuk dapat merancang benar, menginstal,
mempertahankan, memperbarui, dan menggunakan paket ERP tertentu.
Sistem untuk Wireless dan Mobile Devices
Analis diminta untuk merancang sejumlah sistem baru dan aplikasi untuk petualang
pengguna, termasuk banyak untuk perangkat nirkabel dan mobile seperti Apple iPhone, iPod, atau
BlackBerry. Selain itu, analis mungkin menemukan diri mereka merancang komunikasi standar atau wireless
jaringan untuk pengguna yang mengintegrasikan suara, video, pesan teks, dan email ke organisasi
intranet atau extranet industri. E-commerce nirkabel disebut sebagai mCommerce (mobile
commerce).
Jaringan area lokal nirkabel (WLAN); jaringan wireless fidelity, disebut Wi-Fi; dan pribadi
jaringan nirkabel yang mempertemukan banyak jenis perangkat di bawah standar disebut Bluetooth
semua sistem yang Anda mungkin diminta untuk merancang. Dalam pengaturan yang lebih maju, analis mungkin
dipanggil untuk merancang agen cerdas, perangkat lunak yang dapat membantu pengguna dengan tugas-tugas di mana
perangkat lunak
belajar preferensi pengguna 'dari waktu ke waktu dan kemudian bertindak pada preferensi mereka. Misalnya, dalam
penggunaan teknologi tarik, agen cerdas akan mencari web untuk cerita yang menarik bagi pengguna,
setelah mengamati pola perilaku pengguna dengan informasi dari waktu ke waktu, dan akan melakukan
pencarian di Web tanpa terus-menerus mendorong dari pengguna.
Open Source Software
Sebuah alternatif untuk pengembangan perangkat lunak tradisional di mana kode berpemilik tersembunyi dari
pengguna disebut software open source (OSS). Dengan OSS, kode, atau instruksi komputer, dapat
belajar, berbagi, dan dimodifikasi oleh banyak pengguna dan programmer. Aturan komunitas ini meliputi
ide bahwa modifikasi program yang harus dibagi dengan semua orang di proyek.
Pengembangan OSS juga telah ditandai sebagai filsafat bukan hanya sebagai
Proses menciptakan software baru. Seringkali mereka yang terlibat dalam komunitas OSS melihatnya sebagai cara untuk
bantuan masyarakat berubah. Dikenal luas proyek open source termasuk Apache untuk mengembangkan Web
Server, browser disebut Mozilla Firefox, dan Linux, yang merupakan Unix-seperti operasi open source
sistem.
Namun, itu akan menjadi terlalu menyederhanakan untuk memikirkan OSS sebagai gerakan monolitik, dan
itu tidak sedikit untuk mengungkapkan apa jenis pengguna atau analis pengguna sedang mengembangkan proyek-proyek
OSS dan pada apa
dasar. Untuk membantu kita memahami gerakan open source, para peneliti baru-baru ini dikategorikan
komunitas open source menjadi empat jenis-ad hoc masyarakat, standar, terorganisir, dan commercialbersama enam berbeda dimensi-umum struktur, lingkungan, tujuan, metode, pengguna
masyarakat, dan perizinan. Beberapa peneliti berpendapat bahwa OSS adalah di persimpangan jalan dan komersial
dan kelompok masyarakat OSS perlu memahami di mana mereka berkumpul dan di mana potensi
konflik ada.
Pengembangan open source berguna untuk banyak aplikasi yang berjalan pada teknologi yang beragam,
termasuk perangkat genggam dan peralatan komunikasi. Penggunaannya dapat mendorong kemajuan dalam
menciptakan standar untuk perangkat untuk berkomunikasi dengan lebih mudah. Meluasnya penggunaan OSS dapat
meringankan
beberapa kekurangan parah programmer dengan menempatkan alat pemrograman di tangan
siswa di negara-negara berkembang lebih cepat daripada jika mereka terbatas untuk menggunakan paket proprietary,
dan dapat menyebabkan masalah besar melalui pemecahan kolaborasi intens dan luas.

PERLU UNTUK ANALISIS SISTEM DAN DESAIN

Analisis sistem dan desain, seperti yang dilakukan oleh sistem analis, berusaha untuk memahami apa yang manusia

perlu menganalisis masukan data atau aliran data secara sistematis, proses atau transformasi data, menyimpan data, dan
output
informasi dalam konteks organisasi tertentu atau perusahaan. Dengan melakukan analisis menyeluruh,
analis berusaha untuk mengidentifikasi dan memecahkan masalah yang tepat. Selanjutnya, analisis sistem dan desain
digunakan untuk menganalisis, merancang, dan mengimplementasikan perbaikan dalam dukungan pengguna dan fungsi
yang
bisnis yang dapat dicapai melalui penggunaan sistem informasi terkomputerisasi.
Menginstal sistem tanpa perencanaan yang tepat mengarah ke pengguna ketidakpuasan besar dan sering
menyebabkan sistem untuk jatuh ke dalam tidak digunakan. Analisis sistem dan desain meminjamkan struktur untuk analisis
dan desain sistem informasi, suatu usaha mahal yang dinyatakan mungkin telah dilakukan dalam
cara serampangan. Hal ini dapat dianggap sebagai serangkaian proses sistematis yang dilakukan untuk meningkatkan
bisnis melalui penggunaan sistem informasi terkomputerisasi. Analisis sistem dan desain melibatkan
bekerja dengan pengguna saat ini dan akhirnya sistem informasi untuk mendukung mereka dalam bekerja
dengan teknologi dalam pengaturan organisasi.
Keterlibatan pengguna di seluruh proyek sistem sangat penting untuk keberhasilan pengembangan
sistem informasi terkomputerisasi. Analis sistem, peran yang dalam organisasi dibahas
berikutnya, adalah komponen penting lainnya dalam mengembangkan sistem informasi yang berguna.
Pengguna bergerak ke permukaan sebagai tim pengembangan perangkat lunak menjadi lebih internasional
dalam komposisi mereka. Ini berarti bahwa ada lebih menekankan pada bekerja dengan pengguna perangkat lunak; pada
melakukan analisis bisnis mereka, masalah, dan tujuan; dan berkomunikasi analisis
dan desain sistem yang direncanakan untuk semua yang terlibat.
Teknologi baru juga sedang mengemudi kebutuhan untuk analisis sistem. Ajax (Asynchronous
JavaScript dan XML) bukan merupakan bahasa pemrograman baru, tetapi teknik yang menggunakan bahasa yang ada
untuk membuat halaman Web berfungsi lebih seperti program aplikasi desktop tradisional. Bangunan
dan mendesain ulang halaman Web yang memanfaatkan teknologi Ajax akan menjadi tugas yang dihadapi analis. Baru
bahasa pemrograman, seperti kerangka Web open source, Ruby on Rails, yang merupakan kombinasi
bahasa pemrograman dan generator kode untuk membuat aplikasi Web, akan memerlukan
analisis yang lebih.
PERAN DARI SISTEM ANALYST
Analis sistem sistematis menilai bagaimana pengguna berinteraksi dengan bisnis teknologi dan bagaimana
fungsi dengan memeriksa penginputan dan pengolahan data dan keluaran informasi dengan
maksud meningkatkan proses organisasi. Banyak perbaikan melibatkan dukungan yang lebih baik dari pengguna '
bekerja tugas dan fungsi bisnis melalui penggunaan sistem informasi terkomputerisasi. Definisi ini
menekankan sistematis, pendekatan metodis untuk menganalisis-dan berpotensi meningkatkan-apa
terjadi dalam konteks spesifik yang dialami oleh pengguna dan diciptakan oleh bisnis.
Definisi kita tentang seorang analis sistem adalah tentu luas. Analis harus mampu bekerja
dengan orang-orang dari semua deskripsi dan berpengalaman dalam bekerja dengan komputer. Drama analis
banyak peran, kadang-kadang menyeimbangkan beberapa pada saat yang sama. Tiga peran utama dari sistem
Analis yang konsultan, ahli mendukung, dan agen perubahan.
Sistem Analis sebagai Konsultan
Analis sistem sering bertindak sebagai konsultan sistem untuk manusia dan bisnis mereka dan,
dengan demikian, dapat disewa secara khusus untuk menangani masalah-masalah sistem informasi dalam bisnis. Perekrutan
seperti
dapat menjadi keuntungan karena konsultan luar dapat membawa dengan mereka perspektif yang segar yang
orang lain dalam sebuah organisasi tidak memiliki. Ini juga berarti bahwa analis luar dirugikan
karena orang luar tidak pernah dapat mengetahui budaya organisasi yang benar. Sebagai konsultan luar,
Anda akan sangat bergantung pada metode yang sistematis dibahas seluruh teks ini untuk menganalisis
dan sistem desain informasi yang tepat bagi pengguna yang bekerja di bisnis tertentu. Tambahan lagi,
Anda akan bergantung pada pengguna sistem informasi untuk membantu Anda memahami budaya organisasi
dari sudut pandang orang lain.
Sistem Analis sebagai Pendukung Ahli
Peran lain yang Anda mungkin diminta untuk bermain adalah bahwa mendukung ahli dalam bisnis untuk
yang Anda secara teratur digunakan dalam beberapa kapasitas sistem. Dalam peran ini analis mengacu pada profesional
keahlian mengenai perangkat keras komputer dan perangkat lunak dan menggunakan mereka dalam bisnis.

"Anda akan senang mengetahui bahwa kita membuat

kasus yang kuat untuk manajemen
bahwa kita harus menyewa analis sistem baru untuk
mengkhususkan diri dalam e-commerce
pengembangan, "kata Al Falfa, seorang analis sistem untuk
rantai internasional multioutlet dari Marathon Vitamin Toko.
Dia
pertemuan dengan tim besar nya sistem analis untuk
memutuskan kualifikasi
bahwa anggota tim mereka baru harus dimiliki. Al terus,
mengatakan, "Bahkan, mereka begitu gembira dengan
kemungkinan tim kami
membantu untuk memindahkan Marathon menjadi strategi
e-commerce yang mereka telah
mengatakan kita harus mulai pencarian kami sekarang dan
tidak menunggu sampai musim gugur. "
Jahe Rute, analis lain, setuju, mengatakan, "Permintaan
untuk
Pengembang situs web masih melebihi pasokan. Kita harus
bergerak
cepat. Saya pikir orang baru kami harus memiliki
pengetahuan dalam sistem
modeling, JavaScript, C, Rational Rose, dan akrab dengan
Ajax,
hanya untuk beberapa nama. "
Al terlihat terkejut melihat daftar panjang Ginger
keterampilan tapi kemudian
menjawab, "Yah, itu pasti salah satu cara kita bisa pergi.
Tapi saya akan
juga ingin melihat seseorang dengan beberapa cerdas
bisnis. Kebanyakan orang
keluar dari sekolah akan memiliki kemampuan
pemrograman yang solid, tetapi
mereka harus tahu tentang akuntansi, persediaan, dan
distribusi
barang dan jasa, juga. "
Anggota terbaru dari kelompok analisis sistem, Vita Ming,
akhirnya menerobos masuk ke dalam diskusi. Dia
mengatakan, "Salah satu alasan saya
memilih untuk datang untuk bekerja dengan kalian semua
adalah bahwa saya pikir kita semua harus
bersama cukup baik bersama-sama. Karena saya punya
beberapa peluang lain,
Aku melihat sangat hati-hati pada apa suasana di sini. Dari
apa
Aku pernah melihat, kami sekelompok ramah. Mari kita
pastikan untuk mempekerjakan seseorang yang
memiliki kepribadian yang baik dan yang cocok dengan
kita. "
Al sepakat, terus, "benar Vita. Orang baru harus
dapat berkomunikasi dengan baik dengan kami, dan
dengan klien bisnis, juga.
Kami selalu berkomunikasi dalam beberapa cara, melalui
presentasi formal,

menggambar diagram, atau mewawancarai pengguna. Jika

mereka memahami
pengambilan keputusan, hal itu akan membuat pekerjaan
mereka lebih mudah, juga. Juga, Marathon
tertarik mengintegrasikan e-commerce ke seluruh bisnis.
Kita
membutuhkan seseorang yang setidaknya menangkap
pentingnya strategis
Web. Desain halaman adalah suatu bagian kecil dari itu. "
Jahe menyela lagi dengan dosis yang sehat kepraktisan,
mengatakan,
"Tinggalkan itu untuk manajemen. Saya masih mengatakan
orang baru harus
menjadi programmer yang baik. "Lalu ia merenungkan
keras," Aku ingin tahu bagaimana
penting UML akan? "
Setelah mendengarkan dengan sabar ke daftar keinginan
semua orang, salah satu senior
analis, Cal Siem, berbicara up, bercanda, "Kami akan
melihat lebih baik jika Superman
tersedia!"
Sebagai kelompok saham tertawa, Al melihat kesempatan
untuk mencoba untuk
beberapa konsensus, mengatakan, "Kami punya
kesempatan untuk mendengar sejumlah
kualifikasi yang berbeda. Mari kita masing-masing
mengambil beberapa saat dan membuat daftar
dari kualifikasi kami pribadi berpikir sangat penting untuk
baru
pengembangan e-commerce untuk orang possess.We'll
berbagi dan
terus membahas sampai kita bisa menggambarkan orang
yang cukup detail
untuk mengubah deskripsi ke kelompok sumber daya
manusia untuk
pengolahan. "
Kualifikasi apa yang harus tim analisis sistem akan mencari
ketika menyewa anggota tim pengembangan e-commerce
baru mereka?
Apakah lebih penting untuk mengetahui bahasa tertentu
atau untuk memiliki
bakat untuk mengambil bahasa dan paket perangkat lunak
dengan cepat?
Seberapa penting bahwa orang yang dipekerjakan memiliki
beberapa dasar
pemahaman bisnis? Harus semua anggota tim memiliki
identik
kompetensi dan keterampilan? Apa kepribadian atau
karakter
yang diinginkan dalam analis sistem yang akan bekerja di
e-commerce
pembangunan?

Pekerjaan ini sering bukan proyek sistem full-blown, melainkan memerlukan sedikit modifikasi atau
keputusan yang mempengaruhi departemen tunggal.
Sebagai ahli pendukung, Anda tidak mengelola proyek; Anda hanya melayani sebagai sumber daya
bagi mereka yang. Jika Anda seorang analis sistem yang digunakan oleh manufaktur atau jasa
organisasi, banyak dari kegiatan sehari-hari Anda dapat dicakup oleh peran ini.
Sistem Analis sebagai Agen Perubahan
Peran yang paling komprehensif dan bertanggung jawab bahwa sistem analis mengambil adalah bahwa agen
perubahan, baik internal maupun eksternal untuk bisnis. Sebagai seorang analis, Anda adalah seorang agen perubahan
setiap kali Anda melakukan salah satu kegiatan dalam siklus hidup pengembangan sistem (dibahas dalam
bagian berikutnya) dan yang hadir dan berinteraksi dengan pengguna dan bisnis untuk jangka waktu yang diperpanjang
(dari dua minggu untuk lebih dari satu tahun). Agen perubahan dapat didefinisikan sebagai seseorang yang
berfungsi sebagai katalisator perubahan, mengembangkan rencana untuk perubahan, dan bekerja dengan orang lain dalam
memfasilitasi
perubahan itu.
Kehadiran Anda dalam bisnis perubahan itu. Sebagai analis sistem, Anda harus mengakui kenyataan ini
dan menggunakannya sebagai titik awal untuk analisis Anda. Oleh karena itu, Anda harus berinteraksi dengan pengguna dan
manajemen
(jika mereka tidak satu dan sama) dari awal proyek Anda. Tanpa mereka

membantu Anda tidak dapat memahami apa yang mereka butuhkan untuk mendukung pekerjaan mereka dalam organisasi,
dan real
perubahan tidak dapat berlangsung.
Jika perubahan (yaitu, perbaikan bisnis yang dapat diwujudkan melalui sistem informasi)
tampaknya dibenarkan setelah analisis, langkah berikutnya adalah untuk mengembangkan rencana untuk perubahan
bersama dengan
orang-orang yang harus memberlakukan perubahan. Setelah konsensus dicapai pada perubahan yang akan dibuat,
Anda harus terus-menerus berinteraksi dengan orang-orang yang berubah.
Sebagai analis sistem bertindak sebagai agen perubahan, Anda menganjurkan jalan tertentu perubahan
melibatkan penggunaan sistem informasi. Anda juga mengajarkan pengguna proses perubahan, karena
perubahan dalam sistem informasi tidak terjadi secara independen; bukan, mereka menyebabkan perubahan dalam
seluruh organisasi juga.
Kualitas dari Sistem Analis
Dari deskripsi di atas peran analis sistem memainkan, mudah untuk melihat bahwa
analis sistem yang sukses harus memiliki berbagai kualitas. Berbagai macam orang
adalah sistem analis, sehingga deskripsi ditakdirkan untuk jatuh pendek dalam beberapa cara. ada beberapa
kualitas, bagaimanapun, bahwa sebagian besar sistem analis tampaknya ditampilkan.
Di atas semua, analis adalah pemecah masalah. Dia adalah orang yang memandang analisis
masalah sebagai tantangan dan yang suka merancang solusi yang terbaik. Bila perlu, yang
Analis harus mampu sistematis mengatasi situasi di tangan melalui aplikasi terampil
alat, teknik, dan pengalaman. Analis juga harus menjadi komunikator yang mampu berhubungan
bermakna untuk orang lain selama jangka waktu yang panjang. Analis sistem harus
dapat memahami kebutuhan manusia 'dalam berinteraksi dengan teknologi, dan mereka cukup membutuhkan
pengalaman komputer program, untuk memahami kemampuan komputer, untuk mengumpulkan informasi
persyaratan dari pengguna, dan untuk berkomunikasi apa yang dibutuhkan untuk programmer. Mereka
juga perlu memiliki etika pribadi dan profesional yang kuat untuk membantu mereka membentuk klien mereka
hubungan.
Analis sistem harus menjadi motivasi diri, individu disiplin diri yang mampu mengelola
dan mengkoordinasikan orang lain, serta sumber daya yang tak terhitung banyaknya proyek. Analisis sistem adalah
menuntut karir, namun, kompensasi, satu yang selalu berubah dan selalu menantang.
SISTEM PEMBANGUNAN SIKLUS HIDUP
Sepanjang bab ini kita telah disebut pendekatan sistematis analis mengambil ke
analisis dan desain sistem informasi . Sebagian besar ini diwujudkan dalam apa yang disebut
siklus hidup pengembangan sistem ( SDLC ) . SDLC adalah pendekatan bertahap untuk analisis dan desain
yang memegang bahwa sistem terbaik yang dikembangkan melalui penggunaan siklus tertentu analis
dan kegiatan pengguna .
Analis tidak setuju pada persis berapa banyak fase ada dalam SDLC , tetapi mereka umumnya memuji
pendekatan terorganisir . Di sini kita telah membagi siklus menjadi tujuh tahapan , seperti yang ditunjukkan pada Gambar 1.3
.
Meskipun setiap fase disajikan discretely , itu tidak pernah dilakukan sebagai langkah terpisah . Sebagai gantinya,
beberapa kegiatan dapat terjadi secara bersamaan , dan kegiatan dapat diulang .

Memasukkan Pertimbangan Interaksi Manusia Komputer

Dalam beberapa tahun terakhir, studi tentang interaksi manusia-komputer (HCI) telah menjadi semakin penting
untuk sistem analis. Meskipun definisi yang masih berkembang, peneliti ciri HCI sebagai
yang "aspek komputer yang memungkinkan komunikasi dan interaksi antara manusia dan
komputer. Ini adalah lapisan dari komputer yang antara manusia dan komputer "(Zhang, Carey,
Te'eni, & Tremaine, 2005, hal. 518). Analis menggunakan pendekatan HCI yang menekankan orang lebih
dari pekerjaan yang harus dilakukan atau IT yang terlibat. Pendekatan mereka untuk masalah adalah multifaset,
melihat "manusia ergonomis, kognitif, afektif, dan faktor perilaku yang terlibat dalam pengguna
tugas, pemecahan masalah proses dan konteks interaksi "(Zhang, Carey, Te'eni, & Tremaine,
2005, p. 518). Interaksi manusia komputer bergerak menjauh dari fokus pertama pada organisasi dan
sistem kebutuhan dan bukannya berkonsentrasi pada kebutuhan manusia. Analis mengadopsi prinsip-prinsip HCI memeriksa
berbagai kebutuhan pengguna dalam konteks manusia berinteraksi dengan teknologi informasi untuk
menyelesaikan tugas dan memecahkan masalah. Ini termasuk memperhitungkan faktor-faktor fisik atau ergonomis;
faktor kegunaan yang sering dicap hal kognitif; yang menyenangkan, estetika, dan menyenangkan
aspek menggunakan sistem; dan aspek perilaku yang berpusat pada kegunaan dari sistem.
Cara lain untuk berpikir tentang HCI adalah untuk menganggapnya sebagai sebuah pendekatan yang berpusat manusia yang
menempatkan orang
menjelang struktur atau budaya organisasi saat membuat sistem baru. Ketika analis mempekerjakan
HCI sebagai lensa untuk menyaring dunia, pekerjaan mereka akan memiliki kualitas yang berbeda dari pekerjaan
mereka yang tidak memiliki perspektif ini.
Karir Anda bisa mendapatkan keuntungan dari landasan yang kuat dalam HCI. Permintaan untuk analis yang
mampu menggabungkan HCI ke dalam proses pengembangan sistem terus meningkat, sebagai perusahaan
semakin menyadari bahwa kualitas sistem dan kualitas kehidupan kerja dapat ditingkatkan baik
dengan mengambil pendekatan yang berpusat manusia pada awal proyek.
Penerapan prinsip-prinsip interaksi manusia-komputer mencoba untuk mengungkap dan mengatasi frustrasi
suara pengguna lebih penggunaan teknologi informasi. Keprihatinan ini termasuk kecurigaan
bahwa sistem analis salah paham pekerjaan yang dilakukan, tugas yang terlibat, dan bagaimana mereka dapat
terbaik didukung; perasaan tidak berdaya atau kurangnya kontrol ketika bekerja dengan sistem; disengaja
pelanggaran privasi; kesulitan menavigasi melalui layar sistem dan menu; dan ketidakcocokan umum
antara sistem yang dirancang dan pengguna jalan sendiri memikirkan proses kerja mereka.

Misjudgments dan kesalahan dalam desain yang menyebabkan pengguna untuk mengabaikan sistem baru atau yang
menyebabkan sistem
jatuh ke dalam tidak digunakan segera setelah pelaksanaannya dapat diberantas atau diminimalkan ketika sistem
analis mengadopsi pendekatan HCI.
Para peneliti di HCI melihat keuntungan untuk masuknya HCI dalam setiap fase dari SDLC. Ini
adalah pendekatan berharga, dan kami akan mencoba untuk cermin ini dengan membawa keprihatinan manusia secara
eksplisit dalam
setiap fase dari SDLC. Sebagai orang yang belajar analisis sistem, Anda juga dapat membawa segar
mata untuk SDLC untuk mengidentifikasi peluang bagi desainer untuk mengatasi masalah HCI dan cara bagi pengguna
untuk menjadi lebih sentral untuk setiap fase dari SDLC. Bab 14 dikhususkan untuk meneliti peran
analis sistem dalam merancang sistem yang berpusat manusia dan interface dari perspektif HCI.
Mengidentifikasi Masalah, Peluang, dan Tujuan
Pada tahap pertama ini dari siklus hidup pengembangan sistem, analis yang bersangkutan dengan benar
mengidentifikasi masalah, peluang, dan tujuan. Tahap ini sangat penting untuk keberhasilan sisanya
proyek, karena tidak ada yang mau buang waktu berikutnya mengatasi masalah yang salah.
Tahap pertama mengharuskan analis melihat secara jujur apa yang terjadi dalam bisnis.
Kemudian, bersama-sama dengan anggota organisasi lainnya, analis titik-titik masalah. Seringkali orang lain
akan memunculkan masalah ini, dan mereka adalah alasan analis awalnya dipanggil. Peluang
adalah situasi yang analis percaya dapat ditingkatkan melalui penggunaan informasi terkomputerisasi
sistem. Memanfaatkan peluang memungkinkan bisnis untuk mendapatkan keunggulan kompetitif atau
menetapkan standar industri.
Mengidentifikasi tujuan juga merupakan komponen penting dari tahap pertama. Analis harus
pertama menemukan apa bisnis coba lakukan. Kemudian analis akan dapat melihat apakah beberapa
aspek aplikasi sistem informasi dapat membantu bisnis mencapai tujuannya dengan mengatasi
masalah tertentu atau peluang.
Orang yang terlibat dalam tahap pertama adalah pengguna, analis, dan sistem manajer mengkoordinasikan
proyek. Kegiatan dalam tahap ini terdiri dari wawancara manajemen pengguna, meringkas
pengetahuan yang diperoleh, memperkirakan lingkup proyek, dan mendokumentasikan hasil. Output
dari tahap ini adalah laporan kelayakan yang berisi definisi masalah dan meringkas tujuan.
Manajemen kemudian harus membuat keputusan tentang apakah akan melanjutkan dengan proyek yang diusulkan. Jika
pengguna
kelompok tidak memiliki dana yang cukup dalam anggaran atau ingin mengatasi masalah yang tidak terkait, atau jika
masalah tidak memerlukan sistem komputer, solusi yang berbeda dapat direkomendasikan, dan sistem
proyek tidak melanjutkan lebih jauh.
Menentukan Informasi Persyaratan Manusia
Tahap berikutnya analis memasuki adalah bahwa penentuan kebutuhan manusia dari pengguna yang terlibat, menggunakan
berbagai alat untuk memahami bagaimana pengguna berinteraksi dalam konteks pekerjaan dengan informasi mereka saat ini
sistem. Analis akan menggunakan metode interaktif seperti wawancara, sampling dan menyelidiki
data keras, dan kuesioner, bersama dengan metode mengganggu, seperti mengamati pengambil keputusan '
perilaku dan lingkungan kantor mereka, dan metode yang mencakup segala, seperti prototyping.
Analis akan menggunakan metode ini untuk berpose dan menjawab banyak pertanyaan mengenai humancomputer
Interaksi (HCI), termasuk pertanyaan seperti, "Apa kekuatan fisik pengguna
dan keterbatasan? "Dengan kata lain," Apa yang perlu dilakukan untuk membuat sistem terdengar, terbaca,
dan aman? "" Bagaimana bisa sistem baru dirancang untuk mudah digunakan, belajar, dan ingat? "" Bagaimana
dapat sistem dibuat menyenangkan atau bahkan menyenangkan untuk digunakan? "" Bagaimana bisa sistem mendukung
individu pengguna
bekerja tugas dan membuat mereka lebih produktif dalam cara-cara baru? "
Dalam persyaratan informasi fase SDLC, analis berusaha untuk memahami apa
pengguna informasi perlu melakukan pekerjaan mereka. Pada titik ini analis sedang memeriksa bagaimana membuat
sistem yang berguna untuk orang-orang yang terlibat. Bagaimana sistem yang lebih baik dapat mendukung tugas individu
yang
perlu lakukan? Apa tugas-tugas baru yang diaktifkan oleh sistem baru yang pengguna tidak dapat melakukan tanpa
saya t? Bagaimana sistem baru yang akan dibuat untuk memperluas kemampuan pengguna di luar apa sistem lama
tersedia? Bagaimana analis menciptakan sistem yang menguntungkan bagi pekerja untuk digunakan?
Orang yang terlibat dalam fase ini adalah analis dan pengguna, biasanya manajer operasi
dan pekerja operasi. Analis sistem perlu mengetahui rincian fungsi sistem saat ini:
yang yang (orang-orang yang terlibat), apa (kegiatan usaha), di mana (lingkungan
di mana pekerjaan berlangsung), ketika (waktunya), dan bagaimana (bagaimana prosedur saat ini
dilakukan) bisnis yang diteliti. Analis maka harus bertanya mengapa bisnis menggunakan arus
sistem. Mungkin ada alasan yang baik untuk melakukan bisnis dengan menggunakan metode saat ini, dan ini
harus dipertimbangkan ketika merancang sistem baru.
Agile pembangunan adalah pendekatan berorientasi objek (OOA) untuk pengembangan sistem yang mencakup
metode pengembangan (termasuk menghasilkan kebutuhan informasi) serta perangkat lunak
alat. Dalam teks ini dipasangkan dengan prototyping di Bab 6. (Ada lebih lanjut tentang
pendekatan berorientasi objek dalam Bab 10.)
Jika alasan untuk operasi saat ini adalah bahwa "itu selalu dilakukan dengan cara itu," Namun, analis
mungkin ingin memperbaiki prosedur. Pada penyelesaian tahap ini, analis harus
memahami bagaimana pengguna menyelesaikan pekerjaan mereka saat berinteraksi dengan komputer dan mulai
mengetahui
bagaimana membuat sistem baru yang lebih berguna dan bermanfaat. Analis juga harus tahu bagaimana bisnis
fungsi dan memiliki informasi lengkap tentang orang-orang, tujuan, data, dan prosedur yang terlibat.
Menganalisis Kebutuhan Sistem
Tahap berikutnya bahwa analis sistem melakukan melibatkan kebutuhan sistem analisis. Sekali lagi, khusus
alat dan teknik membantu analis membuat penentuan kebutuhan. Alat seperti data
diagram alir (DFD) untuk memetakan input, proses, dan output dari fungsi bisnis, atau kegiatan
diagram atau diagram urutan untuk menunjukkan urutan kejadian, menggambarkan sistem secara terstruktur,
bentuk grafik. Dari aliran data, urutan, atau diagram lainnya, kamus data dikembangkan

yang berisi daftar semua item data yang digunakan dalam sistem, serta spesifikasi mereka.
Selama fase ini analis sistem juga menganalisis keputusan terstruktur dibuat. Tersusun
keputusan adalah mereka yang kondisi, alternatif kondisi, tindakan, dan tindakan
aturan dapat ditentukan. Ada tiga metode utama untuk analisis keputusan terstruktur:
terstruktur bahasa Inggris, tabel keputusan, dan pohon keputusan.
Pada titik ini dalam SDLC, analis sistem mempersiapkan proposal sistem yang merangkum
apa yang telah mengetahui tentang pengguna, kegunaan, dan kegunaan dari sistem saat ini; menyediakan
analisis biaya-manfaat alternatif; dan membuat rekomendasi tentang apa (jika ada) harus
dilakukan. Jika salah satu dari rekomendasi diterima untuk manajemen, analis hasil bersama
yang tentu saja. Setiap masalah sistem adalah unik, dan tidak pernah ada hanya satu solusi yang tepat. The
cara di mana rekomendasi atau solusi dirumuskan tergantung pada kualitas individu
dan pelatihan profesional masing-masing analis dan interaksi analis dengan pengguna dalam konteks
lingkungan kerja mereka.
Merancang Sistem Direkomendasikan
Pada tahap desain SDLC, analis sistem menggunakan informasi yang dikumpulkan sebelumnya untuk mencapai
desain logis dari sistem informasi. Analis desain prosedur untuk pengguna
untuk membantu mereka secara akurat memasukkan data sehingga data akan masuk ke sistem informasi yang benar. Di
Selain itu, analis menyediakan bagi pengguna untuk menyelesaikan masukan efektif untuk sistem informasi dengan
menggunakan teknik bentuk yang baik dan halaman Web atau desain layar.
Bagian dari desain logis dari sistem informasi menyusun HCI. The menghubungkan antarmuka
pengguna dengan sistem dan dengan demikian sangat penting. User interface dirancang dengan
bantuan pengguna untuk memastikan bahwa sistem ini terdengar, terbaca, dan aman, serta menarik
dan menyenangkan untuk digunakan. Contoh user interface fisik meliputi keyboard (mengetik pertanyaan
dan jawaban), menu pada layar (untuk memperoleh perintah pengguna), dan berbagai antarmuka pengguna grafis
(GUI) yang menggunakan layar sentuh mouse atau.
Tahap desain juga termasuk database merancang yang akan menyimpan banyak data yang dibutuhkan
oleh pengambil keputusan dalam organisasi. Pengguna manfaat dari database terorganisir dengan baik yang logis
kepada mereka dan sesuai dengan cara mereka melihat pekerjaan mereka. Dalam fase ini analis juga bekerja
dengan pengguna untuk merancang keluaran (baik layar atau dicetak) yang memenuhi kebutuhan informasi mereka.
Akhirnya, analis harus merancang kontrol dan prosedur cadangan untuk melindungi sistem dan
data, dan untuk menghasilkan paket spesifikasi program untuk programmer. Setiap paket harus mengandung
input dan output layout, spesifikasi berkas, dan rincian pengolahan; mungkin juga termasuk keputusan
pohon atau tabel, UML atau aliran data diagram, dan nama-nama dan fungsi dari kode prewritten
yang baik ditulis di-rumah atau menggunakan kode atau perpustakaan kelas lainnya.
Mengembangkan dan Mendokumentasikan Software
Pada tahap kelima dari SDLC, analis bekerja dengan programmer untuk mengembangkan perangkat lunak asli
yang dibutuhkan. Selama fase ini analis bekerja dengan pengguna untuk mengembangkan dokumentasi yang efektif untuk
software, termasuk manual prosedur, bantuan online, dan situs web yang menampilkan Pertanyaan yang Sering Diajukan
(FAQ), pada Read Me file dikirimkan dengan software baru. Karena pengguna yang terlibat dari awal,
dokumentasi fase harus menjawab pertanyaan-pertanyaan mereka telah mengangkat dan dipecahkan bersama-sama dengan
analis. Dokumentasi memberitahu pengguna bagaimana menggunakan perangkat lunak dan apa yang harus dilakukan jika
masalah perangkat lunak terjadi.
Programmer memiliki peran penting dalam fase ini karena mereka merancang, kode, dan menghapus sintaksis
kesalahan dari program komputer. Untuk memastikan kualitas, programmer dapat melakukan baik desain atau
walkthrough kode, menjelaskan bagian-bagian yang kompleks dari program untuk tim programmer lain.
Pengujian dan Mempertahankan Sistem
Sebelum sistem informasi dapat digunakan, harus diuji. Hal ini jauh lebih murah untuk menangkap masalah
sebelum sistem ditandatangani ke pengguna. Beberapa pengujian selesai oleh programmer
saja, beberapa di antaranya oleh analis sistem dalam hubungannya dengan programmer. Serangkaian tes untuk menentukan
masalah dijalankan pertama dengan data sampel dan akhirnya dengan data aktual dari sistem saat ini.
Seringkali rencana uji dibuat di awal SDLC dan diperhalus sebagai proyek berlangsung.
Pemeliharaan sistem dan dokumentasinya dimulai pada fase ini dan dilakukan secara rutin
sepanjang hidup sistem informasi. Banyak dari pekerjaan rutin programmer terdiri
pemeliharaan, dan bisnis menghabiskan banyak uang pada pemeliharaan. Beberapa
pemeliharaan, seperti update program, dapat dilakukan secara otomatis melalui situs penjual di Web.
Banyak prosedur yang sistematis analis mempekerjakan seluruh SDLC dapat membantu memastikan
pemeliharaan yang disimpan ke minimum.
Menerapkan dan Mengevaluasi Sistem
Pada fase ini terakhir pengembangan sistem, analis membantu mengimplementasikan sistem informasi. Ini
Fase melibatkan pengguna pelatihan untuk menangani sistem. Vendor melakukan beberapa pelatihan, tetapi pengawasan
pelatihan
adalah tanggung jawab analis sistem. Selain itu, analis perlu untuk merencanakan konversi halus
dari sistem lama ke yang baru. Proses ini meliputi mengkonversi file dari format lama ke
yang baru, atau membangun database, memasang peralatan, dan membawa sistem baru ke dalam produksi.

Cerita: Di rumah dan di kunjungan kami ke kampus-kampus universitas dan bisnis di seluruh dunia, kami telah
memperhatikan bahwa
mahasiswa dan organisasi semakin menunjukkan minat pada Mac. Oleh karena itu, kami pikir itu
akan menambahkan sedikit minat untuk menampilkan beberapa pilihan Mac yang seorang desainer sistem memiliki. Pada
saat itu

kita menulis buku ini, sekitar satu dari tujuh komputer pribadi dibeli di Amerika Serikat adalah
Mac. Mac adalah mesin berbasis Intel kualitas yang berjalan di bawah sistem operasi yang kompeten dan dapat
juga menjalankan Windows, sehingga dalam efek segala sesuatu yang bisa dilakukan pada PC dapat dilakukan pada Mac.
Satu arah
untuk menjalankan Windows adalah untuk boot langsung ke Windows (setelah itu diinstal); lain adalah dengan menggunakan
virtualisasi
menggunakan perangkat lunak seperti VM Fusion, yang ditunjukkan pada Gambar 1.MAC.
Pengadopsi dari Mac telah dikutip banyak alasan untuk menggunakan Mac termasuk keamanan yang lebih baik dibangun ke
sistem operasi Mac, cadangan cerdas menggunakan built-in mesin waktu, banyak aplikasi
sudah termasuk, keandalan setup dan jaringan, dan kemampuan untuk melakukan sinkronisasi Mac dengan
Mac dan iPhone lainnya. Alasan yang paling menarik, kita berpikir, adalah desain itu sendiri.
Evaluasi disertakan sebagai bagian dari tahap akhir ini SDLC sebagian besar untuk kepentingan diskusi.
Sebenarnya, evaluasi berlangsung selama setiap fase. Kriteria Akey yang harus puas adalah
apakah pengguna dimaksudkan memang menggunakan sistem.
Perlu dicatat bahwa sistem kerja sering siklus. Ketika seorang analis selesai satu fase
sistem pembangunan dan hasil ke berikutnya, penemuan masalah mungkin memaksa analis
untuk kembali ke fase sebelumnya dan memodifikasi pekerjaan yang dilakukan di sana.
Dampak Pemeliharaan
Setelah sistem terinstal, harus dipertahankan, yang berarti bahwa program komputer harus
dimodifikasi dan terus up to date. Gambar 1.4 menggambarkan jumlah rata-rata waktu yang digunakan untuk pemeliharaan
di instalasi MIS khas. Perkiraan waktu yang dihabiskan oleh departemen pemeliharaan
telah berkisar 48-60 persen dari total waktu yang dihabiskan mengembangkan sistem. Waktu yang sangat sedikit sisa-sisa
untuk pengembangan sistem baru. Karena jumlah program yang ditulis meningkat, demikian juga
jumlah perawatan yang mereka butuhkan.
Pemeliharaan dilakukan karena dua alasan. Yang pertama adalah untuk memperbaiki kesalahan software. Tidak
peduli seberapa menyeluruh sistem diuji, bug atau kesalahan merayap ke dalam program komputer. Bugs

dalam perangkat lunak PC komersial sering didokumentasikan sebagai "anomali dikenal," dan dikoreksi saat
versi baru dari perangkat lunak yang dirilis atau dalam rilis interim. Dalam perangkat lunak kustom (juga disebut
software dipesan lebih dahulu), bug harus diperbaiki seperti yang terdeteksi.
Alasan lain untuk melakukan pemeliharaan sistem adalah untuk meningkatkan kemampuan perangkat lunak
dalam menanggapi perubahan kebutuhan organisasi, umumnya melibatkan salah satu dari tiga berikut
situasi:
1. Pengguna sering meminta fitur tambahan setelah mereka menjadi akrab dengan komputer
sistem dan kemampuannya.
2. Pengelola berubah dari waktu ke waktu.
3. Hardware dan software berubah dengan kecepatan dipercepat.
Gambar 1.5 menggambarkan jumlah sumber daya-biasanya waktu dan uang yang dihabiskan untuk sistempengembangan dan pemeliharaan. Daerah di bawah kurva mewakili jumlah total dolar yang dihabiskan.
Anda dapat melihat bahwa dari waktu ke waktu total biaya pemeliharaan kemungkinan akan melebihi dari pengembangan
sistem.
Pada titik tertentu menjadi lebih layak untuk melakukan studi sistem baru, karena
Biaya pemeliharaan terus jelas lebih besar dari menciptakan informasi yang sama sekali baru
sistem.
Singkatnya, pemeliharaan adalah proses yang berkelanjutan selama siklus hidup dari suatu sistem informasi.
Setelah sistem informasi dipasang, pemeliharaan biasanya mengambil bentuk mengoreksi sebelumnya
kesalahan program tidak terdeteksi. Setelah ini diperbaiki, sistem pendekatan mantap
negara, menyediakan layanan diandalkan untuk para penggunanya. Pemeliharaan selama periode ini dapat terdiri dari
menghapus
beberapa bug terdeteksi sebelumnya dan memperbarui sistem dengan tambahan beberapa minor.
Dengan berjalannya waktu dan perubahan bisnis dan teknologi, namun, upaya pemeliharaan
meningkatkan secara dramatis.

MENGGUNAKAN ALAT KASUS

Analis yang mengadopsi pendekatan SDLC sering mendapatkan keuntungan dari perangkat produktivitas, disebut ComputerAided Software Engineering (CASE) tools, yang telah dibuat secara eksplisit untuk meningkatkan rutinitas mereka
bekerja melalui penggunaan dukungan otomatis. Analis mengandalkan alat CASE untuk meningkatkan
produktivitas, berkomunikasi dengan lebih efektif dengan pengguna, dan mengintegrasikan pekerjaan yang mereka lakukan
pada
sistem dari awal sampai akhir siklus hidup.
Analis terlihat (VA) adalah salah satu contoh dari alat CASE yang memungkinkan sistem analis untuk melakukan
perencanaan grafis, analisis, dan desain untuk membangun aplikasi client / server yang kompleks dan
database. Analis terlihat dan produk perangkat lunak lain yang disebut Microsoft Visio memungkinkan pengguna untuk
menggambar dan memodifikasi diagram dengan mudah.
Analis dan pengguna sama melaporkan bahwa alat CASE membelinya sarana komunikasi
tentang sistem selama konseptualisasi nya. Melalui penggunaan dukungan otomatis menampilkan
Output layar, klien dapat dengan mudah melihat bagaimana arus data dan konsep sistem lainnya digambarkan,
dan mereka kemudian dapat meminta koreksi atau perubahan yang akan mengambil terlalu banyak waktu dengan
alat yang lebih tua.
Beberapa analis membedakan antara alat CASE atas dan bawah. Sebuah alat KASUS atas memungkinkan
analis untuk membuat dan memodifikasi desain sistem. Semua informasi tentang proyek ini
disimpan dalam sebuah ensiklopedia yang disebut repositori KASUS, koleksi besar catatan, elemen, diagram,
layar, laporan, dan informasi lainnya (lihat Gambar 1.6). Laporan analisis dapat dihasilkan
menggunakan informasi repositori untuk menunjukkan di mana desain tidak lengkap atau mengandung kesalahan.
CASE tools atas juga dapat membantu mendukung pemodelan kebutuhan fungsional organisasi,
membantu analis dan pengguna dalam menggambar batas-batas untuk proyek tertentu, dan membantu mereka
memvisualisasikan
bagaimana proyek jerat dengan bagian lain dari organisasi.
CASE tools yang lebih rendah digunakan untuk menghasilkan kode sumber komputer, menghilangkan kebutuhan untuk
pemrograman
sistem. Pembuatan kode memiliki beberapa keunggulan: (1) sistem dapat diproduksi
lebih cepat daripada dengan menulis program komputer; (2) jumlah waktu yang digunakan untuk perawatan
menurun dengan kode generasi; (3) kode dapat dihasilkan dalam lebih dari satu bahasa komputer,
sehingga lebih mudah untuk bermigrasi sistem dari satu platform yang lain; (4) pembuatan kode menyediakan
cara yang efektif dari sistem dibeli dari vendor pihak ketiga untuk kebutuhan organisasi menjahit;
dan (5) menghasilkan kode bebas dari kesalahan program komputer.
THE Agile PENDEKATAN
Meskipun teks ini cenderung berfokus pada SDLC, pendekatan yang paling banyak digunakan dalam praktek, di kali
analis akan mengakui bahwa organisasi dapat memperoleh manfaat dari pendekatan alternatif. Mungkin
proyek sistem yang menggunakan pendekatan terstruktur baru-baru ini gagal, atau mungkin organisasi
subkultur, terdiri dari beberapa kelompok pengguna yang berbeda, tampak lebih pada langkah dengan
metode alternatif. Kita tidak bisa melakukan keadilan untuk metode ini dalam ruang kecil; masing-masing layak dan memiliki
terinspirasi buku dan penelitian sendiri. Dengan menyebutkan pendekatan ini di sini, namun, kami berharap untuk
membantu Anda menyadari bahwa dalam keadaan tertentu, organisasi Anda mungkin ingin mempertimbangkan
alternatif atau suplemen untuk analisis terstruktur dan desain dan SDLC.
Pendekatan tangkas pendekatan pengembangan perangkat lunak berdasarkan nilai-nilai, prinsip, dan inti
praktek. Keempat nilai-nilai komunikasi, kesederhanaan, umpan balik, dan keberanian. Kami merekomendasikan
bahwa sistem analis mengadopsi nilai-nilai ini di semua proyek mereka melakukan, tidak hanya ketika mengadopsi
Pendekatan tangkas.
Dalam rangka untuk menyelesaikan sebuah proyek, penyesuaian sering perlu dibuat dalam manajemen proyek. Di
Bab 6 kita akan melihat bahwa metode tangkas dapat memastikan berhasil menyelesaikan proyek dengan menyesuaikan
sumber daya penting waktu, biaya, kualitas, dan ruang lingkup. Ketika empat variabel kontrol ini
yang benar termasuk dalam perencanaan, ada keadaan keseimbangan antara sumber daya dan kegiatan
dibutuhkan untuk menyelesaikan proyek.
Mengambil praktek-praktek pembangunan yang ekstrim adalah yang paling terlihat ketika salah satu mengejar praktek
yang unik untuk pengembangan tangkas. Dalam Bab 6 kita membahas praktek tangkas empat inti: rilis singkat,
40 jam kerja seminggu, tuan pelanggan onsite, dan menggunakan pemrograman pasangan. Awalnya
Sekilas praktek ini muncul ekstrim, tetapi karena Anda akan melihat, kita dapat belajar beberapa pelajaran penting
dari menggabungkan banyak nilai-nilai dan praktik dari pendekatan tangkas dalam analisis sistem
dan proyek desain.

Proses perkembangan untuk Proyek Agile

Ada kegiatan dan perilaku yang membentuk anggota tim pengembangan cara dan pelanggan
bertindak selama pengembangan proyek tangkas. Dua kata yang menjadi ciri proyek dilakukan dengan
pendekatan tangkas yang interaktif dan incremental. Dengan memeriksa Gambar 1.7 kita dapat melihat bahwa ada
lima tahap yang berbeda: eksplorasi, perencanaan, iterasi untuk rilis pertama, productionizing, dan
pemeliharaan. Perhatikan bahwa tiga anak panah merah yang loop kembali ke dalam "Iterasi" kotak melambangkan

perubahan tambahan diciptakan melalui pengujian berulang dan umpan balik yang akhirnya menyebabkan stabil
tetapi sistem berkembang. Juga mencatat bahwa ada beberapa perulangan panah yang memberi makan kembali ke
fase productionizing. Ini melambangkan bahwa laju iterasi meningkat setelah sebuah produk
dirilis. Panah merah ditampilkan meninggalkan tahap pemeliharaan dan kembali ke perencanaan
panggung, sehingga ada umpan balik terus menerus yang melibatkan pelanggan dan tim pengembangan
karena mereka setuju untuk mengubah sistem berkembang.
EKSPLORASI. Selama eksplorasi, Anda akan menjelajahi lingkungan Anda, menegaskan keyakinan Anda
bahwa masalah dapat dan harus didekati dengan pengembangan tangkas, merakit tim, dan
menilai tim keterampilan anggota. Tahap ini akan mengambil tempat dari beberapa minggu (jika Anda sudah tahu
anggota tim Anda dan teknologi) untuk beberapa bulan (jika semuanya baru). Anda juga akan
aktif meneliti teknologi potensial yang dibutuhkan untuk membangun sistem baru. Selama tahap ini Anda
harus berlatih memperkirakan waktu yang diperlukan untuk berbagai tugas. Dalam eksplorasi, pelanggan juga
bereksperimen dengan menulis cerita pengguna. Intinya adalah untuk mendapatkan pelanggan untuk memperbaiki sebuah
cerita
cukup sehingga Anda kompeten dapat memperkirakan jumlah waktu yang diperlukan untuk membangun solusi
ke dalam sistem Anda berencana. Tahap ini adalah semua tentang mengadopsi sikap main-main dan ingin tahu
terhadap lingkungan kerja, masalah, teknologi, dan orang-orang.
PERENCANAAN. Tahap selanjutnya dari proses pembangunan tangkas disebut perencanaan. Berbeda dengan
Tahap pertama, perencanaan hanya dapat memakan waktu beberapa hari untuk menyelesaikan. Pada tahap ini Anda dan
pelanggan Anda
setuju berkencan mana saja dari dua bulan untuk setengah tahun dari tanggal saat ini untuk memberikan solusi
untuk masalah bisnis mereka yang paling mendesak (Anda akan menangani terkecil, set yang paling berharga
cerita). Jika kegiatan eksplorasi Anda sudah cukup, tahap ini harus sangat singkat.
Seluruh proses perencanaan tangkas telah ditandai menggunakan ide permainan perencanaan
sebagai dirancang oleh Beck. Perencanaan pertandingan menguraikan aturan yang dapat membantu merumuskan
pembangunan tangkas
hubungan tim dengan pelanggan bisnis mereka. Meskipun aturan membentuk gambaran bagaimana
Anda ingin masing-masing pihak untuk bertindak selama pengembangan, mereka tidak dimaksudkan sebagai pengganti
hubungan.
Mereka adalah dasar untuk membangun dan memelihara hubungan.
Jadi, kita menggunakan metafora permainan. Untuk itu kita berbicara dalam hal tujuan permainan,
strategi untuk mengejar, potongan untuk bergerak, dan para pemain yang terlibat. Tujuan dari permainan ini adalah untuk
memaksimalkan
nilai dari sistem yang dihasilkan oleh tim tangkas. Dalam rangka untuk mencari nilai, Anda memiliki
untuk mengurangi biaya pengembangan, dan waktu, biaya, dan ketidakpastian diambil pada sehingga pembangunan
proyek bisa maju.
Strategi yang ditempuh oleh tim pengembangan tangkas adalah selalu salah satu ketidakpastian membatasi
(mengecilkan risiko). Untuk melakukan itu mereka merancang solusi yang paling sederhana mungkin, menempatkan sistem
ke dalam produksi
sesegera mungkin, mendapatkan umpan balik dari pelanggan bisnis tentang apa yang bekerja, dan
beradaptasi desain mereka dari sana.
Kartu cerita menjadi potongan-potongan dalam permainan perencanaan yang menjelaskan secara singkat tugas,
memberikan
catatan, dan menyediakan area untuk pelacakan tugas.
Ada dua pemain utama di game perencanaan: tim pengembangan dan pelanggan bisnis.
Memutuskan kelompok usaha khususnya akan menjadi pelanggan bisnis tidak selalu
memutuskan apa tim pengembangan harus mengatasi pertama. Keputusan mereka akan menetapkan prioritas dan periksa
fungsi seluruh proses.
Iterasi untuk PERTAMA RELEASE. Tahap ketiga dalam proses pembangunan tangkas terdiri
iterasi untuk rilis pertama. Biasanya ini iterasi (siklus pengujian, umpan balik, dan
mengubah) dari sekitar tiga minggu di durasi. Anda akan mendorong diri Anda untuk membuat sketsa seluruh yang
arsitektur sistem, meskipun hanya dalam garis atau bentuk tulang. Salah satu tujuannya adalah untuk menjalankan
pelanggan-tes tertulis fungsional pada akhir setiap iterasi. Selama iterasi tahap Anda
juga harus mempertanyakan apakah jadwal tersebut perlu diubah atau apakah Anda menangani terlalu
banyak cerita. Membuat ritual kecil dari setiap iterasi sukses, yang melibatkan pelanggan serta
pengembang. Selalu merayakan kemajuan Anda, bahkan jika itu kecil, karena ini adalah bagian dari budaya
memotivasi setiap orang untuk bekerja sangat keras pada proyek.
PRODUCTIONIZING. Beberapa kegiatan terjadi selama fase ini. Pada fase ini siklus umpan balik
mempercepat sehingga daripada menerima umpan untuk iterasi setiap tiga minggu, software
revisi sedang berbalik dalam satu minggu. Anda mungkin lembaga briefing harian sehingga semua orang
tahu apa yang orang lain lakukan. Produk ini dirilis pada fase ini, tapi mungkin ditingkatkan
dengan menambahkan fitur-fitur lainnya. Mendapatkan sistem ke dalam produksi merupakan acara yang menarik. Membuat
waktu untuk
merayakan dengan rekan tim Anda dan menandai kesempatan itu. Salah satu semboyan dari tangkas
Pendekatan, yang kita sungguh-sungguh setuju, adalah bahwa hal itu seharusnya menyenangkan untuk mengembangkan
sistem!
MAINTENANCE. Setelah sistem telah dirilis, perlu terus berjalan lancar. Baru
fitur dapat ditambahkan, saran pelanggan berisiko dapat dipertimbangkan, dan anggota tim mungkin
diputar atau menonaktifkan tim. Sikap Anda mengambil pada saat ini dalam proses perkembangan adalah
lebih konservatif dari pada waktu lainnya. Anda sekarang dalam "penjaga api" mode bukan
dari yang lucu yang Anda alami selama eksplorasi.

ANALISIS BERORIENTASI OBJEK DAN SISTEM DESAIN

(OO) analisis dan desain berorientasi objek adalah sebuah pendekatan yang dimaksudkan untuk memfasilitasi
pengembangan
sistem yang harus berubah dengan cepat dalam menanggapi lingkungan bisnis yang dinamis.
Bab 10 akan membantu Anda memahami apa yang berorientasi objek analisis sistem dan desain, bagaimana hal itu berbeda
dari pendekatan terstruktur dari SDLC, dan ketika itu mungkin tepat untuk menggunakan objectoriented
Pendekatan.
Teknik berorientasi objek yang diduga bekerja dengan baik dalam situasi di mana informasi yang rumit
sistem sedang menjalani perawatan terus menerus, adaptasi, dan desain ulang. Berorientasi pada objek
Pendekatan menggunakan standar industri untuk pemodelan sistem berorientasi objek, yang disebut
bahasa pemodelan terpadu (UML), untuk memecah sistem menjadi model use case.
Pemrograman berorientasi objek berbeda dari pemrograman prosedural tradisional dengan memeriksa
benda yang merupakan bagian dari sistem. Setiap objek adalah representasi komputer dari beberapa hal yang sebenarnya
atau acara. Benda mungkin pelanggan, item, perintah, dan sebagainya. Benda yang diwakili oleh dan
dikelompokkan ke dalam kelas yang optimal untuk digunakan kembali dan pemeliharaan. Kelas A mendefinisikan set
atribut dan perilaku bersama yang ditemukan di setiap objek di kelas.
Fase dalam UML adalah sama dengan yang di SDLC. Sejak dua metode berbagi kaku
dan menuntut pemodelan, mereka terjadi dalam lebih lambat, kecepatan yang lebih disengaja daripada fase tangkas
modeling. Analis melewati masalah dan identifikasi fase, fase analisis, dan
fase desain seperti yang ditunjukkan pada Gambar 1.8. Meskipun banyak spesifik dibahas dalam Bab 2
dan 10, langkah-langkah berikut memberikan gambaran singkat tentang proses UML.
1. Tentukan model use case.
Pada fase ini analis mengidentifikasi pelaku dan peristiwa besar yang diprakarsai oleh pelaku.
Sering analis akan mulai dengan menggambar diagram dengan tongkat angka mewakili aktor dan
panah menunjukkan bagaimana aktor berhubungan. Ini disebut diagram use case (Bab 2) dan
merupakan aliran standar kejadian dalam sistem. Kemudian seorang analis biasanya menulis up penggunaan sebuah
skenario (Bab 2), yang menggambarkan dengan kata-kata langkah-langkah yang biasanya dilakukan.
2. Selama tahap analisis sistem, mulai menggambar diagram UML.
Pada tahap kedua (Bab 10), analis akan menarik Activity Diagram, yang
menggambarkan semua kegiatan utama dalam kasus penggunaan. Selain itu, analis akan membuat satu atau
diagram urutan lebih untuk setiap kasus penggunaan, yang menunjukkan urutan kegiatan dan mereka
waktu. Ini adalah kesempatan untuk kembali dan meninjau kasus penggunaan, memikirkan kembali mereka, dan
memodifikasi mereka jika perlu.
3. Melanjutkan dalam tahap analisis, mengembangkan diagram kelas.
Kata benda dalam kasus penggunaan adalah objek yang berpotensi dapat dikelompokkan ke dalam kelas. Untuk
Misalnya, setiap mobil adalah obyek yang berbagi karakteristik dengan mobil lainnya.
Bersama-sama mereka membuat kelas.
4. Masih dalam tahap analisis, menggambar diagram statechart.
Diagram kelas digunakan untuk menggambar diagram statechart, yang membantu dalam pemahaman
proses kompleks yang tidak dapat sepenuhnya diturunkan oleh diagram urutan. Statechart yang
diagram sangat berguna dalam memodifikasi diagram kelas, sehingga proses iteratif
UML modeling terus.
5. Mulailah desain sistem dengan memodifikasi diagram UML. Kemudian menyelesaikan spesifikasi.
Sistem desain berarti memodifikasi sistem yang ada dan yang menyiratkan memodifikasi
diagram ditarik di fase sebelumnya. Diagram ini dapat digunakan untuk menurunkan kelas, mereka
atribut, dan metode (metode hanya operasi). Analis perlu untuk menulis
spesifikasi kelas untuk setiap kelas termasuk atribut, metode, dan deskripsi mereka.
Mereka juga akan mengembangkan spesifikasi metode yang detail input dan output persyaratan
untuk metode, bersama dengan penjelasan rinci tentang proses internal dari metode ini.
6. Mengembangkan dan mendokumentasikan sistem.
UML adalah, tentu saja, bahasa pemodelan. Seorang analis dapat membuat model yang indah, tapi
jika sistem ini tidak dikembangkan tidak ada gunanya model bangunan. Dokumentasi
kritis. Semakin lengkap informasi yang Anda berikan tim pengembangan melalui
dokumentasi dan diagram UML, semakin cepat perkembangan dan lebih solid final
sistem produksi.
Metodologi berorientasi objek sering fokus pada kecil, iterasi cepat pembangunan, kadang-kadang
disebut model spiral. Analisis dilakukan pada bagian kecil dari sistem, biasanya dimulai
dengan item prioritas tinggi atau mungkin salah satu yang memiliki risiko terbesar. Ini diikuti dengan desain dan
implementasi. Siklus ini diulang dengan analisis bagian selanjutnya, desain, dan beberapa implementasi,
dan diulang sampai proyek selesai. Pengerjaan ulang diagram dan komponen
sendiri adalah normal. UML adalah alat pemodelan yang kuat yang dapat sangat meningkatkan kualitas Anda
analisis dan desain sistem dan produk akhir.
MEMILIH METODE YANG SISTEM PEMBANGUNAN UNTUK MENGGUNAKAN
Perbedaan antara tiga pendekatan yang dijelaskan sebelumnya tidak sebesar sebagaimana yang tampak di awal.
Dalam semua tiga pendekatan, analis perlu memahami organisasi pertama (Bab 2). Kemudian
analis atau tim proyek perlu anggaran waktu dan sumber daya mereka dan mengembangkan proposal proyek
(Bab 3). Berikutnya mereka harus mewawancarai anggota organisasi dan mengumpulkan data rinci dengan menggunakan
kuesioner (Bab 4) dan data sampel dari laporan yang ada dan mengamati bagaimana bisnis
Saat ini ditransaksikan (Bab 5). Ketiga pendekatan memiliki semua kegiatan tersebut kesamaan.
Bahkan metode sendiri memiliki kesamaan. TheSDLCand pendekatan berorientasi objek baik
memerlukan perencanaan yang luas dan diagram. Pendekatan lincah dan pendekatan berorientasi objek
kedua memungkinkan subsistem akan dibangun satu per satu sampai seluruh sistem selesai. Tangkas dan
Pendekatan SDLC keduanya khawatir tentang data cara logis bergerak melalui sistem.
Jadi diberikan pilihan untuk mengembangkan sistem menggunakan pendekatan SDLC, pendekatan tangkas, atau object
pendekatan berorientasi, yang akan Anda pilih? Gambar 1.9 menyediakan seperangkat pedoman untuk membantu
Anda memilih metode mana yang digunakan ketika mengembangkan sistem Anda berikutnya.
RINGKASAN
Informasi dapat dilihat sebagai sumber daya organisasi seperti manusia. Karena itu, harus dikelola

hati-hati, seperti sumber daya lainnya yang. Ketersediaan daya komputer terjangkau untuk organisasi memiliki
berarti ledakan informasi, dan akibatnya, lebih banyak perhatian harus dibayar untuk mengatasi informasi
dihasilkan.
Sistem analis merekomendasikan, desain, dan memelihara berbagai jenis sistem bagi pengguna, termasuk transaksi
sistem pengolahan (TPS), sistem otomatisasi kantor (OAS), sistem kerja pengetahuan (KWS), dan manajemen
sistem informasi (MIS). Mereka juga menciptakan sistem yang berorientasi keputusan untuk pengguna tertentu. Ini

"Selamat Datang di Maple Ridge Engineering, apa yang kita

sebut MRE.
Kami harap Anda menikmati melayani sebagai konsultan
sistem bagi kita. Meskipun
Saya telah bekerja di sini lima tahun dalam kapasitas yang
berbeda, saya baru saja
ditugaskan kembali untuk melayani sebagai asisten
administratif untuk Snowden
Evans, kepala Pelatihan baru dan Departemen Sistem
Manajemen.
Kami tentu berbagai kelompok. Ketika Anda membuat jalan
Anda
melalui perusahaan, pastikan untuk menggunakan semua
keahlian Anda, baik teknis
dan orang-orang yang berorientasi, untuk memahami siapa
kita dan untuk mengidentifikasi
masalah dan konflik yang Anda pikir harus diselesaikan
mengenai
sistem informasi kami. "
"Untuk membawa Anda up to date, saya katakan bahwa
Rekayasa Maple Ridge
adalah sebuah perusahaan rekayasa medis menengah.
Lalu
tahun, pendapatan kami melebihi $ 287.000.000. Kami
mempekerjakan sekitar
335 orang. Ada sekitar 150 karyawan administrasi serta
manajemen dan staf administrasi seperti diriku; sekitar
75 karyawan yang profesional, termasuk insinyur, dokter,
dan
analis sistem; dan sekitar 110 karyawan perdagangan,
seperti perancang
dan teknisi. "
"Ada empat kantor. Anda akan mengunjungi kami melalui
HyperCase di
kantor rumah kami di Maple Ridge, Tennessee. Kami
memiliki tiga lainnya

cabang di Amerika Serikat bagian selatan juga: Atlanta,

Georgia;
Charlotte, North Carolina; dan New Orleans, Louisiana.
Kami akan senang
untuk memiliki Anda mengunjungi ketika Anda berada di
daerah. "
"Untuk saat ini, Anda harus mencari HyperCase baik
menggunakan Firefox,
Safari, atau Microsoft Internet Explorer. "
"Untuk mempelajari lebih lanjut tentang Maple Ridge
Teknik sebagai perusahaan
atau untuk mencari tahu bagaimana untuk mewawancarai
karyawan, yang akan menggunakan sistem
Anda merancang, dan bagaimana untuk mengamati kantor
mereka di perusahaan kami,
Anda mungkin ingin memulai dengan pergi ke situs Web
yang ditemukan di www.
pearsonhighered.com/kendall. Kemudian klik pada link
berlabel
HyperCase. Pada tampilan layar HyperCase, klik Mulai dan
Anda akan berada di ruang tamu untuk Maple Ridge Teknik.
Dari titik ini, Anda dapat mulai konsultasi langsung. "
Situs Web ini berisi informasi yang berguna tentang proyek
sebagai
serta file yang dapat didownload ke komputer Anda. Ada
satu set
file data Analis Terlihat, dan satu set file data yang Visio
cocok HyperCase. Mereka berisi serangkaian sebagian
dibangun dari
diagram aliran data, diagram relasi entitas, diagram UML,
dan informasi repositori. Situs Web HyperCase juga
mengandung
latihan tambahan yang dapat ditugaskan. HyperCase
dirancang
untuk dieksplorasi, dan Anda tidak harus mengabaikan
setiap objek atau petunjuk pada
halaman web

termasuk sistem pendukung keputusan (DSS), sistem pakar (ES), sistem pendukung keputusan kelompok (GDSS),
sistem komputer yang didukung kolaboratif kerja (CSCWS), dan sistem pendukung eksekutif (ESS). Banyak aplikasi
yang baik yang berasal dari, atau pindah ke, theWeb untuk mendukung e-commerce dan banyak fungsi bisnis lainnya.
Analisis sistem dan desain adalah pendekatan sistematis untuk mengidentifikasi masalah, peluang, dan tujuan;
untuk menganalisis informasi manusia dan komputer yang dihasilkan mengalir dalam organisasi; dan untuk merancang
sistem informasi terkomputerisasi untuk memecahkan masalah. Analis sistem yang diperlukan untuk mengambil banyak
peran
dalam perjalanan pekerjaan mereka. Beberapa peran ini adalah (1) konsultan luar untuk bisnis, (2) mendukung
ahli dalam bisnis, dan (3) agen perubahan dalam situasi baik internal maupun eksternal.
Analis memiliki berbagai keterampilan. Pertama dan terpenting, analis adalah pemecah masalah, seseorang
yang menikmati tantangan menganalisa masalah dan merancang solusi yang bisa diterapkan. Analis sistem membutuhkan
keterampilan komunikasi yang memungkinkan mereka untuk berhubungan bermakna untuk berbagai macam orang setiap
hari,
serta keterampilan komputer. Memahami dan berhubungan dengan baik untuk pengguna sangat penting untuk keberhasilan
mereka.
Analis melanjutkan sistematis. Kerangka kerja untuk pendekatan sistematis mereka disediakan dalam apa yang
disebut siklus hidup pengembangan sistem (SDLC). Siklus hidup ini dapat dibagi menjadi tujuh berurutan
fase, meskipun pada kenyataannya fase saling terkait dan sering dilakukan secara bersamaan. Tujuh
fase yang mengidentifikasi masalah, peluang, dan tujuan; menentukan kebutuhan informasi manusia;
menganalisis kebutuhan sistem; merancang sistem yang direkomendasikan; mengembangkan dan mendokumentasikan
perangkat lunak;
pengujian dan pemeliharaan sistem; dan melaksanakan dan mengevaluasi sistem.
Pendekatan tangkas adalah pendekatan pengembangan perangkat lunak berdasarkan nilai-nilai, prinsip, dan praktik inti.
Sistem yang dirancang menggunakan metode tangkas dapat berkembang pesat. Tahapan dalam pengembangan tangkas
Proses yang eksplorasi, perencanaan, iterasi untuk pertama rilis, productionizing, dan pemeliharaan.
Pendekatan ketiga untuk pengembangan sistem yang disebut desain analisis berorientasi objek. Teknik ini

didasarkan pada konsep pemrograman berorientasi objek yang telah menjadi dikodifikasikan dalam UML, sebuah standar
bahasa pemodelan di mana objek yang dibuat tidak hanya mencakup kode tentang data tetapi juga petunjuk
tentang operasi yang akan dilakukan pada data. Diagram kunci membantu menganalisis, desain, dan berkomunikasi
Sistem UML dikembangkan. Sistem ini biasanya dikembangkan sebagai komponen dan pengerjaan ulang komponen
berkali-kali adalah kegiatan normal dalam analisis berorientasi objek dan desain.
PERTANYAAN REVIEW
1. Bandingkan memperlakukan informasi sebagai sumber daya untuk mengobati manusia sebagai sumber daya.
2. Daftar perbedaan antara OAS dan KWS.
3. Tentukan apa yang dimaksud dengan MIS.
4. Bagaimana MIS berbeda dari DSS?
5. Tentukan sistem pakar jangka. Bagaimana sistem pakar berbeda dari sistem pendukung keputusan?
6. Daftar masalah interaksi kelompok yang sistem pendukung keputusan kelompok (GDSS) dan computersupported
sistem kerja kolaboratif (CSCWS) dirancang untuk mengatasi.
7. Yang merupakan istilah yang lebih umum, CSCWS atau GDSS? Jelaskan.
8. Tentukan mCommerce jangka.
9. Daftar keuntungan dari aplikasi pemasangan di Web.
10. Apa alasan menyeluruh untuk merancang perusahaan (atau ERP) sistem?
11. Memberikan contoh dari proyek perangkat lunak open source.
12. Daftar keuntungan menggunakan analisis sistem dan desain teknik di mendekat terkomputerisasi
sistem informasi untuk bisnis.
13. Daftar tiga peran bahwa sistem analis dipanggil untuk bermain. Memberikan definisi untuk masing-masing.
14. Apa kualitas pribadi yang membantu untuk analis sistem? Daftar mereka.
15. Daftar dan secara singkat mendefinisikan tujuh fase siklus hidup pengembangan sistem (SDLC).
16. Apa CASE tools digunakan untuk?
17. Apa perbedaan antara alat CASE atas dan bawah?
18. Tentukan apa yang dimaksud dengan pendekatan tangkas.
19. Apa arti dari kalimat "perencanaan game"?
20. Apa tahapan dalam pengembangan tangkas?
21. Tentukan analisis berorientasi objek jangka dan desain.
22. Apa UML?
Chap2
Keterkaitan dan Interdependensi Sistem
Semua sistem dan subsistem yang saling terkait dan saling tergantung. Fakta ini memiliki implikasi penting
baik untuk organisasi dan bagi mereka analis sistem yang berusaha untuk membantu mereka lebih mencapai
tujuan mereka. Ketika setiap elemen dari suatu sistem berubah atau dihilangkan, sisa elemen sistem
dan subsistem juga secara signifikan terpengaruh.
Misalnya, bahwa manajer dari suatu organisasi memutuskan untuk tidak menyewa asisten administrasi
lagi dan mengganti fungsi mereka dengan PC jaringan. Keputusan ini memiliki potensi
mempengaruhi secara signifikan tidak hanya asisten administrasi dan manajer tetapi juga semua
anggota organisasi yang membangun jaringan komunikasi dengan asisten sekarang berangkat.
Semua sistem memproses masukan dari lingkungan mereka. Menurut definisi, proses mengubah atau
mengubah input menjadi output. Setiap kali Anda memeriksa sistem, memeriksa untuk melihat apa yang sedang
diubah atau diproses. Jika tidak ada yang berubah, Anda mungkin tidak akan mengidentifikasi proses. Khas
proses dalam sistem meliputi verifikasi, memperbarui, dan pencetakan.
Aspek lain dari organisasi sebagai sistem adalah bahwa semua sistem yang terkandung oleh batas-batas
memisahkan mereka dari lingkungan mereka. Batas-batas organisasi ada di sebuah kontinum mulai
dari sangat permeabel terhadap hampir kedap. Untuk terus beradaptasi dan bertahan hidup, organisasi
harus mampu pertama yang mengimpor orang, bahan baku, dan informasi melalui mereka
batas (input), dan kemudian untuk bertukar mereka produk jadi, jasa, atau informasi dengan
dunia luar (output).
Umpan balik adalah salah satu bentuk dari sistem kontrol. Sebagai sistem, semua organisasi menggunakan perencanaan dan
pengendalian
untuk mengelola sumber daya mereka secara efektif. Gambar 2.1 menunjukkan bagaimana output sistem yang digunakan
sebagai umpan balik
yang membandingkan kinerja dengan tujuan. Perbandingan ini pada gilirannya membantu manajer merumuskan
tujuan yang lebih spesifik sebagai masukan. Contohnya adalah sebuah perusahaan manufaktur AS yang memproduksi
redwhitedan biru set latihan beban serta senjata-logam set abu-abu. Perusahaan menemukan satu yang
tahun setelah Olimpiade, sangat sedikit set merah-putih-dan biru yang dibeli. Manajer produksi
menggunakan informasi itu sebagai umpan balik untuk membuat keputusan tentang apa yang jumlah setiap warna untuk
menghasilkan.
Umpan balik dalam hal ini berguna untuk perencanaan dan pengendalian.
Sistem yang ideal, bagaimanapun, adalah salah satu yang mengoreksi diri atau diri-mengatur sedemikian rupa bahwa
keputusan
pada kejadian khas tidak diperlukan. Contohnya adalah sistem rantai pasokan untuk produksi
perencanaan yang memperhitungkan saat ini dan proyeksi permintaan dan merumuskan usulan
solusi sebagai output. Produsen pakaian rajut Italia yang memasarkan pakaian di Amerika Serikat
baru saja sistem tersebut. Perusahaan ini memproduksi sebagian besar sweater di putih, menggunakan komputerisasi yang
informasi persediaan sistem untuk mencari tahu apa warna jual terbaik, dan kemudian pewarna sweater
dalam warna laris segera sebelum pengiriman mereka.
Umpan balik yang diterima dari dalam organisasi dan dari lingkungan luar sekitar
saya t. Apapun eksternal untuk batas-batas organisasi dianggap lingkungan. Banyak sekali
lingkungan, dengan berbagai tingkat stabilitas, merupakan lingkungan di mana organisasi ada.
Di antara lingkungan ini adalah (1) lingkungan masyarakat di mana organisasi
secara fisik terletak, yang dibentuk oleh ukuran populasi dan profil demografis,

termasuk faktor-faktor seperti pendidikan dan pendapatan rata-rata; (2) lingkungan ekonomi,
dipengaruhi oleh faktor pasar, termasuk persaingan; (3) lingkungan politik, dikendalikan
melalui pemerintah negara bagian dan lokal; dan (4) lingkungan hukum, mengeluarkan federal, negara bagian, regional,
dan hukum dan pedoman lokal. Meskipun perubahan status lingkungan dapat direncanakan
untuk, mereka sering tidak bisa langsung dikendalikan oleh organisasi

"Toko ritel kami dan divisi mail-order yang cukup sehat,"

kata Bill Berry, salah satu pemilik dari Marathon Vitamin
toko, "tapi
untuk menjadi kompetitif, kita harus membangun sebuah
situs e-commerce Web. "Nya
Ayah, co-pemilik, berseru, "Saya setuju, tapi di mana kita
mulai?" The
tua Berry tahu, tentu saja, bahwa itu bukan kasus
menyiapkan Web
situs dan meminta pelanggan untuk email pesanan mereka
ke toko ritel. Dia
diidentifikasi delapan bagian yang berbeda untuk ecommerce dan menyadari bahwa mereka
semua bagian dari sistem yang lebih besar. Dengan kata
lain, semua bagian harus
bekerja sama untuk menciptakan sebuah paket yang kuat.
Daftar nya elemen penting
untuk e-commerce meliputi:
1. Menarik pelanggan ke situs Web e-commerce.
2. Menginformasikan pelanggan tentang produk dan jasa
yang ditawarkan.
3. Membiarkan pelanggan untuk menyesuaikan produk
secara online.
4. Melengkapi transaksi dengan pelanggan.
5. Menerima pembayaran dari pelanggan dalam berbagai
bentuk.
6. Mendukung pelanggan setelah penjualan melalui situs
Web.
7. Mengatur untuk pengiriman barang dan jasa.

8. Personalisasi tampilan dan nuansa dari situs Web untuk

berbeda
pelanggan.
Bill Berry membaca daftar dan merenungkan untuk
sementara waktu. "Ini jelas
e-commerce yang lebih kompleks daripada yang saya pikir,
"katanya. Kamu
dapat membantu para pemilik Marathon Vitamin toko di
berikut ini
cara:
1. Buatlah daftar unsur-unsur yang saling terkait atau
saling tergantung. Kemudian menulis sebuah paragraf
yang menyatakan mengapa
penting untuk memantau elemen-elemen ini erat.
2. Tentukan batas-batas dan ruang lingkup utama dari
sistem.
Artinya, menulis sebuah paragraf mengekspresikan
pendapat yang
elemen sangat penting untuk Marathon Vitamin Toko dan
yang
elemen dapat dieksplorasi di kemudian hari.
3. Sarankan yang elemen harus ditangani di rumah dan
yang harus diserahkan kepada perusahaan lain yang
mungkin
lebih mampu menangani pekerjaan. Membenarkan saran
Anda dalam dua
paragraf, satu untuk pekerjaan di rumah dan satu untuk
tugas outsourcing.

Terkait dan mirip dengan konsep permeabilitas batas eksternal adalah konsep internal
keterbukaan atau ketertutupan organisasi. Keterbukaan dan Ketertutupan juga ada di sebuah kontinum,
karena tidak ada hal seperti itu sebagai sebuah organisasi yang benar-benar terbuka atau benar-benar tertutup.
Keterbukaan mengacu pada arus informasi yang bebas dalam organisasi. Subsistem seperti
departemen kreatif atau seni sering ditandai sebagai open, dengan aliran ide di antara peserta
dan sangat sedikit pembatasan pada siapa mendapat apa informasi pada waktu apa ketika kreatif
proyek masih dalam tahap awal.
Pada ujung kontinum mungkin unit departemen pertahanan ditugaskan untuk bekerja
perencanaan pertahanan rahasia yang mempengaruhi keamanan nasional. Setiap orang perlu menerima clearance,
informasi yang tepat waktu adalah suatu keharusan, dan akses informasi hanya pada "perlu tahu" dasar.
Ini semacam unit dibatasi oleh berbagai aturan.
Menggunakan overlay sistem untuk memahami organisasi memungkinkan kita untuk mengakui ide
sistem terdiri dari subsistem; keterkaitan dan saling ketergantungan mereka; keberadaan
batas yang memungkinkan atau mencegah interaksi antara berbagai departemen dan unsur-unsur
subsistem dan lingkungan lainnya; dan keberadaan lingkungan internal ditandai dengan
derajat keterbukaan dan ketertutupan, yang mungkin berbeda di seluruh departemen, unit, atau bahkan sistem
proyek.
Organisasi Virtual dan Tim Virtual
Tidak semua organisasi atau bagian dari organisasi yang terlihat di lokasi fisik. Organisasi seluruh
atau unit organisasi sekarang dapat memiliki komponen virtual yang memungkinkan mereka untuk
konfigurasi perubahan untuk beradaptasi dengan perubahan proyek atau pasar tuntutan. Perusahaan virtual
menggunakan jaringan komputer dan teknologi komunikasi untuk membawa orang-orang dengan spesifik
keterampilan bersama-sama secara elektronik untuk bekerja pada proyek-proyek yang tidak secara fisik terletak di
tempat yang sama. Teknologi informasi memungkinkan koordinasi anggota ini tim terpencil. Sering
tim virtual bermunculan di organisasi yang sudah mapan; dalam beberapa kasus, bagaimanapun,
organisasi pekerja jarak jauh telah mampu sukses tanpa investasi tradisional
dalam fasilitas fisik

Ada beberapa manfaat potensial untuk organisasi virtual, seperti kemungkinan mengurangi
biaya fasilitas fisik, respon cepat lebih untuk kebutuhan pelanggan, dan membantu karyawan maya
untuk memenuhi kewajiban keluarga mereka untuk pertumbuhan anak-anak atau orang tua penuaan. Hanya bagaimana
penting itu akan memenuhi kebutuhan sosial pekerja virtual masih terbuka untuk penelitian dan perdebatan.
Salah satu contoh dari kebutuhan untuk identifikasi nyata dengan budaya muncul ketika siswa yang
terdaftar di sebuah universitas virtual online, dengan tidak ada kampus fisik (atau tim olahraga), terus meminta
barang-barang seperti kaus, mug kopi, dan panji-panji dengan logo universitas virtual dicantumkan
pada mereka. Barang-barang ini adalah artefak budaya yang berarti bahwa tradisional bata-dan-mortir
sekolah telah lama tersedia.

Banyak analisis sistem dan desain tim sekarang dapat bekerja secara virtual, dan pada kenyataannya, banyak dari
mereka ditandai jalan untuk jenis lain dari karyawan untuk mengikuti dalam menyelesaikan pekerjaan secara virtual.
Beberapa analis izin aplikasi yang menyediakan bantuan teknis melalui Web untuk "melihat"
perangkat lunak dan perangkat keras konfigurasi pengguna meminta bantuan, dengan cara ini menciptakan sebuah iklan
hoc tim virtual terdiri dari analis dan pengguna.
Mengambil Sistem Perspektif
Mengambil perspektif sistem memungkinkan sistem analis untuk memulai luas mengklarifikasi dan pemahaman
berbagai bisnis yang mereka akan datang ke dalam kontak. Adalah penting bahwa anggota
subsistem menyadari bahwa pekerjaan mereka adalah saling terkait. Perhatikan pada Gambar 2.2 bahwa output dari
subsistem produksi berfungsi sebagai masukan untuk pemasaran dan bahwa output pemasaran berfungsi sebagai
input baru untuk produksi. Subsistem tidak benar dapat mencapai tujuannya tanpa yang lain.
Masalah terjadi ketika setiap manajer memiliki gambaran yang berbeda tentang pentingnya atau
subsistem fungsional sendiri. Dalam Gambar 2.3 Anda dapat melihat bahwa manajer pemasaran pribadi
perspektif menunjukkan bisnis didorong oleh pemasaran, dengan semua bidang fungsional lainnya saling terkait
tapi tidak sangat penting. Dengan cara yang sama, perspektif posisi manajer produksi
produksi di pusat bisnis, dengan semua bidang fungsional lainnya didorong oleh itu.
Kepentingan relatif dari bidang fungsional sebagaimana terungkap dalam perspektif pribadi manajer
mengambil signifikansi ditambahkan ketika manajer naik ke atas melalui peringkat, menjadi
manajer strategis. Mereka dapat membuat masalah jika mereka terlalu menekankan informasi fungsional sebelum mereka
persyaratan dalam kaitannya dengan kebutuhan organisasi yang lebih luas.
Sebagai contoh, jika seorang manajer produksi dipromosikan tapi terus menekankan penjadwalan produksi
dan kinerja pekerja line, aspek yang lebih luas dari peramalan dan kebijakan pengambilan mungkin
menderita. Kecenderungan ini adalah bahaya dalam segala macam usaha: di mana insinyur bekerja dengan cara mereka
sampai
menjadi administrator dari perusahaan kedirgantaraan, dosen bergerak dari departemen mereka untuk menjadi
dekan, atau programmer maju untuk menjadi eksekutif perusahaan perangkat lunak. Terowongan visi mereka
sering menciptakan masalah bagi analis sistem mencoba untuk memisahkan informasi aktual
persyaratan dari keinginan untuk jenis informasi tertentu.

Sistem Perusahaan: Melihat Organisasi sebagai System

Sistem perusahaan, sering disebut sebagai perencanaan sumber daya perusahaan (ERP) sistem, adalah istilah
digunakan untuk menggambarkan suatu sistem organisasi (perusahaan) informasi yang terintegrasi. Secara khusus, ERP
adalah perangkat lunak yang membantu aliran informasi antara bidang fungsional dalam organisasi. Saya t
adalah sistem yang disesuaikan yang, bukannya dikembangkan di rumah, biasanya dibeli dari salah satu
perusahaan pengembangan perangkat lunak terkenal paket ERP, seperti SAP atau Oracle.
Produk ini kemudian disesuaikan agar sesuai dengan persyaratan dari perusahaan tertentu. Biasanya,
Vendor membutuhkan komitmen organisasi dalam hal pengguna khusus atau pelatihan analis.
Banyak paket ERP dirancang untuk berjalan di Web. ERP, meskipun semakin populer, juga
yang dilihat dengan beberapa skeptisisme.
ERP berkembang dari kebutuhan bahan perencanaan (MRP), sistem informasi yang dirancang
untuk meningkatkan manufaktur pada umumnya dan perakitan pada khususnya. Sistem ERP sekarang termasuk
komponen manufaktur dan dengan demikian membantu dengan perencanaan kapasitas, penjadwalan produksi material,
dan peramalan. Di luar manufaktur (dan rekan pelayanannya), ERP meliputi penjualan dan
operasi perencanaan, distribusi, pengadaan, dan mengelola rantai pasokan. Oleh karena itu secara signifikan
mempengaruhi semua daerah dalam organisasi, termasuk akuntansi, keuangan, manajemen,
pemasaran, dan sistem informasi.
Menerapkan solusi ERP mungkin frustasi karena sulit untuk menganalisis sistem
sedang digunakan dan kemudian sesuai dengan model ERP sistem itu. Selanjutnya, perusahaan cenderung merancang
proses bisnis mereka sebelum ERP diimplementasikan. Sayangnya, proses ini sering
bergegas dan model bisnis yang diusulkan tidak selalu sesuai dengan fungsi ERP. Hasil
adalah kustomisasi lebih lanjut, jangka waktu pelaksanaan diperpanjang, biaya yang lebih tinggi, dan sering kehilangan
Menggambarkan SISTEM grafis
Asystem atau subsistem seperti yang ada dalam organisasi perusahaan dapat digambarkan secara grafis
dalam beberapa cara. Berbagai model grafis menunjukkan batas-batas sistem dan informasi yang
digunakan dalam sistem.
Sistem dan Konteks-Level Data Flow Diagram yang
Model pertama adalah diagram aliran data konteks tingkat (juga disebut model lingkungan). Data
diagram alir fokus pada data yang mengalir masuk dan keluar dari sistem dan pengolahan data.
Komponen-komponen dasar dari setiap program komputer dapat dijelaskan secara rinci dan digunakan untuk menganalisis
sistem untuk akurasi dan kelengkapan.
Seperti yang ditunjukkan pada Gambar 2.4, diagram aliran data konteks tingkat mempekerjakan hanya tiga simbol: (1)
persegi panjang dengan sudut membulat, (2) sebuah persegi dengan dua sisi yang teduh, dan (3) anak panah. Proses
mengubah data yang masuk ke informasi keluar, dan tingkat konten hanya memiliki satu proses,
mewakili seluruh sistem. Entitas eksternal merupakan entitas yang memasok atau menerima
informasi dari sistem tetapi bukan merupakan bagian dari sistem. Entitas ini mungkin orang, kelompok
orang, posisi perusahaan atau departemen, atau sistem lainnya. Garis yang menghubungkan eksternal
entitas untuk proses disebut arus data, dan mereka mewakili data.
Contoh dari data flow diagram konteks tingkat ditemukan dalam Gambar 2.5. Dalam contoh ini,
sebagian elemen dasar dari sistem reservasi maskapai penerbangan yang diwakili. Penumpang (entitas) inisiat
permintaan perjalanan (aliran data). Diagram konteks tingkat tidak menunjukkan cukup detail untuk menunjukkan
persis apa yang terjadi (tidak seharusnya), tetapi kita dapat melihat bahwa preferensi penumpang dan
penerbangan yang tersedia dikirim ke agen perjalanan, yang mengirimkan informasi ticketing kembali ke process.We yang
juga dapat melihat bahwa reservasi penumpang dikirim ke maskapai. Konteks tingkat data flow diagram
berfungsi sebagai titik awal yang baik untuk menggambar diagram use case (dibahas kemudian dalam bab ini).
Dalam Bab 7 kita melihat bahwa aliran data berisi banyak informasi. Misalnya, penumpang

pemesanan berisi nama, maskapai, nomor penumpang penerbangan (s), tanggal (s) dari perjalanan, harga, tempat duduk
preferensi, dan sebagainya. Untuk saat ini, bagaimanapun, kita prihatin terutama dengan bagaimana tingkat konteks
mendefinisikan batas-batas sistem. Dalam contoh sebelumnya, hanya pemesanan adalah bagian dari
proses. Keputusan lain bahwa maskapai ini akan membuat (misalnya, pembelian pesawat terbang, mengubah
jadwal, harga) bukan bagian dari sistem ini.
Diagram aliran data konteks tingkat adalah salah satu cara untuk menunjukkan ruang lingkup dari sistem, atau apa yang
untuk dimasukkan dalam sistem. Entitas eksternal di luar ruang lingkup dan sesuatu yang lebih
yang sistem tidak memiliki kontrol.
Sistem dan Model Entity-Relationship
Cara sistem analis lain dapat menunjukkan ruang lingkup dari sistem dan menentukan batas-batas sistem yang tepat
adalah dengan menggunakan diagram hubungan entitas. Unsur-unsur yang membentuk sistem organisasi
dapat disebut sebagai entitas. Entitas dapat menjadi orang, tempat, atau sesuatu, seperti penumpang
pada sebuah maskapai penerbangan, tujuan, atau pesawat. Atau, suatu entitas dapat menjadi acara, seperti akhir
bulan, periode penjualan, atau gangguan mesin. Suatu hubungan adalah asosiasi yang menggambarkan
interaksi antara entitas.
Ada banyak konvensi yang berbeda untuk menggambar entitas-hubungan (ER) diagram (dengan
nama-nama seperti kaki gagak, Arrow, atau notasi Bachman). Dalam buku ini, kita menggunakan notasi kaki gagak.
Untuk saat ini, kita mengasumsikan bahwa suatu entitas adalah kotak persegi panjang polos.
Gambar 2.6 menunjukkan diagram entitas-hubungan yang sederhana. Dua entitas terkait bersama-sama oleh
line. Dalam contoh ini, akhir baris ditandai dengan dua tanda paralel pendek (| |), menandakan
bahwa hubungan ini adalah satu-ke-satu. Dengan demikian, tepat satu karyawan ditugaskan untuk salah satu ekstensi
telepon.
Tidak ada yang berbagi ekstensi telepon yang sama di kantor ini.
Panah merah bukan merupakan bagian dari diagram entitas-hubungan. Mereka hadir untuk menunjukkan
cara membaca diagram entitas-hubungan. Ungkapan di sisi kanan dari garis dibaca
dari atas ke bawah sebagai berikut: "Satu EMPLOYEE ditugaskan untuk satu PHONE EXTENSION." Pada
sisi kiri, saat Anda membaca dari bawah ke atas, panah mengatakan, "Satu PHONE EXTENSION terdaftar
untuk satu KARYAWAN. "
Demikian pula, Gambar 2.7 menunjukkan hubungan lain. Notasi kaki gagak (> - +) adalah jelas pada
diagram ini, dan contoh khusus ini adalah banyak-ke-satu contoh. Ketika Anda membaca dari kiri ke kanan,
panah menandakan, "Banyak KARYAWAN adalah anggota DEPARTEMEN a." Saat Anda membaca dari
kanan ke kiri, itu berarti, "Satu DEPARTEMEN mengandung banyak KARYAWAN."
Perhatikan bahwa ketika banyak-ke-satu hubungan hadir, perubahan tata bahasa dari "adalah" untuk
"Yang" meskipun tunggal "adalah" ditulis pada baris. Kaki gagak dan tanda tunggal lakukan
tidak secara harfiah berarti akhir ini hubungan harus menjadi wajib "banyak." Sebaliknya, mereka menyiratkan
bahwa tujuan ini bisa apa saja dari satu ke banyak.
Gambar 2.8 mengelaborasi skema ini. Di sini kita telah terdaftar sejumlah hubungan entitas khas.
Yang pertama, "Sebuah EMPLOYEE ditugaskan untuk sebuah OFFICE," adalah hubungan satu-ke-satu. Yang kedua
adalah banyak satu-ke-hubungan: "Satu CARGO PESAWAT akan melayani satu atau lebih DISTRIBUSI
Pusat. "Yang ketiga adalah sedikit berbeda karena memiliki lingkaran di salah satu ujung. Hal ini dapat dibaca sebagai "A
SISTEM ANALYST dapat ditugaskan untuk PROYEK BANYAK, "yang berarti bahwa analis dapat ditugaskan
tidak ada proyek [itulah yang lingkaran (O), untuk nol, adalah untuk], satu, atau banyak proyek. Demikian juga,
lingkaran (O) menunjukkan bahwa tidak ada yang mungkin dalam hubungan selanjutnya. Ingat bahwa tanda pendek berarti
satu.
Oleh karena itu, kita dapat membacanya sebagai berikut: "A MESIN mungkin atau mungkin tidak akan mengalami
DIJADWALKAN
MAINTENANCE. "Perhatikan bahwa garis ditulis sebagai" sedang mengalami, "tapi tanda akhir pada baris
menunjukkan bahwa baik tidak ada pemeliharaan (O) atau pemeliharaan (I) yang sebenarnya terjadi.
Negara hubungan berikutnya, "Satu atau banyak tenaga penjualan (jamak dari SALESPERSON) adalah
ditugaskan untuk satu atau lebih pelanggan. "Ini adalah klasik hubungan banyak-ke-banyak. Hubungan selanjutnya
dapat dibaca sebagai berikut: "The RUMAH KANTOR dapat memiliki satu atau banyak karyawan,"
atau "Satu atau lebih karyawan mungkin atau mungkin tidak ditugaskan ke OFFICE HOME." Sekali lagi,
yang Iand O bersama-sama menyiratkan situasi Boolean; dengan kata lain, satu atau nol.
Hubungan akhir ditampilkan di sini dapat dibaca sebagai, "Banyak penumpang ke banyak
Tujuan. "Simbol ini [> - +] lebih disukai oleh beberapa orang untuk menunjukkan wajib" banyak "kondisi.
(Apakah itu pernah mungkin untuk hanya memiliki satu penumpang atau hanya satu tujuan?) Meski begitu,
beberapa alat CASE seperti Analis Terlihat tidak menawarkan kemungkinan ini, karena oneor- opsional
banyak kondisi seperti yang ditunjukkan dalam hubungan SALESPERSON-CUSTOMER akan melakukan.
Sampai sekarang kami telah dimodelkan semua hubungan kita menggunakan hanya satu persegi panjang sederhana dan
garis.
Metode ini bekerja dengan baik ketika kita meneliti hubungan dari hal-hal yang nyata seperti orang yang nyata,
tempat, dan hal-hal. Kadang-kadang, meskipun, kita membuat item baru dalam proses pengembangan
sistem Informasi. Beberapa contoh adalah faktur, tanda terima, file, dan database. Ketika kita ingin
untuk menggambarkan bagaimana seseorang berhubungan dengan tanda terima , misalnya , menjadi nyaman untuk
menunjukkan
penerimaan dengan cara yang berbeda , seperti yang ditunjukkan pada Gambar 2.9 sebagai entitas asosiatif .
Entitas asosiatif hanya bisa ada jika terhubung ke setidaknya dua entitas lain . Untuk itu
Alasannya , beberapa menyebutnya gerund , persimpangan , persimpangan , atau badan bersambung . kata-kata ini
masuk akal karena tanda terima tidak akan diperlukan kecuali ada seorang pelanggan dan seorang tenaga penjualan
membuat transaksi .
Tipe lain dari entitas adalah atributif . Ketika seorang analis ingin menampilkan data yang benar-benar
tergantung pada keberadaan entitas mendasar , suatu entitas atributif harus digunakan

Sebagai contoh, ketika perpustakaan memiliki beberapa salinan dari buku yang sama, suatu entitas atributif bisa
digunakan untuk menunjuk yang menyalin dari buku yang sedang diperiksa. Entitas atributif berguna untuk
menunjukkan mengulangi kelompok data. Misalnya, kita akan model hubungan
yang ada saat pelindung mendapat tiket untuk konser atau pertunjukan. Entitas tampak jelas pada awalnya: "a
PENDUKUNG dan CONCERT / TAMPILKAN, "seperti yang ditunjukkan pada Gambar 2.10. Seperti apa hubungan ada?
Sekilas PENDUKUNG mendapat reservasi untuk KONSER / TAMPILKAN, dan
KONSER / TAMPILKAN dapat dikatakan telah membuat pemesanan untuk PENDUKUNG a.
Proses ini tidak sesederhana itu, tentu saja, dan diagram ER tidak perlu yang sederhana baik. The
PENDUKUNG benar-benar membuat PEMESANAN, seperti yang ditunjukkan pada Gambar 2.11. PEMESANAN adalah untuk
KONSER / TAMPILKAN. CONCERT / TAMPILKAN memegang PEMESANAN, dan PEMESANAN adalah
dalam nama PENDUKUNG tersebut. Kami menambahkan entitas asosiatif sini karena PEMESANAN sebuah diciptakan
karena sistem informasi yang diperlukan untuk menghubungkan PENDUKUNG dan CONCERT / TAMPILKAN.

Sekali lagi proses ini cukup sederhana, tapi karena konser dan pertunjukan memiliki banyak pertunjukan,
diagram ER ditarik sekali lagi pada Gambar 2.12. Di sini kita menambahkan entitas atributif untuk menangani
banyak pertunjukan dari CONCERT / TAMPILKAN. Dalam hal ini PEMESANAN dibuat untuk
KINERJA tertentu, dan KINERJA adalah salah satu dari banyak yang milik tertentu
KONSER / TAMPILKAN. Pada gilirannya CONCERT / TAMPILKAN memiliki banyak pertunjukan, dan satu KINERJA
memiliki PEMESANAN yang ada di nama PENDUKUNG tertentu.
Di sebelah kanan diagram ER ini adalah satu set data atribut yang membentuk masing-masing entitas.
Beberapa entitas mungkin memiliki atribut yang sama. Atribut yang digarisbawahi dapat dicari
untuk. Atribut yang disebut sebagai kunci dan dibahas dalam Bab 13.
Diagram ER sering digunakan oleh sistem desainer untuk membantu model file atau database. ini
bahkan lebih penting, bagaimanapun, bahwa analis sistem memahami awal kedua entitas dan
hubungan dalam sistem organisasi. Dalam sketsa beberapa diagram ER dasar, analis
perlu:
1. Daftar entitas dalam organisasi untuk mendapatkan pemahaman yang lebih baik dari organisasi.
2. Pilih entitas kunci untuk mempersempit ruang lingkup masalah untuk dikelola dan bermakna
dimensi.
3. Mengidentifikasi apa entitas utama harus.
4. Konfirmasi hasil langkah 1 sampai 3 melalui metode pengumpulan data lainnya
(investigasi, wawancara, pemberian kuesioner, observasi, dan prototyping),
seperti yang dibahas dalam Bab 4 sampai 6.
Sangat penting bahwa analis sistem mulai menggambar diagram ER setelah memasuki organisasi
daripada menunggu sampai database perlu dirancang, karena diagram ER membantu
Analis memahami apa bisnis organisasi sebenarnya dalam, menentukan ukuran dan ruang lingkup
masalah, dan melihat apakah masalah yang tepat sedang ditangani. E-R diagram perlu
untuk dikukuhkan atau direvisi sebagai proses pengumpulan data berlangsung.
USE CASE PEMODELAN
Awalnya diperkenalkan sebagai diagram untuk digunakan dalam UML berorientasi objek, kasus penggunaan kini menjadi
digunakan terlepas dari pendekatan untuk pengembangan sistem. Hal ini dapat digunakan sebagai bagian dari SDLC atau
dalam pemodelan tangkas. Penggunaan kata diucapkan sebagai kata benda (Yoos) daripada kata kerja (yooz). SEBUAH

model use case menggambarkan apa yang sistem lakukan tanpa menjelaskan bagaimana sistem melakukannya; bahwa
adalah, itu adalah model logis dari sistem. (Model logis atau konseptual akan dibahas lebih lanjut
dalam Bab 7.) Model use case mencerminkan pandangan sistem dari perspektif pengguna
di luar sistem (yaitu, persyaratan sistem).
Seorang analis mengembangkan kasus digunakan dalam upaya kerja sama dengan pakar bisnis yang membantu
mendefinisikan
persyaratan sistem. Model use case menyediakan sarana komunikasi yang efektif
antara tim bisnis dan tim pengembangan. Partisi Sebuah model penggunaan kasus
cara sistem bekerja dalam perilaku, layanan, dan tanggapan (kasus penggunaan) yang signifikan
dengan pengguna sistem.
Dari perspektif seorang aktor (atau pengguna), kasus penggunaan harus menghasilkan sesuatu yang dari
nilai. Oleh karena itu, analis harus menentukan apa yang penting bagi pengguna, dan ingat untuk menyertakan
dalam diagram use case. Misalnya, sedang memasuki sesuatu password nilai ke
pengguna? Ini mungkin termasuk jika pengguna memiliki kekhawatiran tentang keamanan atau jika sangat penting untuk
keberhasilan
proyek.
Gunakan Simbol Kasus

Diagram use case berisi aktor dan use case simbol, bersama dengan menghubungkan garis. Aktor
mirip dengan entitas eksternal; mereka ada di luar sistem. Aktor merujuk tertentu
Peran dari pengguna sistem. Sebagai contoh, seorang aktor mungkin seorang karyawan, tetapi juga dapat menjadi
pelanggan di toko perusahaan. Meskipun orang yang sama di dunia nyata, itu diwakili
sebagai dua simbol yang berbeda pada diagram use case, karena orang berinteraksi dengan sistem
dalam peran yang berbeda. Aktor ini ada di luar sistem dan berinteraksi dengan sistem dalam
cara tertentu. Seorang aktor bisa menjadi manusia, sistem lain, atau perangkat seperti keyboard atau Web
koneksi. Aktor dapat memulai sebuah contoh dari kasus penggunaan. Seorang aktor dapat berinteraksi dengan satu atau
lebih
menggunakan kasus, dan kasus penggunaan dapat melibatkan satu atau lebih pelaku.
Aktor dapat dibagi menjadi dua kelompok. Aktor utama menyediakan data atau menerima informasi
dari sistem. Beberapa pengguna langsung berinteraksi dengan sistem (aktor sistem), tapi aktor utama
mungkin juga pengusaha yang tidak secara langsung berinteraksi dengan sistem tetapi memiliki saham di dalamnya. Primer
aktor penting karena mereka adalah orang-orang yang menggunakan sistem dan dapat memberikan rincian
apa kasus penggunaan harus dilakukan. Mereka juga dapat memberikan daftar tujuan dan prioritas. Mendukung aktor
(juga disebut aktor sekunder) membantu untuk menjaga sistem berjalan atau memberikan jasa lainnya. Ini
adalah orang-orang yang menjalankan meja bantuan, analis, programmer, dan sebagainya.
Kadang-kadang hal ini berguna untuk membuat profil aktor yang berisi daftar aktor, latar belakang mereka, dan
keterampilan mereka dalam format tabel sederhana. Ini mungkin berguna untuk memahami bagaimana aktor berinteraksi
dengan
sistem. Contohnya adalah sebuah Spesialis Order Processing. Profil akan, "Seorang pengguna rutin
perangkat lunak, akrab dengan fitur kecil, agar pengecualian, dan kustomisasi ketertiban. "Hal ini
juga berguna untuk daftar aktor dan tujuan dan prioritas mereka. Setiap tujuan mungkin menjadi kasus penggunaan.
Sebuah kasus penggunaan menyediakan pengembang dengan pemandangan apa yang pengguna inginkan. Hal ini bebas
dari teknis atau
rincian implementasi. Kami bisa memikirkan kasus penggunaan sebagai urutan transaksi dalam suatu sistem. The
Penggunaan model kasus didasarkan pada interaksi dan hubungan kasus penggunaan individu.
Sebuah kasus penggunaan selalu menjelaskan tiga hal: seorang aktor yang memulai acara; acara yang memicu
kasus penggunaan; dan kasus penggunaan yang melakukan tindakan dipicu oleh acara tersebut. Dalam kasus penggunaan,
aktor menggunakan sistem memulai sebuah acara yang dimulai serangkaian terkait interaksi dalam sistem.
Gunakan kasus digunakan untuk mendokumentasikan transaksi atau peristiwa tunggal. Sebuah acara merupakan masukan
untuk sistem
yang terjadi pada waktu dan tempat tertentu dan menyebabkan sistem untuk melakukan sesuatu.
Hal ini lebih baik untuk membuat kasus penggunaan lebih sedikit daripada lebih. Sering query dan laporan tidak termasuk;
20 kasus penggunaan (dan tidak lebih dari 40 atau 50) yang cukup untuk sebuah sistem besar. Gunakan kasus mungkin
juga diulang, jika diperlukan. Beberapa kasus penggunaan menggunakan kata kerja berhasil kasus penggunaan kelompok
untuk menambahkan,
menghapus, dan mengubah ke lain, tingkat rendah, diagram use case. Anda dapat menyertakan kasus digunakan pada
beberapa diagram, tetapi kasus penggunaan yang sebenarnya didefinisikan hanya sekali dalam repositori. Sebuah kasus
yang digunakan adalah
dinamai dengan kata kerja dan kata benda.
Gunakan Hubungan Kasus
Hubungan aktif yang disebut sebagai hubungan perilaku dan digunakan terutama dalam kasus penggunaan
diagram. Ada empat tipe dasar dari hubungan perilaku: berkomunikasi, termasuk, meluas,
dan generalisasi. Perhatikan bahwa semua istilah ini kata kerja. Gambar 2.13 menunjukkan panah

dan garis digunakan untuk diagram masing-masing empat jenis hubungan perilaku. Empat hubungan
dijelaskan berikutnya.
Berkomunikasi. Hubungan perilaku berkomunikasi digunakan untuk menghubungkan seorang aktor untuk penggunaan yang
kasus. Ingat bahwa tugas kasus penggunaan adalah untuk memberikan semacam hasil yang bermanfaat bagi
aktor dalam sistem. Oleh karena itu, penting untuk mendokumentasikan hubungan ini antara aktor dan
menggunakan kasus. Dalam contoh pertama kami, Mahasiswa berkomunikasi dengan Mendaftar di Course. Contoh beberapa
komponen dari contoh pendaftaran siswa ditunjukkan dalam diagram use case pada Gambar 2.14.
TERMASUK. Termasuk hubungan (juga disebut menggunakan hubungan) menggambarkan situasi di
yang kasus penggunaan mengandung perilaku yang umum bagi lebih dari satu kasus penggunaan. Dalam kata lain,
kasus penggunaan umum termasuk dalam kasus penggunaan lainnya. Panah Adotted yang menunjuk ke penggunaan umum
kasus menunjukkan meliputi hubungan. Sebuah contoh akan menjadi kasus penggunaan Biaya Pay Mahasiswa yang
termasuk dalam Mendaftar di Kursus dan Atur Perumahan, karena dalam kedua kasus siswa harus membayar
biaya mereka. Ini dapat digunakan oleh beberapa kasus penggunaan. Panah menunjuk ke arah kasus penggunaan umum.
EXTENDS. Meluas hubungan menggambarkan situasi di mana satu kasus penggunaan yang memiliki
perilaku yang memungkinkan kasus penggunaan baru untuk menangani variasi atau pengecualian dari kasus penggunaan
dasar.

Sebagai contoh, diperpanjang kasus penggunaan Asuransi Kesehatan Mahasiswa memperluas dasar kasus penggunaan
Bayar
Biaya siswa. Panah pergi dari diperpanjang untuk kasus penggunaan dasar.
Generalisasi. Hubungan generalisasi menyiratkan bahwa satu hal yang lebih khas dari yang lain
hal. Hubungan ini mungkin ada di antara dua aktor atau dua kasus penggunaan. Misalnya, Part-Time
Mahasiswa generalisasi siswa a. Demikian pula, beberapa karyawan universitas adalah profesor. The
panah menunjuk ke hal umum.
Mengembangkan Sistem Lingkup
Ruang lingkup sistem mendefinisikan batas-batasnya, apa yang ada di lingkup-atau di dalam sistem-dan apa yang
keluar dari ruang lingkup. Proyek ini biasanya memiliki anggaran yang membantu untuk menentukan ruang lingkup, dan awal
dan akhir

waktu. Aktor yang selalu di luar lingkup sistem. Garis berkomunikasi yang menghubungkan aktor
untuk penggunaan kasus adalah batas, dan menentukan ruang lingkup. Sejak diagram use case dibuat
di awal siklus hidup sistem, anggaran, waktu mulai, dan berakhir waktu dapat berubah sebagai proyek
berlangsung; sebagai analis belajar tentang sistem, diagram use case, kasus penggunaan, dan
lingkup dapat berubah.
Mengembangkan Use Case Diagram
Kasus penggunaan utama terdiri dari aliran standar kejadian dalam sistem yang menggambarkan standar
sistem perilaku. Kasus penggunaan utama mewakili normal, diharapkan, dan penyelesaian yang sukses
dari kasus penggunaan.
Ketika diagram kasus penggunaan, mulai dengan meminta pengguna untuk membuat daftar semua sistem harus
lakukan untuk mereka. Hal ini dapat dilakukan dengan menggunakan wawancara, dalam sesi desain aplikasi bersama (seperti
yang dijelaskan
dalam Bab 4), atau melalui sesi tim lain difasilitasi. Analis juga dapat menggunakan cerita tangkas
sesi (dijelaskan dalam Bab 6) untuk mengembangkan kasus penggunaan. Catat yang terlibat dengan setiap penggunaan
kasus, dan tanggung jawab atau jasa kasus penggunaan harus memberikan kepada pelaku atau sistem lainnya. Di
tahap awal, ini mungkin sebagian daftar yang diperluas dalam tahap analisis nanti. Menggunakan
panduan berikut:
1. Tinjau spesifikasi bisnis dan mengidentifikasi para pelaku yang terlibat.
2. Mengidentifikasi peristiwa tingkat tinggi dan mengembangkan kasus penggunaan utama yang menggambarkan peristiwaperistiwa
dan bagaimana para aktor menginisiasi mereka. Hati-hati memeriksa peran yang dimainkan oleh aktor untuk
mengidentifikasi semua kemungkinan kasus penggunaan primer diprakarsai oleh masing-masing aktor. Gunakan kasus
dengan sedikit atau
tidak ada interaksi pengguna tidak harus ditampilkan.
3. Tinjau setiap kasus penggunaan utama untuk menentukan kemungkinan variasi aliran melalui penggunaan
kasus. Dari analisis ini, menetapkan jalur alternatif. Karena aliran peristiwa adalah
biasanya berbeda dalam setiap kasus, mencari kegiatan yang bisa berhasil atau gagal. Juga mencari
setiap cabang dalam logika digunakan kasus di mana hasil yang berbeda yang mungkin.
Jika diagram aliran data konteks tingkat telah dibuat, dapat menjadi titik awal untuk menciptakan
Gunakan alasan. Entitas eksternal adalah aktor potensial. Kemudian memeriksa aliran data untuk menentukan apakah itu
akan memulai kasus penggunaan atau diproduksi oleh kasus penggunaan.
Gambar 2.15 adalah contoh diagram use case yang mewakili sistem yang digunakan untuk merencanakan sebuah
konferensi.
Para aktor adalah Ketua Konferensi, yang bertanggung jawab untuk perencanaan dan pengelolaan konferensi,
Peserta konferensi, Speaker, Keynote Speaker, Hotel Reservasi, dan
Katering. Aktor mewakili peran pengguna memainkan, dan katering mungkin baik karyawan hotel
atau layanan katering eksternal.
Kedua Ketua Konferensi dan Katering yang terlibat dalam perencanaan makan dan perjamuan.
Konferensi Ketua juga bertanggung jawab untuk mengatur speaker. Peserta register untuk
konferensi. Perhatikan bahwa penggunaan kasus Reserve Room terlibat dalam hubungan antara
dengan Atur Speaker dan Registrasi untuk kasus penggunaan Conference, karena kedua pembicara dan peserta
perlu penginapan. The Atur Terjemahan Bahasa kasus penggunaan meluas Register
Konferensi menggunakan kasus karena tidak semua peserta akan membutuhkan layanan penerjemahan bahasa.
Aktor Speaker adalah generalisasi dari Keynote Speaker.
Mengembangkan Gunakan skenario kasus
Setiap kasus penggunaan memiliki deskripsi. Kami akan mengacu pada deskripsi sebagai skenario kasus penggunaan.
Sebagaimana dimaksud,
kasus penggunaan utama mewakili aliran standar peristiwa dalam sistem, dan alternative

jalur menggambarkan variasi untuk perilaku. Gunakan skenario kasus mungkin menggambarkan apa yang terjadi jika item
dibeli adalah keluar dari saham, atau jika perusahaan kartu kredit menolak pembelian pelanggan diminta.
Tidak ada format skenario kasus penggunaan standar, sehingga setiap organisasi dihadapkan dengan menentukan
apa standar harus disertakan. Seringkali kasus penggunaan didokumentasikan menggunakan kasus penggunaan
template dokumen yang telah ditentukan oleh organisasi, yang membuat kasus penggunaan lebih mudah dibaca
dan memberikan informasi standar untuk setiap kasus digunakan dalam model.
Gunakan Tingkat Kasus
Anda mungkin ingin membuat kasus penggunaan untuk tingkat yang berbeda. Salah satu metode (didefinisikan oleh Alistair
Cockburn)
menggunakan metafora ketinggian berikut:
1. Putih adalah tingkat tertinggi, seperti awan. Ini adalah tingkat perusahaan, dan ada mungkin hanya
4-5 untuk seluruh organisasi. Contoh mungkin untuk mengiklankan barang, menjual barang ke
pelanggan, mengelola persediaan, mengelola rantai pasokan, dan mengoptimalkan pengiriman.
2. Kite lebih rendah dari putih tapi masih tingkat tinggi, memberikan gambaran. Penggunaan layang-layang kasus mungkin
berada di unit bisnis atau departemen tingkat dan merupakan ringkasan dari tujuan. Contoh akan
untuk mendaftar siswa, atau jika bekerja dengan sebuah perusahaan perjalanan: membuat sebuah maskapai penerbangan,
hotel, mobil, atau
cruise reservasi.
3. Biru adalah di permukaan laut, dan biasanya dibuat untuk tujuan pengguna. Hal ini sering memiliki bunga terbesar
untuk pengguna dan termudah bagi perusahaan untuk memahami. Hal ini biasanya ditulis untuk bisnis
aktivitas dan setiap orang harus mampu melakukan satu kegiatan tingkat biru di mana saja dari 2 sampai

20 menit. Contohnya adalah mendaftarkan siswa melanjutkan , menambah pelanggan baru , menempatkan item
dalam keranjang belanja , dan ketertiban checkout .

4. Indigo atau ikan adalah kasus penggunaan yang menunjukkan banyak detail, sering pada fungsional atau subfunctional
tingkat . Contohnya adalah memilih kelas , membayar biaya akademik , mencari kode bandara untuk diberikan
kota , dan menghasilkan daftar pelanggan setelah memasukkan nama .
5. Hitam atau kerang , seperti dasar laut , adalah kasus penggunaan yang paling rinci , pada
tingkat subfunction . Contoh mungkin validasi logon aman , menambahkan bidang baru menggunakan
HTML dinamis , atau menggunakan Ajax untuk memperbarui halaman Web dengan cara kecil .
Sebuah contoh skenario kasus penggunaan ditunjukkan pada Gambar 2.16 . Beberapa daerah termasuk adalah opsional ,
dan tidak dapat digunakan oleh semua organisasi . Tiga bidang utama adalah :
1. Header daerah yang mengandung pengidentifikasi kasus dan inisiator .
2. Langkah-langkah yang dilakukan .
3. Sebuah wilayah footer mengandung prasyarat , asumsi , pertanyaan , dan informasi lainnya .

Daerah pertama, menggunakan pengidentifikasi kasus dan inisiator, mengarahkan pembaca dan berisi kasus penggunaan
nama dan ID unik; daerah aplikasi atau sistem yang menggunakan kasus ini milik; aktor yang terlibat
dalam kasus penggunaan; dan pemangku kepentingan yang memiliki tingkat bunga yang tinggi dalam hal penggunaan.
Beberapa
stakeholder pernah berinteraksi langsung dengan sistem, seperti pemegang saham, dewan direksi,
atau manajer penjualan. Setiap aktor utama adalah pemangku kepentingan, tetapi tidak terdaftar di daerah pemangku
kepentingan.
Termasuk tingkat (biru, layang-layang, dan sebagainya) dan deskripsi singkat tentang apa yang menyelesaikan kasus
penggunaan.
Header menyimpulkan dengan memulai (memicu) event, yaitu, apa yang menyebabkan kasus penggunaan
untuk memulai, dan jenis pemicu, baik eksternal atau temporal. Peristiwa eksternal yang dimulai oleh
seorang aktor, baik orang atau sistem lain meminta informasi, seperti reservasi maskapai
Sistem meminta informasi penerbangan dari sistem airline. Peristiwa Temporal adalah mereka yang
dipicu atau dimulai oleh waktu. Peristiwa terjadi pada waktu tertentu, seperti mengirim email tentang khusus
menawarkan seminggu sekali pada hari Minggu malam, mengirimkan tagihan pada hari tertentu, atau menghasilkan
pemerintah
statistik pada tanggal yang ditentukan setiap kuartal.
Wilayah kedua kasus penggunaan mencakup langkah-langkah yang dilakukan, dan informasi yang diperlukan
untuk masing-masing langkah. Pernyataan-pernyataan ini mewakili aliran standar peristiwa dan langkah-langkah yang
diambil
untuk berhasil menyelesaikan kasus penggunaan. Hal ini diinginkan untuk menulis kasus penggunaan untuk utama
jalan, dan kemudian untuk menulis satu untuk masing-masing jalur alternatif secara terpisah, daripada menggunakan
JIKA. . .Kemudian. . . pernyataan. Langkah diberi nomor dengan bilangan bulat. Langkah-langkah mungkin berasal dari rinci
wawancara dengan pengguna atau mungkin berasal dari cerita pemodelan tangkas (seperti yang dijelaskan dalam
Bab 6). Langkah-langkah ini harus ditinjau dengan pengguna untuk klarifikasi.
Analis harus memeriksa setiap langkah dan menentukan informasi yang diperlukan untuk setiap
langkah. Jika analis tidak dapat menentukan informasi, ia harus menjadwalkan wawancara tindak lanjut
dengan pengguna. Beberapa deskripsi use case termasuk ekstensi atau skenario alternatif, dengan
pengecualian sebagai bagian tambahan berikut aliran standar peristiwa. Ini diberi nomor
dengan integer, titik desimal, dan bilangan bulat lain, seperti 3.1, 3.2, 3.3, dan sebagainya. Ini adalah langkah
yang mungkin atau mungkin tidak dapat digunakan. Analis dan pengguna dapat bertukar pikiran apa yang bisa salah dengan
utama
jalan, dan mungkin mengungkap rincian dan kondisi penting. Hal ini diperlukan untuk bekerja dengan pengguna untuk
menentukan apa yang harus dilakukan ketika kondisi ini terjadi. Hal ini membantu untuk mendeteksi kesalahan sebelumnya
dalam kehidupan
siklus.
Gambar 2.17 menggambarkan bagaimana logika dan skenario alternatif dapat dimasukkan di bagian tengah
dari kasus penggunaan. Dalam contoh maskapai ini, melihat bahwa langkah 1 terdiri dari langkah-langkah kecil, banyak
yang didahului dengan "jika." Ini masih di jalan utama, tetapi hanya terjadi jika kondisi ini
bertemu. Misalnya, jika ada banyak bandara yang melayani kota, maka semua bandara akan ditampilkan.
Ekstensi atau skenario alternatif juga bisa muncul di sini. Untuk maskapai ini, skenario lainnya termasuk penerbangan
seleksi, pemilihan kursi, dan seleksi makanan. Gunakan kasus bahkan mungkin termasuk langkah-langkah berulang atau
perulangan.
Luas ketiga kasus penggunaan meliputi:
Prasyarat, atau kondisi sistem sebelum kasus penggunaan dapat dilakukan, yang
mungkin kasus penggunaan lain. Sebuah contoh mungkin, "penampil telah berhasil login ke
sistem, "atau mungkin berhasil menyelesaikan kasus penggunaan lain.
Postconditions, atau keadaan sistem setelah kasus penggunaan telah selesai, termasuk keluaran
orang telah menerima, transmisi ke sistem lain, dan data yang telah dibuat atau
diperbarui. Ini berhubungan dengan tujuan atau kebutuhan pengguna dari definisi masalah
(dijelaskan dalam Bab 3) atau cerita tangkas (dijelaskan dalam Bab 6).
Asumsi yang dibuat yang akan mempengaruhi metode kasus penggunaan dan yang bisa menetapkan
teknologi yang dibutuhkan, seperti persyaratan teknologi minimum dalam browser atau bahkan
versi tertentu atau lebih tinggi dari browser. Sebuah asumsi mungkin bahwa cookies atau JavaScript
diaktifkan. Analis harus menentukan apa yang harus dilakukan jika asumsi tidak terpenuhi. Kapan
menggunakan Google Maps, JavaScript harus diaktifkan. Jika tidak diaktifkan, peta tidak akan
display. Cookie diperlukan oleh Netflix. Halaman Web yang baik akan mendeteksi bahwa asumsi
belum bertemu dan memberitahu penonton dengan pesan, termasuk informasi tentang cara
mengaktifkan cookies atau JavaScript untuk browser yang berbeda.
Jaminan minimal adalah minimum berjanji untuk pengguna. Mereka mungkin tidak senang dengan ini
hasil dan mungkin bahwa tidak ada yang terjadi.
Jaminan Sukses adalah apa yang akan memuaskan pengguna, dan biasanya bahwa tujuan penggunaan
kasus telah dipenuhi.
Setiap isu yang beredar atau pertanyaan harus dijawab sebelum pelaksanaan kasus penggunaan.

 Sebuah pernyataan opsional prioritas kasus penggunaan , yang mungkin berasal dari masalah
definisi atau pengguna persyaratan .
Sebuah pernyataan opsional risiko yang terlibat dalam menciptakan kasus penggunaan .
The "persyaratan bertemu " daerah menghubungkan kasus penggunaan untuk kebutuhan pengguna atau tujuan dari
definisi masalah. Setelah Anda mengembangkan skenario kasus penggunaan , pastikan untuk meninjau hasil Anda dengan
pakar bisnis untuk memverifikasi dan memperbaiki kasus penggunaan jika diperlukan .
Dalam skenario ini menggunakan kasus tertentu , yang disebut Register untuk Konferensi , satu-satunya aktor yang terlibat
adalah Peserta . Daerah keseluruhan Perencanaan Konferensi , dan kasus penggunaan dipicu oleh
peserta log on ke halaman Registrasi Web . Langkah daerah Dilakukan daftar urutan
peristiwa yang harus terjadi untuk pendaftaran konferensi yang sukses . Perhatikan bahwa informasi
diperlukan untuk melakukan setiap langkah-langkah terdaftar di sebelah kanan . Ini mungkin termasuk halaman Web dan
bentuk , serta tabel database dan catatan .

The Prasyarat daerah di bagian footer dari skenario kasus penggunaan daftar apa harus terjadi sebelum
peserta dapat mendaftar untuk konferensi. Dalam contoh ini, peserta harus sudah
mendaftar sebagai anggota masyarakat dan memiliki UserID dan password yang valid. The Postconditions daerah
daftar apa yang telah dicapai oleh kasus penggunaan. Asumsi daerah diskon setiap lokasi dasar
Analis menganggap dipenuhi oleh aktor sebelumnya. Persyaratan daerah Bertemu menunjukkan mengapa ini
kasus penggunaan penting dan diperlukan untuk area bisnis untuk menjadi sukses. Prioritas merupakan indikasi
yang menggunakan kasus harus dikembangkan pertama dan yang mungkin tertunda. Risiko adalah penilaian kasar
apakah mungkin ada masalah atau kesulitan mengembangkan kasus penggunaan. Dalam hal ini, risiko adalah media
karena kasus penggunaan pendaftaran membutuhkan server yang aman dan menerima informasi kartu kredit.
Membuat Deskripsi Use Case
Gunakan empat langkah berikut untuk membuat deskripsi kasus penggunaan:
1. Gunakan cerita tangkas, tujuan definisi masalah, kebutuhan pengguna, atau daftar fitur sebagai
titik pangkal.
2. Tanyakan tentang tugas-tugas yang harus dilakukan untuk mencapai transaksi. Tanyakan apakah kasus penggunaan
membaca data atau update setiap tabel.
3. Cari tahu apakah ada tindakan berulang atau perulangan.
4. use case berakhir ketika tujuan pelanggan selesai.
Mengapa Gunakan Case Diagram Apakah Bermanfaat
Tidak peduli apa metode yang Anda gunakan untuk mengembangkan sistem anda (metode SDLC tradisional, metode
tangkas,
atau berorientasi objek metode), Anda akan menemukan bahwa kasus penggunaan yang sangat berharga. Diagram use case
mengidentifikasi semua aktor dalam domain masalah, dan analis sistem dapat berkonsentrasi pada
apa yang manusia inginkan dan perlu menggunakan sistem, memperluas kemampuan mereka, dan menikmati interaksi
mereka
dengan teknologi.
Tindakan yang harus diselesaikan juga jelas ditunjukkan pada diagram use case. Ini
tidak hanya memudahkan analis untuk mengidentifikasi proses, tetapi juga membantu dalam komunikasi dengan
analis lain di tim dan bisnis eksekutif.
Skenario use case juga bermanfaat. Karena banyak informasi pengguna memberikan kepada
analis sudah mengambil bentuk cerita, mudah untuk menangkap cerita di skenario kasus penggunaan
untuk m. Skenario use case selalu mendokumentasikan peristiwa yang memicu sehingga analis selalu bisa
melacak langkah-langkah yang mengarah ke kasus penggunaan lainnya. Karena langkah-langkah yang dilakukan dicatat,
adalah mungkin untuk mempekerjakan
menggunakan skenario kasus untuk menulis proses logis.
Diagram use case menjadi populer karena kesederhanaan mereka dan kurangnya detail teknis.
Mereka digunakan untuk menunjukkan ruang lingkup sistem, bersama dengan fitur-fitur utama dari sistem dan
aktor yang bekerja dengan fitur-fitur utama. Para pengguna melihat sistem dan mereka dapat bereaksi
dan memberikan umpan balik. Mereka juga dapat membantu untuk menentukan apakah akan membangun atau membeli
perangkat lunak.
Alasan utama untuk menulis kasus penggunaan ditunjukkan pada Gambar 2.18.
TINGKAT MANAJEMEN
Manajemen dalam organisasi ada pada tiga, tingkat horisontal yang luas: pengendalian operasional, manajerial
perencanaan dan pengendalian (manajemen menengah), dan manajemen strategis, seperti yang ditunjukkan pada
Gunakan kasus secara efektif berkomunikasi persyaratan sistem karena diagram yang
dibuat sederhana.
Gunakan kasus memungkinkan orang untuk bercerita.
Gunakan cerita kasus masuk akal untuk orang non-teknis.
Gunakan kasus tidak tergantung pada bahasa khusus.
Gunakan kasus dapat menggambarkan persyaratan yang paling fungsional (seperti interaksi antara
aktor dan aplikasi).
Gunakan kasus dapat menggambarkan kebutuhan nonfungsional (seperti kinerja dan
rawatan) melalui penggunaan stereotip.
Gunakan kasus membantu analis mendefinisikan batas-batas.
Gunakan kasus dapat dilacak, memungkinkan analis untuk mengidentifikasi hubungan antara kasus penggunaan dan
desain dan dokumentasi alat-alat lain.

Dimana Ada Carbon, Ada Menyalin

"Saya tidak tahu apa yang kita lakukan dengan yang
merah muda lagi," Richard Russell
mengakui. "Mereka adalah bagian dari bentuk rangkap
empat yang merobek terpisah.
Yang saya tahu adalah bahwa kita menjaga mereka untuk
petugas arsip, dan dia file
mereka ketika ia punya waktu. "
Richard adalah account executive junior yang baru direkrut
untuk Carbon,
Karbon & Rippy, rumah broker. Anda berjalan melalui
langkah ia mengambil dalam membuat pembelian saham
"resmi" karena nya
Bos meminta Anda untuk merampingkan proses dimana
pembelian saham
informasi disimpan dalam sistem komputer dan diambil.
Setelah Anda meninggalkan, Richard terus berpikir tentang
merah muda
bentuk. Dia mengatakan petugas nya, Harry Schultz,
"Dalam dua bulan saya di sini, saya
tidak melihat orang menggunakan mereka. Mereka
mengambil waktu saya dan Anda, tidak
untuk menyebutkan semua ruang pengajuan. Mari kita
pitch mereka. "
Richard dan Harry melanjutkan untuk membuka semua file
lama disimpan oleh
Pendahulunya Richard dan membuang bentuk merah muda
mengajukan, bersama dengan
mereka akumulasi tetapi belum mengajukan. Dibutuhkan
jam, tapi mereka membuat

banyak ruang. "Pasti layak waktu," Richard meyakinkan

Harry.
Tiga minggu kemudian, asisten bos Richard, Carol Vaness,
muncul. Richard senang melihat wajah yang familier,
ucapan dia dengan,
"Hai, Carol. Apa yang baru?"
"Hal lama yang sama," Carol mendesah. "Yah, saya kira itu
tidak tua untuk Anda,
karena Anda pendatang baru. Tapi aku butuh semua orang
sial merah muda
bentuk. "
Hampir shock, Richard pertukaran penampilan dengan
Harry, maka
bergumam, "Kau bercanda, tentu saja."
Carol tampak lebih serius dari Richard pernah berpikir
mungkin,
menjawab, "Tidak ada lelucon. Saya merangkum semua
bentuk merah muda dari semua broker,
dan kemudian total saya dibandingkan dengan pembelian
saham komputerisasi
Informasi. Ini bagian dari rutinitas, pemeriksaan tiga bulan
untuk
akurasi transaksi. Pekerjaan saya tergantung pada Anda.
Tidak Ms. MCCue menjelaskan bahwa untuk Anda ketika Anda mulai? "
Sistem apa konsep itu Richard dan Harry mengabaikan saat
melemparkan keluar bentuk merah muda? Apa
konsekuensi yang mungkin
untuk sistem analis jika sistem umum konsep diabaikan?

Gambar 2.19. Setiap tingkat membawa tanggung jawab sendiri, dan semua bekerja untuk mencapai organisasi
tujuan dan sasaran dengan cara mereka sendiri.
Pengendalian operasional membentuk tingkat bawah manajemen bertingkat tiga. Manajer operasi
membuat keputusan menggunakan aturan yang telah ditetapkan yang memiliki hasil diprediksi ketika diimplementasikan
benar.
Mereka membuat keputusan yang mempengaruhi implementasi dalam penjadwalan kerja, inventory control, pengiriman,
menerima, dan pengendalian proses seperti produksi. Manajer operasi mengawasi
Rincian operasi organisasi.
Manajemen menengah membentuk kedua, atau menengah, tingkat manajemen bertingkat tiga
sistem. Manajer menengah membuat perencanaan dan pengendalian keputusan jangka pendek tentang bagaimana sumber
mungkin terbaik dialokasikan untuk memenuhi tujuan organisasi.
Keputusan mereka berkisar sepanjang jalan dari peramalan kebutuhan sumber daya masa depan untuk memecahkan
masalah karyawan yang mengancam produktivitas. Pengambilan keputusan domain dari manajer menengah
dapat berguna dicirikan sebagai sebagian operasional dan sebagian strategis, dengan fluktuasi konstan.

Manajemen strategis adalah tingkat ketiga kontrol manajemen bertingkat tiga. Manajer strategis
melihat ke luar dari organisasi ke masa depan, membuat keputusan yang akan memandu tengah
dan manajer operasi di bulan dan tahun-tahun mendatang.
Manajer strategis bekerja di lingkungan pengambilan keputusan yang sangat tidak pasti. Melalui pernyataan
tujuan dan penentuan strategi dan kebijakan untuk mencapai mereka, manajer strategis
sebenarnya mendefinisikan organisasi secara keseluruhan. Mereka adalah gambaran luas, dimana
perusahaan memutuskan untuk mengembangkan lini produk baru, melepaskan diri dari usaha tidak menguntungkan,
memperoleh
perusahaan lain yang kompatibel, atau bahkan membiarkan dirinya untuk diakuisisi atau merger.
Ada kontras yang tajam antara pengambil keputusan di banyak dimensi. Contohnya,
manajer strategis memiliki tujuan keputusan beberapa, sedangkan manajer operasi harus tunggal
yang. Hal ini sering sulit bagi manajer tingkat tinggi untuk mengidentifikasi masalah, tetapi mudah untuk operasi
manajer untuk melakukannya. Manajer strategis dihadapkan dengan masalah semiterstruktur, sedangkan lowerlevel
manajer menangani sebagian besar dengan masalah terstruktur.
Alternatif solusi untuk masalah yang dihadapi manajer strategis seringkali sulit untuk mengartikulasikan,
tetapi alternatif yang manajer operasi bekerja dengan biasanya mudah untuk menghitung.
Manajer strategis yang paling sering membuat keputusan satu kali, sedangkan keputusan yang dibuat oleh operasi
manajer cenderung berulang.
Implikasi bagi Pengembangan Sistem Informasi
Masing-masing dari tiga tingkat manajemen memiliki implikasi yang berbeda-beda untuk mengembangkan sistem informasi.
Beberapa persyaratan informasi untuk manajer jelas, sedangkan yang lain kabur
dan tumpang tindih.
Manajer operasi membutuhkan informasi internal yang dari berulang, tingkat rendah alam. Mereka

sangat tergantung pada informasi yang menangkap kinerja saat ini, dan mereka adalah pengguna besar
online, sumber daya informasi real-time. Kebutuhan manajer operasi untuk kinerja masa lalu
informasi dan informasi periodik hanya moderat. Mereka memiliki sedikit digunakan untuk informasi eksternal
yang memungkinkan proyeksi masa depan.
Pada tingkat manajemen berikutnya, manajer menengah yang membutuhkan jangka panjang-pendek dan baik
Informasi. Karena sifat pemecahan masalah dari pekerjaan mereka, manajer menengah mengalami sangat
kebutuhan tinggi untuk informasi secara real time. Untuk mengontrol dengan baik, mereka juga membutuhkan informasi saat
ini
kinerja yang diukur terhadap standar yang ditetapkan. Manajer menengah sangat tergantung
informasi internal. Berbeda dengan manajer operasi, mereka memiliki kebutuhan tinggi untuk sejarah
informasi, bersama dengan informasi yang memungkinkan untuk prediksi kejadian masa depan dan simulasi
dari berbagai skenario yang mungkin.
Manajer strategis agak berbeda dari kedua operasi menengah dan manajer informasi mereka
persyaratan. Mereka sangat tergantung pada informasi dari sumber eksternal yang
berita pasokan tren pasar dan strategi perusahaan-perusahaan yang bersaing. Karena tugas
strategis mengelola tuntutan proyeksi ke masa depan yang tidak pasti, manajer strategis memiliki tinggi
butuhkan untuk informasi yang bersifat prediktif dan informasi yang memungkinkan penciptaan berbagai berbeda
apa-jika skenario. Manajer strategis juga menunjukkan kebutuhan yang kuat untuk informasi yang dilaporkan secara berkala
karena mereka berusaha untuk beradaptasi dengan perubahan yang bergerak cepat.
BUDAYA ORGANISASI
Budaya organisasi adalah daerah didirikan penelitian yang telah berkembang sangat dalam lalu
generasi. Sama seperti itu adalah tepat untuk memikirkan organisasi sebagai termasuk banyak teknologi, itu adalah
sama yang tepat untuk melihat mereka sebagai tuan rumah untuk beberapa, sering bersaing subkultur.
Masih ada sedikit kesepakatan tentang apa tepatnya merupakan suatu subkultur organisasi. ini
setuju, bagaimanapun, bahwa subkultur bersaing mungkin dalam konflik, berusaha untuk mendapatkan penganut
visi mereka tentang apa yang organisasi harus. Penelitian sedang berlangsung untuk menentukan dampak
organisasi virtual dan tim virtual pada penciptaan subkultur ketika anggota tidak
berbagi ruang kerja fisik tetapi berbagi tugas.
Daripada berpikir tentang budaya secara keseluruhan, itu lebih berguna untuk berpikir tentang melalui penelitian
penentu subkultur, seperti bersama simbolisme verbal dan nonverbal. Simbolisme Verbal mencakup
bahasa bersama digunakan untuk membangun, menyampaikan, dan melestarikan subkultur mitos, metafora, visi,
dan humor. Simbolisme nonverbal meliputi artefak bersama, ritual, dan upacara; pakaian
Piramida Daya
"Kami benar-benar memandang Anda," kata Paul Legon.
Sebagai seorang analis sistem,
Anda telah diundang untuk membantu Pyramid, Inc, kecil,
independen
perusahaan buku-publishing yang mengkhususkan diri
dalam buku-buku paperback
luar arus utama penerbitan.
Paulus melanjutkan, "Kita berurusan dengan apa yang
beberapa orang berpikir ini adalah pinggiran
topik. Anda tahu, kekuatan piramida, akhir-of-the-dunia
nubuat, dan
sehat hidup dengan memikirkan warna pink. Kadangkadang ketika orang
melihat buku-buku kami, mereka hanya menggelengkan
kepala mereka dan berkata, 'Tut-jarang
topik. "Tapi kami tidak budak untuk setiap filsafat tertentu,
dan
kami sudah sangat sukses. Begitu banyak sehingga karena
aku 24, orang
memanggil saya 'anak raja.' "Paul berhenti untuk
menguraikan reaksi Anda.
Paulus melanjutkan, "Saya di bagian atas sebagai presiden,
dan bidang fungsional
seperti editorial, akuntansi, produksi, dan pemasaran
berada di bawah saya. "
Asisten Paulus, Ceil Toom, yang telah mendengarkan diamdiam up
sekarang, tongkang dengan komentarnya: "Para ahli sistem
terakhir yang
melakukan proyek bagi kita merekomendasikan
pembentukan komite penghubung

karyawan antara akuntansi, produksi, dan pemasaran,

sehingga
bahwa kita bisa berbagi baru terkomputerisasi persediaan
dan angka penjualan
seluruh organisasi. Mereka mengklaim bahwa komite
seperti itu
akan mengurangi duplikasi perlu output, dan masingmasing fungsional
daerah akan lebih baik diintegrasikan dengan semua yang
lain. "
Paul mengambil cerita, mengatakan, "Itu wajar-oh, untuk
sementaradan karyawan bersama informasi, tetapi alasan Anda di sini
adalah
bahwa karyawan mengatakan mereka tidak punya waktu
untuk pertemuan komite
dan berbagi informasi tidak nyaman dengan orang-orang
dari
departemen lain yang lebih jauh tangga daripada mereka
di sini di Pyramid. "
Menurut Paul dan Ceil, apa efek menginstal
sistem informasi manajemen di Pyramid, Inc, yang
diperlukan
orang untuk berbagi informasi dengan cara yang tidak
konsisten dengan
struktur mereka? Mengusulkan beberapa cara umum untuk
mengatasi masalah ini
sehingga karyawan Pyramid masih bisa mendapatkan
penjualan dan persediaan
angka yang mereka butuhkan

pengambil keputusan dan pekerja; penggunaan, penempatan, dan dekorasi kantor; dan ritual untuk merayakan
anggota 'ulang tahun, promosi, dan pensiun.
Subkultur hidup berdampingan dalam "resmi" budaya organisasi. Budaya resmi sanksi
mungkin meresepkan kode berpakaian, cara yang tepat untuk mengatasi atasan dan rekan kerja, dan tepat
cara untuk berurusan dengan masyarakat luar. Subkultur mungkin penentu kuat informasi
persyaratan, ketersediaan, dan penggunaan.
Anggota organisasi mungkin milik satu atau lebih subkultur dalam organisasi. Subkultur
mungkin memberikan pengaruh kuat terhadap perilaku anggota, termasuk sanksi untuk atau terhadap
penggunaan sistem informasi.
Memahami dan mengakui subkultur organisasi dominan dapat membantu sistem
Analis mengatasi perlawanan untuk mengubah itu muncul ketika sistem informasi baru dipasang.
Sebagai contoh, analis mungkin merancang pelatihan pengguna untuk mengatasi masalah spesifik
subkultur organisasi. Mengidentifikasi subkultur juga dapat membantu dalam desain pendukung keputusan
sistem yang dirancang untuk interaksi dengan kelompok pengguna tertentu.
RINGKASAN
Ada tiga dasar organisasi yang luas untuk dipertimbangkan ketika menganalisis dan merancang informasi
sistem: konsep organisasi sebagai sistem, berbagai tingkat manajemen, dan keseluruhan organisasi
budaya.
Organisasi adalah sistem yang kompleks yang terdiri dari subsistem yang saling terkait dan saling tergantung. Tambahan
lagi,
sistem dan subsistem yang ditandai dengan lingkungan internal mereka pada kontinum dari terbuka untuk
tertutup. Sistem terbuka memungkinkan bagian bebas dari sumber daya (orang, informasi, bahan) melalui batas-batasnya;
sistem tertutup tidak memungkinkan aliran bebas dari input atau output. Organisasi dan tim juga dapat diatur
hampir dengan anggota yang terhubung secara elektronik yang tidak di ruang kerja fisik yang sama.
Sistem perencanaan sumber daya perusahaan adalah sistem organisasi (perusahaan) informasi yang terintegrasi yang
dikembangkan
dengan disesuaikan, software proprietary yang membantu aliran informasi antara area fungsional
dalam organisasi. Mereka mendukung pandangan sistem organisasi.

PERTANYAAN REVIEW
1. Apakah tiga kelompok fundamental organisasi yang membawa implikasi bagi pengembangan
sistem informasi?
2. Apa yang dimaksud dengan mengatakan bahwa subsistem organisasi saling terkait dan saling tergantung?
3. Tentukan batas organisasi jangka.
4. Apa dua tujuan utama untuk umpan balik dalam organisasi?
5. Tentukan keterbukaan dalam lingkungan organisasi.
6. Tentukan ketertutupan dalam lingkungan organisasi.
7. Apa perbedaan antara organisasi tradisional dan satu virtual?
8. Apa manfaat potensial dan kelemahan dari organisasi virtual?
9. Berikan contoh bagaimana sistem analis bisa bekerja dengan pengguna sebagai tim virtual.
10. Apa sistem perusahaan?
11. Apa ERP, dan apa tujuannya?
12. Apa masalah yang analis sering menghadapi ketika mereka mencoba untuk menerapkan paket ERP?
13. Apa dua simbol pada penggunaan diagram kasus, dan apa yang mereka wakili?
14. Apa skenario kasus penggunaan?
15. Apakah tiga bagian utama dari skenario kasus penggunaan?
16. Apa empat langkah dalam menciptakan deskripsi kasus penggunaan?
17. Apakah lima metafora untuk menggambarkan ketinggian kasus penggunaan pada tingkat yang berbeda? Apa yang
mereka
mewakili?
18. Apa proses mewakili pada diagram aliran data konteks tingkat?
19. Apakah yang dimaksud dengan entitas pada diagram aliran data?
20. Apa yang dimaksud dengan istilah diagram entitas-hubungan?
21. simbol apa yang digunakan untuk menggambar E-R diagram?
22. Daftar jenis E-R diagram.
23. Bagaimana suatu entitas, entitas asosiatif, dan entitas atributif berbeda?
24. Daftar tiga, tingkat horisontal yang luas dari manajemen dalam organisasi.
25. Bagaimana bisa memahami subkultur organisasi membantu dalam desain sistem informasi?
Chap 3
RINGKASAN
Lima fundamental manajemen proyek besar bahwa analis sistem harus menangani adalah (1) proyek initiationmendefinisikan masalah, (2) menentukan kelayakan proyek, (3) perencanaan dan pengendalian aktivitas, (4) proyek
anggota penjadwalan, dan (5) tim analisis sistem pengelolaan. Ketika dihadapkan dengan pertanyaan tentang bagaimana
bisnis dapat memenuhi tujuan mereka dan memecahkan masalah sistem, analis menciptakan definisi masalah. Masalah
definisi adalah pernyataan resmi dari masalah, termasuk (1) isu situasi sekarang, (2)
tujuan untuk setiap masalah, (3) persyaratan yang harus disertakan dalam semua sistem yang diusulkan, dan (4) kendala

bahwa pengembangan sistem batas.

Memilih proyek adalah keputusan yang sulit, karena lebih banyak proyek akan diminta daripada benar-benar dapat
dilakukan. Lima kriteria penting untuk pemilihan proyek (1) bahwa proyek yang diminta didukung oleh manajemen,
(2) bahwa itu diberi batas waktu tepat untuk komitmen sumber daya, (3) bahwa itu bergerak ke arah bisnis
pencapaian tujuannya, (4) yang praktis, dan (5) bahwa itu cukup penting untuk dipertimbangkan lebih lainnya
proyek mungkin.
Jika proyek diminta memenuhi kriteria tersebut, studi kelayakan operasionalnya, teknis, dan ekonomi
manfaat dapat dilakukan. Melalui studi kelayakan, analis sistem mengumpulkan data yang memungkinkan manajemen untuk
memutuskan apakah akan melanjutkan dengan studi sistem penuh. Dengan inventarisasi peralatan sudah di tangan dan
pada urutan,
analis sistem akan dapat lebih baik menentukan apakah baru, dimodifikasi, atau perangkat keras komputer saat ini
adalah untuk direkomendasikan.
Hardware komputer dapat diperoleh melalui pembelian, sewa, atau sewa. Vendor akan memasok dukungan
layanan seperti pemeliharaan preventif dan pelatihan pengguna yang biasanya dinegosiasikan secara terpisah. Perangkat
lunak
dapat dibuat sebagai produk kustom, dibeli sebagai off-the-rak komersial (COTS) paket perangkat lunak, atau
outsourcing untuk penyedia layanan aplikasi (ASP).
Mempersiapkan proposal sistem berarti mengidentifikasi semua biaya dan manfaat dari sejumlah alternatif.
Analis sistem memiliki sejumlah metode yang tersedia untuk meramalkan masa depan biaya, manfaat, volume
transaksi, dan variabel ekonomi yang mempengaruhi biaya dan manfaat. Biaya dan manfaat dapat berwujud

PERTANYAAN REVIEW
1. Apakah lima dasar proyek besar?
2. Daftar tiga cara untuk mencari tahu tentang masalah atau peluang yang mungkin panggilan untuk solusi sistem.
3. Buatlah daftar lima kriteria untuk pemilihan proyek sistem.
4. Tentukan kelayakan teknis.
5. Tentukan kelayakan ekonomi.
6. Tentukan kelayakan operasional.
7. Daftar empat kriteria untuk mengevaluasi perangkat keras sistem.
8. Apakah tiga pilihan utama untuk akuisisi perangkat keras komputer?
9. Apa COTS berdiri?
10. Apa ASP berdiri untuk dalam hal pengiriman perangkat lunak?
11. Tentukan biaya dan manfaat yang nyata. Berikan contoh masing-masing.
12. Tentukan biaya tak berwujud dan manfaat. Berikan contoh masing-masing.
13. Daftar empat teknik untuk membandingkan biaya dan manfaat dari sistem yang diusulkan.
14. Kapan analisis impas berguna?
15. Apakah tiga kelemahan dari menggunakan metode payback?
16. Kapan analisis arus kas yang digunakan?
17. Sebagai pedoman umum, ketika harus menyajikan analisis nilai digunakan?
18. Apa yang dimaksud dengan grafik Gantt?
19. Ketika adalah diagram PERT berguna untuk proyek-proyek sistem?
20. Daftar tiga keuntungan menggunakan diagram PERT lebih bagan Gantt untuk proyek-proyek sistem penjadwalan.
21. Tentukan jalur jangka kritis.
22. Bagaimana seorang manajer proyek menilai risiko hal yang salah dan mengambil yang menjadi pertimbangan
ketika merencanakan waktu yang dibutuhkan untuk menyelesaikan proyek?
23. Daftar dua jenis pemimpin tim.
24. Yang dimaksud dengan norma tim disfungsional?
25. Apa yang dimaksud dengan proses tim?
26. Apa tiga alasan bahwa pengaturan tujuan tampaknya memotivasi analisis sistem anggota tim?
27. Apa empat cara di mana manajemen proyek e-commerce berbeda dari proyek tradisional
manajemen?
28. Unsur-unsur apa yang terkandung dalam piagam proyek?