CHAPTER 2 (Memahami dan Memodelkan Sistem Organisasi)

ORGANISASI SEBAGAI SISTEM

Organisasi dan anggotanya secara bermanfaat dikonseptualisasikan sebagai sistem

yang dirancang untuk mencapai tujuan dan sasaran yang telah ditentukan sebelumnya
melalui orang dan sumber daya lain yang mereka gunakan. Organisasi terdiri dari
sistem yang lebih kecil dan saling terkait (departemen, unit, divisi, dll.) Yang
melayani fungsi khusus. Fungsi yang umum termasuk akuntansi, pemasaran, produksi,
pemrosesan data, dan manajemen. Fungsi khusus (sistem yang lebih kecil) pada
akhirnya diintegrasikan melalui berbagai cara untuk membentuk keseluruhan
organisasi yang efektif.

Pentingnya organisasi konseptualisasi sebagai sistem yang kompleks adalah bahwa

prinsip-prinsip sistem memungkinkan wawasan tentang bagaimana organisasi bekerja.
Untuk memastikan persyaratan informasi dengan benar dan untuk merancang sistem
informasi yang tepat, adalah sangat penting untuk memahami organisasi secara
keseluruhan. Semua sistem terdiri dari subsistem (yang termasuk sistem informasi);
Oleh karena itu, ketika mempelajari suatu organisasi, kami juga memeriksa
bagaimana sistem yang lebih kecil terlibat dan bagaimana mereka berfungsi.

Keterkaitan dan Interdependensi Sistem

Semua sistem dan subsistem saling terkait dan saling bergantung. Fakta ini memiliki
implikasi penting baik bagi organisasi maupun bagi analis sistem yang berusaha
membantu mereka mencapai tujuan mereka dengan lebih baik. Ketika elemen apa pun
dari sistem diubah atau dihilangkan, elemen dan subsistem sistem lainnya juga
terpengaruh secara signifikan.

Sebagai contoh, anggaplah bahwa manajer suatu organisasi memutuskan untuk tidak
lagi mempekerjakan asisten administrasi dan mengganti fungsi mereka dengan PC
berjaringan. Keputusan ini memiliki potensi untuk secara signifikan mempengaruhi
tidak hanya asisten administrasi dan manajer tetapi juga semua anggota organisasi
yang membangun jaringan komunikasi dengan asisten yang sekarang berangkat.

Semua sistem memproses input dari lingkungan mereka. Menurut definisi, proses
mengubah atau mengubah input menjadi output. Setiap kali Anda memeriksa suatu
sistem, periksa untuk melihat apa yang sedang diubah atau diproses. Jika tidak ada
perubahan, Anda mungkin tidak mengidentifikasi proses. Proses khas dalam sistem
termasuk verifikasi, pemutakhiran, dan pencetakan.

Aspek lain dari organisasi sebagai sistem adalah bahwa semua sistem dikandung oleh
batasan yang memisahkan mereka dari lingkungan mereka. Batas-batas organisasi ada
pada suatu rangkaian mulai dari yang sangat permeabel sampai hampir kedap air.
Untuk terus beradaptasi dan bertahan hidup, organisasi harus dapat terlebih dahulu
mengimpor orang, bahan mentah, dan informasi melalui batasan (input) mereka, dan
kemudian menukarkan produk jadi, layanan, atau informasi mereka dengan dunia luar
(output).

Umpan balik adalah salah satu bentuk kontrol sistem. Sebagai sistem, semua
organisasi menggunakan perencanaan dan kontrol untuk mengelola sumber daya
mereka secara efektif. Gambar 2.1 menunjukkan bagaimana output sistem digunakan
sebagai umpan balik yang membandingkan kinerja dengan sasaran. Perbandingan ini
pada gilirannya membantu manajer merumuskan tujuan yang lebih spesifik sebagai
input. Contohnya adalah perusahaan manufaktur AS yang memproduksi merah putih
dan biru set latihan beban serta set abu-abu logam-senjata. Perusahaan menemukan itu
tahun setelah Olimpiade, sangat sedikit set merah-putih-dan-biru yang dibeli. Manajer
produksi menggunakan informasi itu sebagai umpan balik untuk membuat keputusan
tentang berapa jumlah setiap warna yang dihasilkan. Umpan balik dalam hal ini
berguna untuk perencanaan dan kontrol.

Namun, sistem yang ideal adalah sistem yang mengoreksi diri atau mengatur diri
sendiri sedemikian rupa sehingga keputusan tentang kejadian yang khas tidak
diperlukan. Contohnya adalah sistem rantai pasokan untuk perencanaan produksi yang
memperhitungkan permintaan saat ini dan proyeksi dan merumuskan solusi yang
diusulkan sebagai output. Produsen pakaian rajut Italia yang memasarkan pakaiannya
di Amerika Serikat hanya memiliki sistem seperti itu. Perusahaan ini memproduksi
sebagian besar sweternya dalam warna putih, menggunakan sistem informasi
inventaris yang terkomputerisasi untuk mencari tahu warna apa yang paling laku, dan
kemudian mewarnai sweater dalam warna laris segera sebelum mengirimnya.

Umpan balik diterima dari dalam organisasi dan dari lingkungan luar di sekitarnya.
Apa pun di luar batas organisasi dianggap sebagai lingkungan. Banyak lingkungan,
dengan berbagai tingkat stabilitas, merupakan lingkungan di mana organisasi ada.

Di antara lingkungan-lingkungan ini adalah (1) lingkungan masyarakat di mana

organisasi secara fisik terletak, yang dibentuk oleh ukuran penduduknya dan profil
demografisnya, termasuk faktor-faktor seperti pendidikan dan pendapatan rata-rata; (2)
lingkungan ekonomi, dipengaruhi oleh faktor pasar, termasuk persaingan; (3)
lingkungan politik, dikontrol melalui pemerintah negara bagian dan lokal; dan (4)
lingkungan hukum, menerbitkan undang-undang dan pedoman federal, negara bagian,
regional, dan lokal. Meskipun perubahan dalam status lingkungan dapat direncanakan
untuk, mereka sering tidak dapat dikontrol langsung oleh organisasi.

FIGURE 2.1

CONSULTING OPPURTUNITY 2,1

Terkait dan mirip dengan konsep permeabilitas batas eksternal adalah konsep
keterbukaan internal atau ketertutupan organisasi. Keterbukaan dan ketertutupan juga
ada pada suatu kontinum, karena tidak ada organisasi yang benar-benar terbuka atau
sepenuhnya tertutup.

Keterbukaan mengacu pada aliran bebas informasi dalam organisasi. Subsistem

seperti departemen kreatif atau seni sering dicirikan sebagai terbuka, dengan aliran ide
bebas di antara para peserta dan sangat sedikit pembatasan pada siapa mendapat
informasi apa pada waktu kapan proyek kreatif masih dalam tahap awal.

Di ujung kontinum mungkin unit departemen pertahanan yang ditugaskan untuk

bekerja pada perencanaan pertahanan rahasia yang mempengaruhi keamanan nasional.
Setiap orang perlu menerima izin, informasi yang tepat waktu adalah suatu kebutuhan,
dan akses ke informasi hanya berdasarkan "perlu mengetahui". Unit semacam ini
dibatasi oleh banyak aturan.

Menggunakan system overlay untuk memahami organisasi memungkinkan kita untuk

mengakui gagasan sistem yang terdiri dari subsistem; kesalingterkaitan dan
interdependensi mereka; keberadaan batas-batas yang memungkinkan atau mencegah
interaksi antara berbagai departemen dan elemen subsistem dan lingkungan lain; dan
keberadaan lingkungan internal yang dicirikan oleh derajat keterbukaan dan
ketertutupan, yang mungkin berbeda antar departemen, unit, atau bahkan sistem
proyek.

Organisasi Virtual dan Tim Virtual

Tidak semua organisasi atau bagian organisasi terlihat di lokasi fisik. Seluruh
organisasi atau unit organisasi kini dapat memiliki komponen virtual yang
memungkinkan mereka mengubah konfigurasi untuk beradaptasi dengan perubahan
proyek atau permintaan pasar. Perusahaan virtual menggunakan jaringan komputer
dan teknologi komunikasi untuk membawa orang-orang dengan keterampilan khusus
bersama secara elektronik untuk bekerja pada proyek-proyek yang secara fisik tidak
terletak di tempat yang sama. Teknologi informasi memungkinkan koordinasi dari
anggota tim jarak jauh ini. Seringkali tim virtual bermunculan di organisasi yang
sudah mapan; dalam beberapa contoh, organisasi pekerja jarak jauh dapat berhasil
tanpa investasi tradisional di fasilitas fisik.

Ada beberapa manfaat potensial untuk organisasi virtual, seperti kemungkinan

mengurangi biaya fasilitas fisik, respons yang lebih cepat terhadap kebutuhan
pelanggan, dan membantu karyawan virtual untuk memenuhi kewajiban keluarga
mereka terhadap pertumbuhan anak-anak atau orang tua yang menua. Betapa
pentingnya untuk memenuhi kebutuhan sosial pekerja virtual masih terbuka untuk
penelitian dan perdebatan. Salah satu contoh kebutuhan untuk identifikasi yang nyata
dengan budaya muncul ketika siswa yang terdaftar di universitas virtual online, tanpa
kampus fisik (atau tim olahraga), terus meminta barang-barang seperti kaus, cangkir
kopi, dan panji-panji dengan logo universitas maya dicantumkan
pada mereka. Barang-barang ini adalah artefak budaya yang berarti yang sudah lama
disediakan sekolah-sekolah tradisional dari bata dan mortir.

Banyak tim analisis dan tim desain sekarang dapat bekerja secara virtual, dan
nyatanya, banyak dari mereka menandai jalan bagi jenis karyawan lain untuk
mengikuti dalam menyelesaikan pekerjaan secara virtual. Beberapa aplikasi
mengizinkan analis yang memberikan bantuan teknis melalui Web untuk "melihat"
konfigurasi perangkat lunak dan perangkat keras dari pengguna yang meminta
bantuan, dengan cara ini menciptakan tim virtual ad hoc yang terdiri dari analis dan
pengguna.

Mengambil Perspektif Sistem

Mengambil perspektif sistem memungkinkan analis sistem untuk mulai

mengklarifikasi dan memahami secara luas berbagai bisnis yang akan mereka hubungi.
Adalah penting bahwa anggota subsistem menyadari bahwa pekerjaan mereka saling
terkait. Perhatikan pada Gambar 2.2 bahwa output dari subsistem produksi berfungsi
sebagai input untuk pemasaran dan bahwa output pemasaran berfungsi sebagai input
baru untuk produksi. Tidak ada subsistem yang dapat mencapai tujuannya dengan
tepat tanpa subsistem lainnya.
Masalah terjadi ketika setiap manajer memiliki gambaran yang berbeda tentang
pentingnya subsistem fungsionalnya sendiri. Pada Gambar 2.3 Anda dapat melihat
bahwa perspektif pribadi manajer pemasaran menunjukkan bisnis yang didorong oleh
pemasaran, dengan semua bidang fungsional lainnya saling terkait tetapi bukan dari
kepentingan utama. Dengan cara yang sama, perspektif seorang manajer produksi
menempatkan produksi di pusat bisnis, dengan semua bidang fungsional lain yang
didorong olehnya.

Kepentingan relatif bidang-bidang fungsional sebagaimana terungkap dalam

perspektif pribadi para manajer mengambil makna tambahan ketika para manajer naik
ke puncak melalui barisan, menjadi manajer strategis. Mereka dapat menciptakan
masalah jika mereka terlalu menekankan persyaratan fungsional fungsional mereka
sebelumnya dalam kaitannya dengan kebutuhan yang lebih luas dari organisasi.

Misalnya, jika manajer produksi dipromosikan tetapi terus menekankan jadwal

produksi dan kinerja pekerja garis, aspek peramalan dan pembuatan kebijakan yang
lebih luas mungkin akan menderita. Kecenderungan ini merupakan bahaya di semua
jenis bisnis: di mana para insinyur bekerja dengan cara mereka untuk menjadi
administrator perusahaan penerbangan, profesor perguruan tinggi pindah dari
departemen mereka untuk menjadi dekan, atau para programmer maju untuk menjadi
eksekutif perusahaan perangkat lunak. Visi terowongan mereka sering menciptakan
masalah bagi analis sistem yang mencoba memisahkan persyaratan informasi aktual
dari keinginan untuk jenis informasi tertentu.

FIGURE 2.2

FIGURE 2.3

Sistem Perusahaan: Melihat Organisasi sebagai Sistem

Sistem perusahaan, sering disebut sebagai sistem perencanaan sumber daya

perusahaan (ERP), adalah istilah yang digunakan untuk menggambarkan sistem
informasi organisasi (perusahaan) yang terintegrasi. Secara khusus, ERP adalah
perangkat lunak yang membantu aliran informasi antara area fungsional dalam
organisasi. Ini adalah sistem khusus yang, daripada dikembangkan sendiri, biasanya
dibeli dari salah satu perusahaan pengembangan perangkat lunak yang terkenal untuk
paket ERP-nya, seperti SAP atau Oracle. Produk ini kemudian disesuaikan agar sesuai
dengan persyaratan perusahaan tertentu. Biasanya, vendor membutuhkan komitmen
organisasi dalam hal pelatihan khusus pengguna atau analis. Banyak paket ERP
dirancang untuk dijalankan di Web. ERP, meskipun semakin populer, juga dipandang
dengan skeptis.

ERP berevolusi dari perencanaan kebutuhan material (MRP), sistem informasi yang
dirancang untuk meningkatkan manufaktur secara umum dan perakitan pada
khususnya. Sistem ERP sekarang termasuk komponen manufaktur dan dengan
demikian membantu dengan perencanaan kapasitas, penjadwalan produksi bahan, dan
peramalan. Di luar manufaktur (dan mitra layanannya), ERP mencakup perencanaan
penjualan dan operasi, distribusi, pengadaan, dan pengelolaan rantai pasokan. Karena
itu secara signifikan
mempengaruhi semua area dalam organisasi, termasuk akuntansi, keuangan,
manajemen,
pemasaran, dan sistem informasi.

Menerapkan solusi ERP mungkin membuat frustrasi karena sulit untuk menganalisis
sistem yang sedang digunakan dan kemudian cocok dengan model ERP untuk sistem
itu. Selanjutnya, perusahaan cenderung merancang proses bisnis mereka sebelum ERP
diterapkan. Sayangnya, proses ini sering terburu-buru dan model bisnis yang
diusulkan tidak selalu sesuai dengan fungsionalitas ERP. Hasilnya adalah penyesuaian
lebih lanjut, kerangka waktu implementasi yang diperpanjang, biaya yang lebih tinggi,
dan sering hilangnya kepercayaan pengguna. Analis harus menyadari besarnya
masalah yang mereka hadapi ketika mencoba menerapkan paket ERP.

SISTEM PENYANGKALAN GRAPHICALLY

Suatu sistem 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 Diagram Arus Data Tingkat Konteks

Model pertama adalah diagram alur data tingkat konteks (juga disebut model
lingkungan). Data flow diagram fokus pada data yang mengalir masuk dan keluar dari
sistem dan pemrosesan data. 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 alur data tingkat konteks hanya
menggunakan tiga simbol: (1) persegi panjang dengan sudut membulat, (2) persegi
dengan dua sisi yang teduh, dan (3) panah. Proses mengubah data yang masuk
menjadi informasi yang keluar, dan level konten hanya memiliki satu proses, yang
mewakili keseluruhan sistem. Entitas eksternal mewakili entitas yang memasok atau
menerima informasi dari sistem tetapi bukan bagian dari sistem. Entitas ini dapat
berupa orang, sekelompok orang, posisi atau departemen perusahaan, atau sistem lain.
Garis yang menghubungkan entitas eksternal ke proses disebut aliran data, dan
mereka mewakili data.

Contoh diagram alur data tingkat konteks ditemukan pada Gambar 2.5. Dalam contoh
ini, elemen paling dasar dari sistem reservasi maskapai terwakili. Penumpang (entitas)
memulai permintaan perjalanan (aliran data). Diagram konteks tidak menunjukkan
cukup detail untuk menunjukkan apa yang terjadi (tidak seharusnya), tetapi kita dapat
melihat bahwa preferensi penumpang dan penerbangan yang tersedia dikirim ke agen
perjalanan, yang mengirimkan informasi tiket kembali ke proses. Kami juga dapat
melihat bahwa pemesanan penumpang dikirim ke maskapai penerbangan. Diagram
alur data tingkat konteks berfungsi sebagai titik awal yang baik untuk menggambar
diagram use case (dibahas nanti dalam bab ini).

Di Bab 7 kita melihat bahwa aliran data mengandung banyak informasi. Misalnya,
reservasi penumpang berisi nama penumpang, maskapai penerbangan, nomor
penerbangan, tanggal perjalanan, harga, preferensi tempat duduk, dan sebagainya.
Untuk saat ini, bagaimanapun, kami terutama terkait dengan bagaimana level konteks
mendefinisikan batas-batas sistem. Dalam contoh sebelumnya, hanya reservasi yang
merupakan bagian dari proses. Keputusan lain yang akan dilakukan maskapai
penerbangan (misalnya, pembelian pesawat terbang, mengubah jadwal, penetapan
harga) bukan bagian dari sistem ini.

Diagram aliran data tingkat konteks adalah salah satu cara untuk menunjukkan ruang
lingkup sistem, atau apa yang akan dimasukkan dalam sistem. Entitas eksternal
berada di luar ruang lingkup dan sesuatu yang tidak dapat dikendalikan oleh sistem.

FIGURE 2.4

FIGURE 2.5

Sistem dan Model Entitas-Hubungan

Cara lain seorang analis sistem dapat menunjukkan ruang lingkup sistem dan
menetapkan batasan sistem yang tepat adalah dengan menggunakan model
entitas-relasi. Unsur-unsur yang membentuk sistem organisasi dapat disebut sebagai
entitas. Entitas dapat berupa orang, tempat, atau benda, seperti penumpang di
maskapai penerbangan, tujuan, atau pesawat. Sebagai alternatif, entitas dapat berupa
peristiwa, seperti akhir bulan, periode penjualan, atau kerusakan mesin. Hubungan
adalah asosiasi yang menggambarkan interaksi antar entitas.

Ada banyak konvensi yang berbeda untuk menggambar diagram entitas-hubungan

(E-R) (dengan nama seperti kaki gagak, Arrow, atau notasi Bachman). Dalam buku
ini, kami menggunakan notasi kaki gagak. Untuk saat ini, kami berasumsi bahwa
entitas adalah kotak persegi panjang biasa.

Gambar 2.6 menunjukkan diagram hubungan entitas sederhana. Dua entitas

dihubungkan bersama oleh suatu garis. Dalam contoh ini, akhir baris ditandai dengan
dua tanda paralel pendek (| |), menandakan bahwa hubungan ini adalah satu-ke-satu.
Jadi, tepat satu karyawan ditugaskan ke satu ekstensi telepon. Tidak ada yang berbagi
ekstensi telepon yang sama di kantor ini.

FIGURE 2.6

Panah merah bukan bagian dari diagram hubungan entitas. Mereka hadir untuk
menunjukkan cara membaca diagram hubungan entitas. Frasa di sisi kanan baris
dibaca dari atas ke bawah sebagai berikut: "Satu EMPLOYEE ditetapkan ke satu
PONSEL PHONE." Di sisi kiri, saat Anda membaca dari bawah ke atas, tanda panah
mengatakan, "Satu PAMAN TELEPON terdaftar untuk satu EMPLOYEE. ”

Demikian pula, Gambar 2.7 menunjukkan hubungan lain. Notasi kaki gagak (-> +)
terlihat jelas pada diagram ini, dan contoh khusus ini adalah contoh banyak-ke-satu.
Ketika Anda membaca dari kiri ke kanan, panah menandakan, "Banyak
EMPLOYEES adalah anggota DEPARTMENT." Ketika Anda membaca dari kanan
ke kiri, itu menyiratkan, "Satu DEPARTMENT berisi banyak EMPLOYEES."

Perhatikan bahwa ketika hubungan banyak-ke-satu hadir, perubahan tata bahasa dari
"adalah" menjadi "adalah" meskipun "tunggal" ditulis di telepon. Kaki gagak dan
tanda tunggal tidak secara harfiah berarti bahwa akhir dari hubungan ini harus
menjadi "wajib" banyak. Sebaliknya, mereka menyiratkan bahwa tujuan ini dapat
berupa apa saja dari satu ke banyak.
Gambar 2.8 menguraikan skema ini. Di sini kami telah membuat daftar sejumlah
hubungan entitas yang khas. Yang pertama, “EMPLOYEE ditugaskan untuk
KANTOR,” adalah hubungan satu-ke-satu. Yang kedua adalah hubungan
satu-ke-banyak: "Satu CARGO AIRCRAFT akan melayani satu atau lebih PUSAT
DISTRIBUSI." Yang ketiga sedikit berbeda karena memiliki lingkaran di salah satu
ujungnya. Hal ini dapat dibaca sebagai "ANALISIS SISTEM dapat ditugaskan untuk
PROYEK BANYAK," yang berarti bahwa analis dapat ditugaskan untuk tidak ada
proyek [itu adalah apa 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: "MESIN mungkin atau mungkin tidak
menjalani PEMELIHARAAN TERJADWAL." Perhatikan bahwa garis ditulis sebagai
"sedang mengalami," tetapi tanda akhir pada garis menunjukkan bahwa baik tidak ada
pemeliharaan (O) atau pemeliharaan (I) sebenarnya sedang berlangsung.

Hubungan berikutnya menyatakan, "Satu atau banyak SALESPEOPLE (jamak dari

SALESPERSON) ditugaskan untuk satu atau lebih PELANGGAN." Ini adalah
hubungan banyak-ke-banyak klasik. Hubungan berikutnya dapat dibaca sebagai
berikut: “KANTOR RUMAH dapat memiliki satu atau banyak EMPLOYEE,” atau
“Satu atau lebih EMPLOYEE mungkin atau mungkin tidak ditugaskan ke KANTOR
RUMAH.” Sekali lagi, Iand O bersama menyiratkan situasi Boolean ; dengan kata
lain, satu atau nol.

Hubungan terakhir yang ditunjukkan di sini dapat dibaca sebagai, "Banyak

PENUMPANG terbang ke banyak DESTINASI." Simbol ini [-> +] lebih disukai oleh
beberapa orang untuk menunjukkan "banyak" kondisi wajib. (Apakah mungkin untuk
memiliki hanya satu penumpang atau hanya satu tujuan?) Meskipun demikian,
beberapa alat CASE seperti Analis Terlihat tidak menawarkan kemungkinan ini,
karena kondisi satu-banyak opsional seperti yang ditunjukkan dalam hubungan
SALESPERSON-PELANGGAN akan dilakukan .

Hingga kini kami telah mencontoh semua hubungan kami hanya dengan
menggunakan satu persegi panjang sederhana dan satu garis. Metode ini berfungsi
dengan baik ketika kita memeriksa hubungan hal-hal nyata seperti orang, tempat, dan
hal-hal nyata. Kadang-kadang, meskipun, kami membuat item baru dalam proses
pengembangan sistem informasi. Beberapa contoh adalah faktur, kwitansi, file, dan
basis data. Ketika kami ingin menggambarkan bagaimana seseorang terkait dengan
tanda terima, misalnya, menjadi nyaman untuk menunjukkan tanda terima dengan
cara yang berbeda, seperti yang ditunjukkan pada Gambar 2.9 sebagai entitas
asosiatif.

FIGURE 2.7
 FIGURE 2.8

Suatu entitas asosiatif hanya dapat ada jika terhubung ke setidaknya dua entitas
lainnya. Untuk alasan itu, beberapa menyebutnya sebagai gerund, persimpangan,
persimpangan, atau entitas gabungan. Kata-kata ini masuk akal karena tanda terima
tidak diperlukan kecuali ada pelanggan dan penjual yang membuat transaksi.

Tipe entitas lain adalah atributif. Ketika seorang analis ingin menunjukkan data yang
sepenuhnya bergantung pada keberadaan entitas fundamental, entitas atributif harus
digunakan.

FIGURE 2.9

FIGURE 2.10
Sebagai contoh, ketika sebuah perpustakaan memiliki banyak salinan dari buku yang
sama, sebuah entitas atributif dapat digunakan untuk menunjuk salinan buku yang
sedang diperiksa. Entitas atributif berguna untuk menampilkan kelompok data yang
berulang. Misalnya, anggap kita akan memodelkan hubungan yang ada ketika seorang
patron mendapatkan tiket untuk konser atau pertunjukan. Entitas tampak jelas pada
awalnya: "PATRON dan CONCERT / SHOW," seperti yang ditunjukkan pada
Gambar 2.10. Hubungan macam apa yang ada?
Sepintas PATRON mendapat reservasi untuk CONCERT / SHOW, dan
CONCERT / SHOW dapat dikatakan telah membuat pemesanan untuk PATRON.

Prosesnya tidak sesederhana itu, tentu saja, dan diagram E-R tidak perlu sesederhana
itu. PATRON benar-benar membuat RESERVATION, seperti yang ditunjukkan pada
Gambar 2.11. RESERVASI adalah untuk CONCERT / SHOW. CONCERT / SHOW
menyimpan RESERVATION, dan RESERVATION adalah atas nama PATRON.
Kami menambahkan entitas asosiatif di sini karena RESERVATION dibuat karena
sistem informasi yang diperlukan untuk menghubungkan PATRON dan CONCERT /
SHOW.

FIGURE 2.11

Sekali lagi proses ini cukup sederhana, tetapi karena konser dan pertunjukan memiliki
banyak pertunjukan, diagram E-R diambil sekali lagi pada Gambar 2.12. Di sini kami
menambahkan entitas atributif untuk menangani banyak pertunjukan CONCERT /
SHOW. Dalam hal ini, PEMESANAN dibuat untuk KINERJA tertentu, dan
KINERJA adalah salah satu dari banyak yang dimiliki KONSER / TAMPILAN
tertentu. Pada gilirannya CONCERT / SHOW memiliki banyak pertunjukan, dan satu
KINERJA memiliki RESERVASI yang ada di nama PATRON tertentu.

Di sebelah kanan diagram E-R ini adalah seperangkat atribut data yang membentuk
masing-masing entitas. Beberapa entitas mungkin memiliki atribut yang sama. Atribut
yang digarisbawahi dapat dicari. Atribut disebut sebagai kunci dan dibahas dalam Bab
13.

Diagram E-R sering digunakan oleh perancang sistem untuk membantu memodelkan
file atau basis data. Namun, yang lebih penting adalah bahwa analis sistem memahami
awal baik entitas dan hubungan dalam sistem organisasi. Dalam membuat sketsa
beberapa diagram E-R dasar, analis perlu:
1. Buat daftar entitas dalam organisasi untuk mendapatkan pemahaman yang lebih
baik tentang organisasi.
2. Pilih entitas kunci untuk mempersempit ruang lingkup masalah ke dimensi yang
dapat dikelola dan bermakna.

FIGURE 2.12

MAC APPEAL

3. Identifikasi apa yang seharusnya menjadi entitas utama.

4. Konfirmasikan hasil langkah 1 hingga 3 melalui metode pengumpulan data lainnya
(Investigasi, wawancara, administrasi kuesioner, observasi, dan prototyping), seperti
yang dibahas dalam Bab 4 hingga 6.

Sangat penting bahwa analis sistem mulai menggambar diagram ER saat memasuki
organisasi daripada menunggu sampai database perlu dirancang, karena diagram ER
membantu analis memahami bisnis apa yang sebenarnya di dalam organisasi,
menentukan ukuran dan ruang lingkup masalah , dan cari tahu apakah masalah yang
tepat sedang ditangani. Diagram E-R perlu dikonfirmasi atau direvisi ketika proses
pengumpulan data berlangsung.

GUNAKAN MODEL KASUS

Awalnya diperkenalkan sebagai diagram untuk digunakan dalam UML berorientasi
obyek, kasus penggunaan sekarang digunakan terlepas dari pendekatan untuk
pengembangan sistem. Ini dapat digunakan sebagai bagian dari SDLC atau dalam
pemodelan tangkas. Penggunaan kata diucapkan sebagai kata benda (yoos) daripada
kata kerja (yooz). Model use case menggambarkan apa yang dilakukan sistem tanpa
menjelaskan bagaimana sistem melakukannya; Yaitu, itu adalah model logis dari
sistem. (Model logis atau konseptual akan dibahas lebih lanjut di Bab 7). Model use
case mencerminkan pandangan sistem dari perspektif pengguna di luar sistem (yaitu,
persyaratan sistem).

Seorang analis mengembangkan kasus penggunaan dalam upaya kerja sama dengan
pakar bisnis yang membantu menentukan persyaratan sistem. Model use case
menyediakan sarana komunikasi yang efektif antara tim bisnis dan tim pengembangan.
Model use case memilah cara sistem bekerja ke dalam perilaku, layanan, dan respons
(use case) yang signifikan bagi pengguna sistem.

Dari perspektif seorang aktor (atau pengguna), use case harus menghasilkan sesuatu
yang bernilai. Oleh karena itu, analis harus menentukan apa yang penting bagi
pengguna, dan ingat untuk memasukkannya dalam diagram use case. Misalnya,
memasukkan kata sandi sesuatu yang bernilai kepada pengguna? Ini dapat
dimasukkan jika pengguna memiliki kekhawatiran tentang keamanan atau jika itu
sangat penting untuk keberhasilan proyek.

Gunakan Simbol Kasus

Diagram use case berisi aktor dan menggunakan simbol case, bersama dengan garis
penghubung. Aktor mirip dengan entitas eksternal; mereka ada di luar sistem. Istilah
aktor mengacu pada peran \ khusus dari pengguna sistem. Misalnya, seorang aktor
mungkin seorang karyawan, tetapi mungkin juga pelanggan di toko perusahaan.
Meskipun itu adalah orang yang sama di dunia nyata, ia direpresentasikan sebagai dua
simbol berbeda pada diagram use case, karena orang tersebut berinteraksi dengan
sistem dalam peran yang berbeda. Aktor ada di luar sistem dan berinteraksi dengan
sistem dengan cara tertentu. Seorang aktor dapat menjadi manusia, sistem lain, atau
perangkat seperti keyboard atau Web
koneksi. Aktor dapat memulai sebuah instance dari use case. Seorang aktor dapat
berinteraksi dengan satu atau beberapa kasus penggunaan, dan kasus penggunaan
mungkin melibatkan satu atau lebih aktor.
Aktor dapat dibagi menjadi dua kelompok. Aktor utama menyediakan data atau
menerima informasi dari sistem. Beberapa pengguna langsung berinteraksi dengan
sistem (aktor sistem), tetapi pelaku utama mungkin juga adalah pelaku bisnis yang
tidak langsung berinteraksi dengan sistem tetapi memiliki saham di dalamnya. Aktor
utama adalah penting karena mereka adalah orang-orang yang menggunakan sistem
dan dapat memberikan rincian tentang apa yang harus dilakukan kasus penggunaan.
Mereka juga dapat memberikan daftar tujuan dan prioritas. Para aktor pendukung
(juga disebut aktor sekunder) membantu menjaga sistem tetap berjalan atau
menyediakan layanan lain. Ini
adalah orang-orang yang menjalankan meja bantuan, analis, programer, dan
seterusnya.

Terkadang 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 Spesialis Pemrosesan Pesanan. Profilnya adalah, “Seorang
pengguna rutin perangkat lunak, akrab dengan fitur-fitur minor, pengecualian pesanan,
dan penyesuaian pesanan.” Ini juga berguna untuk membuat daftar para aktor dan
tujuan serta prioritas mereka. Setiap tujuan dapat menjadi kasus penggunaan.

Kasus penggunaan memberi pengembang pandangan tentang apa yang diinginkan

pengguna. Ini bebas dari detail teknis atau implementasi. Kita dapat menganggap
suatu use case sebagai urutan transaksi dalam suatu sistem. Model use case
didasarkan pada interaksi dan hubungan kasus penggunaan individual.

Kasus penggunaan selalu menggambarkan tiga hal: seorang aktor yang memulai suatu
peristiwa; peristiwa yang memicu kasus penggunaan; dan use case yang melakukan
tindakan yang dipicu oleh peristiwa tersebut. Dalam kasus penggunaan, aktor yang
menggunakan sistem memulai suatu peristiwa yang memulai serangkaian interaksi
terkait dalam sistem. Use cases digunakan untuk mendokumentasikan satu transaksi
atau acara. Peristiwa adalah masukan ke sistem yang terjadi pada waktu dan tempat
tertentu dan menyebabkan sistem melakukan sesuatu.

Lebih baik membuat lebih sedikit use case daripada lebih banyak. Seringkali
pertanyaan dan laporan tidak dimasukkan; 20 kasus penggunaan (dan tidak lebih dari
40 atau 50) cukup untuk sistem yang besar. Kasus penggunaan juga dapat diulang,
jika diperlukan. Beberapa kasus penggunaan menggunakan kata kerja untuk
mengelola kasus penggunaan kelompok untuk menambahkan, menghapus, dan
mengubah ke diagram kasus penggunaan tingkat rendah yang lain. Anda dapat
menyertakan use case pada beberapa diagram, tetapi use case yang sebenarnya hanya
didefinisikan sekali dalam repositori. Sebuah use case diberi nama dengan kata kerja
dan kata benda.
Gunakan Hubungan Kasus

Hubungan aktif disebut sebagai hubungan perilaku dan digunakan terutama dalam
diagram use case. Ada empat tipe dasar hubungan perilaku: berkomunikasi, mencakup,
meluas, dan menggeneralisasikan. Perhatikan bahwa semua istilah ini adalah kata
kerja tindakanGambar 2.13 menunjukkan panah dan garis yang digunakan untuk
memetakan masing-masing dari empat jenis hubungan perilaku. Keempat hubungan
tersebut dijelaskan selanjutnya.

FIGURE 2.13

KOMUNIKASI. Hubungan perilaku berkomunikasi digunakan untuk

menghubungkan aktor dengan use case. Ingat bahwa tugas dari use case adalah
memberikan semacam hasil yang bermanfaat bagi aktor dalam sistem. Oleh karena itu,
penting untuk mendokumentasikan hubungan antara aktor dan menggunakan kasus.
Dalam contoh pertama kami, seorang Siswa berkomunikasi dengan Mendaftar di
Kursus. Contoh beberapa komponen contoh pendaftaran siswa ditunjukkan dalam
diagram use case pada Gambar 2.14.

TERMASUK. Hubungan termasuk (juga disebut menggunakan hubungan)

menggambarkan situasi di mana use case berisi perilaku yang umum untuk lebih dari
satu use case. Dengan kata lain, kasus penggunaan umum termasuk dalam kasus
penggunaan lainnya. Panah putus-putus yang menunjuk ke kasus penggunaan umum
menunjukkan hubungan termasuk. Contohnya adalah kasus penggunaan Pembayaran
Biaya Siswa yang termasuk dalam Mendaftar di Kursus dan Mengatur Perumahan,
karena dalam kedua kasus siswa harus membayar biaya mereka. Ini dapat digunakan
oleh beberapa kasus penggunaan. Panah menunjuk ke arah kasus penggunaan umum.

MEMPERPANJANG. Hubungan yang diperluas menggambarkan situasi di mana satu

kasus penggunaan memiliki perilaku yang memungkinkan kasus penggunaan baru
untuk menangani variasi atau pengecualian dari kasus penggunaan dasar. Sebagai
contoh, kasus penggunaan diperpanjang Asuransi Kesehatan Mahasiswa
memperpanjang kasus penggunaan dasar Bayar Biaya Siswa . Tanda panah pergi dari
perpanjangan ke kasus penggunaan dasar.

FIGURE 2.14
SECARA UMUM. Generalisasi hubungan menyiratkan bahwa satu hal lebih khas
daripada hal lainnya. Hubungan ini mungkin ada antara dua aktor atau dua kasus
penggunaan. Sebagai contoh, seorang siswa paruh waktu menyamar sebagai siswa.
Demikian pula, beberapa karyawan universitas adalah profesor. Panah menunjuk pada
hal umum.

Mengembangkan Cakupan Sistem

Ruang lingkup suatu sistem mendefinisikan batas-batasnya, apa yang ada dalam ruang
lingkup — atau di dalam sistem — dan apa yang berada di luar ruang lingkup. Proyek
biasanya memiliki anggaran yang membantu mendefinisikan ruang lingkup, dan
waktu mulai dan akhir. Aktor selalu berada di luar ruang lingkup sistem. Jalur
komunikasi yang menghubungkan aktor dengan kasus penggunaan adalah batas, dan
menentukan ruang lingkup. Karena diagram use case dibuat pada awal siklus hidup
sistem, anggaran, waktu mulai, dan waktu akhir dapat berubah ketika proyek
berlangsung; saat analis mempelajari lebih lanjut tentang sistem, diagram use case,
use case, dan scope dapat berubah.

Mengembangkan Use Case Diagrams

Kasus penggunaan utama terdiri dari aliran standar kejadian dalam sistem yang
menggambarkan perilaku sistem standar. Kasus penggunaan utama menunjukkan
penyelesaian kasus penggunaan normal, yang diharapkan, dan berhasil.

Saat memetakan use case, mulailah dengan meminta pengguna untuk membuat daftar
semua yang harus dilakukan oleh sistem untuk mereka. Ini dapat dilakukan dengan
menggunakan wawancara, dalam sesi perancangan aplikasi bersama (seperti yang
dijelaskan dalam Bab 4), atau melalui sesi tim lain yang difasilitasi. Analis juga dapat
menggunakan sesi cerita tangkas (dijelaskan dalam Bab 6) untuk mengembangkan
kasus penggunaan. Tuliskan siapa yang terlibat dengan setiap kasus penggunaan, dan
tanggung jawab atau layanan yang harus diberikan oleh kasus penggunaan kepada
aktor atau sistem lain. Pada fase awal, ini mungkin merupakan daftar parsial yang
diperluas dalam fase analisis selanjutnya. Menggunakan
panduan berikut:

1. Tinjau spesifikasi bisnis dan identifikasi para pelaku yang terlibat.

2. Identifikasi kejadian tingkat tinggi dan kembangkan kasus penggunaan primer yang
menggambarkan peristiwa-peristiwa itu dan bagaimana para pelaku memulainya.
Pelajari dengan cermat peran yang dimainkan oleh para aktor untuk mengidentifikasi
semua kemungkinan kasus penggunaan primer yang diprakarsai oleh masing-masing
aktor. Gunakan kasus dengan sedikit atau tanpa interaksi pengguna tidak harus
ditampilkan.
3. Tinjau setiap kasus penggunaan primer untuk menentukan kemungkinan variasi
aliran melalui use case. Dari analisis ini, buat jalur alternatif. Karena aliran peristiwa
biasanya berbeda dalam setiap kasus, carilah kegiatan yang dapat berhasil atau gagal.
Juga mencari cabang apa pun dalam logika use case yang memungkinkan hasil yang
berbeda.

Jika diagram alur data tingkat konteks telah dibuat, itu bisa menjadi titik awal untuk
membuat kasus penggunaan. Entitas eksternal adalah aktor potensial. Kemudian
periksa aliran data untuk menentukan apakah akan memulai use case atau diproduksi
oleh use case.

Gambar 2.15 adalah contoh diagram use case yang mewakili sistem yang digunakan
untuk merencanakan konferensi. Para aktor adalah Ketua Konferensi, yang
bertanggung jawab untuk merencanakan dan mengelola konferensi, peserta konferensi,
pembicara, Pembicara utama, Pemesanan Hotel, dan seorang Caterer. Aktor mewakili
peran yang dimainkan pengguna, dan Caterer dapat berupa karyawan hotel atau
layanan katering eksternal.

Baik Ketua Konferensi dan Caterer terlibat dalam perencanaan makanan dan jamuan
makan. Ketua Konferensi juga bertanggung jawab untuk mengatur pembicara. Peserta
mendaftar untuk konferensi. Perhatikan bahwa use case Reserve Room terlibat dalam
hubungan termasuk dengan Arrange Speaker dan Register for Conference use cases,
karena baik pembicara dan peserta akan membutuhkan penginapan. Kasus
penggunaan Terjemahan Bahasa Penyusun memperpanjang kasus penggunaan
Register for Conference karena tidak semua peserta akan membutuhkan layanan
terjemahan bahasa. Aktor Pembicara adalah generalisasi dari Pembicara Keynote.

Mengembangkan Skenario Use Use

Setiap use case memiliki deskripsi. Kami akan mengacu pada deskripsi sebagai
skenario use case. Seperti disebutkan, kasus penggunaan primer mewakili aliran
standar kejadian dalam sistem, dan jalur alternatif menggambarkan variasi terhadap
perilaku. Skenario penggunaan dapat menggambarkan apa yang terjadi jika barang
yang dibeli kehabisan stok, atau jika perusahaan kartu kredit menolak pembelian yang
diminta pelanggan.
 FIGURE 2.15

Tidak ada format skenario standar penggunaan, sehingga setiap organisasi dihadapkan
dengan menetapkan standar apa yang harus dimasukkan. Seringkali kasus penggunaan
didokumentasikan menggunakan kerangka dokumen kasus penggunaan yang telah
ditentukan oleh organisasi, yang membuat kasus penggunaan lebih mudah dibaca dan
memberikan informasi standar untuk setiap kasus penggunaan 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 level tertinggi, seperti awan. Ini adalah tingkat perusahaan, dan
mungkin hanya ada empat hingga lima untuk seluruh organisasi. Contohnya mungkin
untuk mengiklankan barang, menjual barang ke pelanggan, mengelola inventaris,
mengelola rantai pasokan, dan mengoptimalkan pengiriman.
2. Layang-layang lebih rendah dari putih tetapi masih tingkat tinggi, memberikan
gambaran umum. Kasus penggunaan layang-layang mungkin berada di unit bisnis
atau tingkat departemen dan merupakan ringkasan tujuan. Contohnya adalah
mendaftarkan siswa, atau jika bekerja dengan perusahaan perjalanan: membuat
penerbangan, hotel, mobil, atau reservasi kapal pesiar.
3. Biru di permukaan laut, dan biasanya dibuat untuk tujuan pengguna. Ini sering
memiliki minat terbesar bagi pengguna dan paling mudah untuk dipahami oleh bisnis.
Ini biasanya ditulis untuk kegiatan bisnis dan setiap orang harus dapat melakukan satu
aktivitas tingkat biru di mana saja dari 2 hingga 20 menit. Contohnya adalah
mendaftarkan siswa yang melanjutkan, tambahkan pelanggan baru, tempatkan item di
keranjang belanja, dan checkout pesanan.
4. Indigo atau ikan adalah kasus penggunaan yang menunjukkan banyak detail, sering
pada tingkat fungsional atau subfungsional. Contohnya adalah memilih kelas,
membayar biaya akademik, mencari kode bandara untuk kota tertentu, dan
menghasilkan daftar pelanggan setelah memasukkan nama.
5. Hitam atau kerang, seperti dasar lautan, adalah kasus penggunaan paling rinci, di a
tingkat subfungsi. Contohnya mungkin validasi logon aman, menambahkan bidang
baru menggunakan HTML dinamis, atau menggunakan Ajax untuk memperbarui
halaman Web dengan cara kecil.
Contoh skenario use case ditunjukkan pada Gambar 2.16. Beberapa area termasuk
opsional, dan tidak dapat digunakan oleh semua organisasi. Tiga bidang utama
adalah:
1. Sebuah header area yang berisi identifier dan inisiator kasus.
2. Langkah-langkah dilakukan.
3. Area footer berisi prakondisi, asumsi, pertanyaan, dan informasi lainnya

FIGURE 2.16

Area pertama, gunakan pengidentifikasi dan inisiator huruf, ucapkan pembaca dan
berisi nama use case dan ID unik; area aplikasi atau sistem yang menggunakan kasus
ini; aktor yang terlibat dalam kasus penggunaan; dan para pemangku kepentingan
yang memiliki tingkat kepentingan yang tinggi dalam kasus penggunaan. Beberapa
pemangku kepentingan tidak pernah berinteraksi langsung dengan sistem, seperti
pemegang saham, dewan direksi, atau manajer penjualan. Setiap aktor utama adalah
pemangku kepentingan, tetapi tidak tercantum dalam wilayah pemangku kepentingan.
Sertakan level (biru, layang-layang, dan sebagainya) dan deskripsi singkat tentang apa
yang dilakukan kasus penggunaan.

Header diakhiri dengan acara inisiasi (memicu), yaitu, apa yang menyebabkan use
case untuk memulai, dan jenis pemicu, baik eksternal atau temporal. Peristiwa
eksternal adalah peristiwa yang dimulai oleh seorang aktor, baik seseorang atau
sistem lain yang meminta informasi, seperti sistem reservasi penerbangan yang
meminta informasi penerbangan dari sistem maskapai penerbangan. Peristiwa
temporal adalah peristiwa yang dipicu atau dimulai oleh waktu. Peristiwa terjadi pada
waktu tertentu, seperti mengirim email tentang penawaran khusus seminggu sekali
pada Minggu malam, mengirim tagihan pada hari tertentu, atau menghasilkan
pemerintah
statistik pada tanggal yang ditentukan setiap kuartal.

Area kedua dari use case meliputi langkah-langkah yang dilakukan, dan informasi
yang diperlukan untuk masing-masing langkah. Pernyataan-pernyataan ini mewakili
aliran standar kejadian dan langkah-langkah yang diambil untuk penyelesaian kasus
penggunaan yang berhasil. Diharapkan untuk menulis sebuah use case untuk jalur
utama, dan kemudian menulis satu untuk masing-masing jalur alternatif secara
terpisah, daripada menggunakan IF. . . KEMUDIAN . . . pernyataan.
Langkah-langkah diberi nomor dengan integer. Langkah-langkah mungkin berasal
dari wawancara rinci 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, dia harus
menjadwalkan wawancara tindak lanjut dengan pengguna. Beberapa penggunaan
deskripsi kasus mencakup ekstensi atau skenario alternatif, dengan pengecualian
sebagai bagian tambahan mengikuti arus peristiwa standar. Ini diberi nomor dengan
bilangan bulat, titik desimal, dan bilangan bulat lain, seperti 3,1, 3,2, 3,3, dan
seterusnya. Ini adalah langkah-langkah yang mungkin atau mungkin tidak digunakan.
Analis dan pengguna dapat bertukar pikiran tentang apa yang bisa salah dengan jalur
utama, dan mungkin mengungkap rincian dan kondisi penting. Penting untuk bekerja
dengan pengguna untuk menentukan apa yang harus dilakukan ketika kondisi ini
terjadi. Ini membantu mendeteksi kesalahan lebih awal dalam siklus hidup.

Gambar 2.17 mengilustrasikan bagaimana skenario logika dan alternatif dapat

dimasukkan di bagian tengah dari use case. Dalam contoh maskapai penerbangan ini,
perhatikan bahwa langkah 1 terdiri dari langkah-langkah yang lebih kecil, banyak
yang didahului oleh "jika." Ini masih berada di jalur utama, tetapi hanya terjadi jika
kondisi terpenuhi. Misalnya, jika ada banyak bandara yang melayani kota, maka
semua bandara akan ditampilkan. Ekstensi atau skenario alternatif juga dapat muncul
di sini. Untuk maskapai ini, skenario lain termasuk pemilihan penerbangan, pemilihan
tempat duduk, dan pemilihan makanan. Kasus penggunaan bahkan dapat mencakup
langkah-langkah berulang atau berulang.
Area ketiga dari use case meliputi:
 Prekondisi, atau kondisi sistem sebelum use case dapat dilakukan, yang mungkin
merupakan kasus penggunaan lain. Contohnya mungkin, "Penampil telah berhasil
masuk ke sistem," atau mungkin berhasil menyelesaikan kasus penggunaan lain.

 Postconditions, atau keadaan sistem setelah use case selesai, termasuk output
yang telah diterima orang, transmisi ke sistem lain, dan data yang telah dibuat
atau diperbarui. Ini berkaitan dengan tujuan atau persyaratan pengguna dari
definisi masalah (dijelaskan dalam Bab 3) atau ke cerita tangkas (dijelaskan
dalam Bab 6).

 Asumsi yang dibuat akan mempengaruhi metode use case dan yang dapat
menetapkan teknologi yang dibutuhkan, seperti persyaratan teknologi minimum
di browser atau bahkan versi tertentu atau lebih tinggi dari browser. Asumsi
mungkin cookie atau JavaScript diaktifkan. Analis harus menentukan apa yang
harus dilakukan jika asumsi tidak dipenuhi. Saat menggunakan Google Maps,
 JavaScript harus diaktifkan. Jika tidak diaktifkan, peta tidak akan ditampilkan.
Cookie dibutuhkan oleh Netflix. Halaman web yang bagus akan mendeteksi
bahwa asumsi belum dipenuhi dan memberi tahu pemirsa dengan pesan, termasuk
informasi tentang cara mengaktifkan cookie atau JavaScript untuk berbagai
browser.

 Jaminan minimal adalah minimum yang dijanjikan kepada pengguna. Mereka

mungkin tidak senang dengan hasil ini dan mungkin tidak ada yang terjadi.

 Jaminan sukses adalah apa yang akan memuaskan pengguna, dan biasanya
tujuan dari use case telah terpenuhi.

 Setiap masalah atau pertanyaan yang luar biasa harus dijawab sebelum
penerapan kasus penggunaan.

FIGURE 2.17
 Pernyataan opsional prioritas kasus penggunaan, yang mungkin berasal dari
masalah definisi atau persyaratan pengguna.

 Pernyataan risiko opsional yang terlibat dalam pembuatan use case.

Area “persyaratan dipenuhi” menghubungkan kasus penggunaan dengan persyaratan

atau tujuan pengguna dari definisi masalah. Setelah Anda mengembangkan skenario
use case, pastikan untuk meninjau hasil Anda dengan pakar bisnis untuk
memverifikasi dan memperbaiki kasus penggunaan jika diperlukan.

Dalam skenario use case khusus ini, yang disebut Register for Conference,
satu-satunya aktor yang terlibat adalah Partisipan. Keseluruhan area adalah
Conference Planning, dan use case dipicu oleh peserta yang masuk ke halaman Web
Pendaftaran. Langkah-langkah yang Dilakukan daerah daftar urutan peristiwa yang
harus terjadi untuk pendaftaran konferensi yang sukses. Perhatikan bahwa informasi
yang diperlukan untuk melakukan masing-masing langkah tercantum di sebelah kanan.
Ini mungkin termasuk halaman web dan formulir, serta tabel dan catatan basis data.

Area Prekondisi di bagian footer dari skenario use case mencantumkan apa yang
harus terjadi sebelum peserta dapat mendaftar untuk konferensi. Dalam contoh ini,
peserta harus sudah mendaftar sebagai anggota masyarakat dan memiliki userID dan
kata sandi yang valid. Area Postconditions mencantumkan apa yang telah dicapai oleh
use case. Area Asumsi mencantumkan semua tempat dasar yang diasumsikan oleh
analis dipenuhi oleh aktor sebelumnya. Area Requirements Met menunjukkan
mengapa use case ini penting dan diperlukan agar area bisnis menjadi sukses.
Prioritas adalah indikasi kasus penggunaan mana yang harus dikembangkan terlebih
dahulu dan yang mungkin tertunda. Risiko adalah penilaian kasar tentang apakah
mungkin ada masalah atau kesulitan mengembangkan kasus penggunaan. Dalam hal
ini, risikonya menengah karena kasus penggunaan pendaftaran memerlukan server
yang aman dan menerima informasi kartu kredit.

Membuat Deskripsi Use Case

Gunakan empat langkah berikut untuk membuat deskripsi kasus penggunaan:

1. Gunakan cerita yang lincah, tujuan definisi masalah, persyaratan pengguna, atau
daftar fitur sebagai titik awal.
2. Tanyakan tentang tugas-tugas yang harus dilakukan untuk menyelesaikan transaksi.
Tanyakan apakah use case membaca data apa pun atau memperbarui tabel apa pun.
3. Cari tahu apakah ada tindakan berulang atau berulang.
4. Kasus penggunaan berakhir ketika tujuan pelanggan selesai.

Mengapa Use Case Diagrams Bermanfaat

Tidak peduli metode apa yang Anda gunakan untuk mengembangkan sistem Anda
(metode SDLC tradisional, metode gesit, atau metode berorientasi objek), Anda akan
menemukan bahwa kasus penggunaan 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 ditunjukkan dengan jelas pada diagram use
case. Ini tidak hanya memudahkan analis untuk mengidentifikasi proses, tetapi juga
membantu dalam komunikasi dengan analis lain di tim dan eksekutif bisnis.

Skenario use case juga bermanfaat. Karena banyak informasi yang diberikan
pengguna kepada analis sudah mengambil bentuk cerita, mudah untuk menangkap
cerita pada formulir skenario kasus penggunaan. Skenario use case selalu
mendokumentasikan peristiwa yang memicu sehingga analis selalu dapat melacak
langkah-langkah yang menyebabkan kasus penggunaan lainnya. Karena
langkah-langkah yang dilakukan dicatat, adalah mungkin untuk menggunakan
skenario use case untuk menulis proses logis.

Use case diagram menjadi populer karena kesederhanaan dan kurangnya detail teknis.
Mereka digunakan untuk menunjukkan ruang lingkup sistem, bersama dengan 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
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 luas, tingkat horizontal: pengendalian
operasional, perencanaan dan pengendalian manajerial (manajemen menengah), dan
manajemen strategis, seperti yang ditunjukkan pada Gambar 2.19. Setiap tingkat
memikul tanggung jawabnya sendiri, dan semua bekerja untuk mencapai tujuan dan
sasaran organisasi dengan cara mereka sendiri.

FIGURE 2.18

Pengendalian operasional membentuk tier bawah manajemen tiga tingkat. Manajer

operasi membuat keputusan menggunakan aturan yang telah ditentukan yang
memiliki hasil yang dapat diprediksi ketika diterapkan dengan benar.

Mereka membuat keputusan yang mempengaruhi implementasi dalam penjadwalan

pekerjaan, kontrol inventaris, pengiriman, penerimaan, dan kontrol proses seperti
produksi. Manajer operasi mengawasi rincian operasi organisasi.

Manajemen tingkat menengah membentuk tingkat kedua, atau menengah, dari sistem
manajemen tiga tingkat. Manajer menengah membuat perencanaan dan pengendalian
keputusan jangka pendek tentang bagaimana sumber daya dapat dialokasikan untuk
memenuhi tujuan organisasi.
Keputusan mereka berkisar dari meramalkan kebutuhan sumber daya di masa depan
untuk memecahkan masalah karyawan yang mengancam produktivitas. Domain
pengambil keputusan manajer menengah dapat dicirikan sebagai sebagian operasional
dan sebagian strategis, dengan fluktuasi yang konstan.

FIGURE 2.19

Manajemen strategis adalah tingkat ketiga kontrol manajemen tiga tingkat. Manajer
strategis melihat keluar dari organisasi ke masa depan, membuat keputusan yang akan
membimbing manajer menengah dan operasi dalam beberapa bulan dan tahun
mendatang.

Manajer strategis bekerja di lingkungan pengambilan keputusan yang sangat tidak

pasti. Melalui pernyataan tujuan dan penentuan strategi dan kebijakan untuk
mencapainya, manajer strategis benar-benar mendefinisikan organisasi secara
keseluruhan. Mereka adalah gambaran luas, di mana perusahaan memutuskan untuk
mengembangkan lini produk baru, melepaskan diri dari usaha yang tidak
menguntungkan, memperoleh perusahaan lain yang kompatibel, atau bahkan
mengizinkan dirinya untuk diakuisisi atau digabung.

Ada perbedaan tajam di antara para pengambil keputusan di banyak dimensi.

Misalnya, manajer strategis memiliki beberapa tujuan keputusan, sedangkan manajer
operasi memiliki tujuan tunggal. Sering kali sulit bagi manajer tingkat tinggi untuk
mengidentifikasi masalah, tetapi mudah bagi manajer operasi untuk melakukannya.
Manajer strategis dihadapkan dengan masalah semiterstruktur, sedangkan manajer
level bawah menangani sebagian besar masalah terstruktur.

Solusi alternatif untuk masalah yang dihadapi manajer strategis sering sulit untuk
diartikulasikan, tetapi alternatif yang manajer operasi bekerja dengan biasanya mudah
untuk dihitung. Manajer strategis paling sering membuat keputusan satu kali,
sedangkan keputusan yang dibuat oleh manajer operasi cenderung berulang.

Implikasi untuk Pengembangan Sistem Informasi

Masing-masing dari tiga tingkat manajemen memegang implikasi yang berbeda untuk
mengembangkan sistem informasi. Beberapa persyaratan informasi untuk manajer
jelas, sedangkan yang lain kabur dan tumpang tindih.
Manajer operasi membutuhkan informasi internal yang bersifat repetitif, tingkat
rendah. Mereka sangat bergantung pada informasi yang menangkap kinerja saat ini,
dan mereka adalah pengguna besar sumber daya informasi online dan real-time.
Kebutuhan manajer operasi untuk informasi kinerja masa lalu dan informasi berkala
hanya moderat. Mereka memiliki sedikit penggunaan untuk informasi eksternal yang
memungkinkan proyeksi masa depan.

Pada tingkat manajemen berikutnya, manajer menengah membutuhkan informasi

jangka pendek dan jangka panjang. Karena sifat pemecahan masalah pekerjaan
mereka, manajer menengah mengalami kebutuhan informasi yang sangat tinggi secara
waktu nyata. Untuk mengontrol dengan benar, mereka juga membutuhkan informasi
terkini tentang kinerja yang diukur dengan standar yang ditetapkan. Manajer
menengah sangat bergantung pada informasi internal. Berbeda dengan manajer
operasi, mereka memiliki kebutuhan tinggi untuk informasi historis, bersama dengan
informasi yang memungkinkan untuk prediksi peristiwa masa depan dan simulasi
berbagai kemungkinan skenario.

Manajer strategis agak berbeda dari kedua manajer menengah dan operasi dalam
persyaratan informasi mereka. Mereka sangat bergantung pada informasi dari sumber
eksternal yang memasok berita tentang tren pasar dan strategi perusahaan pesaing.
Karena tugas pengelolaan strategis menuntut proyeksi ke masa depan yang tidak pasti,
manajer strategis memiliki kebutuhan yang tinggi akan informasi sifat prediktif dan
informasi yang memungkinkan penciptaan banyak skenario apa-jika berbeda. Manajer
strategis juga menunjukkan kebutuhan yang kuat untuk informasi yang dilaporkan
secara berkala
saat mereka berusaha beradaptasi dengan perubahan yang bergerak cepat.

BUDAYA ORGANISASI

Budaya organisasi adalah bidang penelitian yang telah berkembang pesat di generasi
terakhir. Persis sebagaimana layaknya untuk memikirkan organisasi sebagai termasuk
banyak teknologi, adalah sama tepat untuk melihat mereka sebagai tuan rumah bagi
banyak, subkultur yang sering bersaing.

Masih ada sedikit kesepakatan tentang apa yang secara tepat merupakan subkultur
organisasi. Namun disepakati, bahwa subkultur yang bersaing mungkin mengalami
konflik, berusaha untuk mendapatkan penganut visi mereka tentang apa yang
seharusnya menjadi organisasi. Penelitian sedang berlangsung untuk menentukan efek
dari organisasi virtual dan tim virtual pada penciptaan subkultur ketika anggota tidak
berbagi ruang kerja fisik tetapi berbagi tugas.
Daripada berpikir tentang budaya secara keseluruhan, lebih berguna untuk
memikirkan faktor penentu subkultur yang dapat diteliti, seperti simbolisme verbal
dan nonverbal yang dibagikan. Simbolisme verbal termasuk bahasa yang digunakan
bersama untuk membangun, menyampaikan, dan melestarikan mitos-mitos subkultur,
metafora, visi, dan humor. Simbolisme nonverbal termasuk berbagi artefak, ritual, dan
upacara; pakaian para pembuat keputusan dan pekerja; penggunaan, penempatan, dan
dekorasi kantor; dan ritual untuk merayakan ulang tahun anggota, promosi, dan
pensiun.

CONSULTING OPPORTUNITY 2.3

Subkultur hidup berdampingan dalam budaya organisasi "resmi". Budaya yang

disetujui secara resmi dapat meresepkan kode berpakaian, cara-cara yang cocok untuk
mengatasi atasan dan rekan kerja, dan cara-cara yang tepat untuk berurusan dengan
publik luar. Subkultur mungkin penentu kuat persyaratan informasi, ketersediaan, dan
penggunaan.

Anggota organisasi dapat menjadi anggota satu atau lebih subkultur dalam organisasi.
Subkultur dapat memberikan pengaruh yang kuat pada perilaku anggota, termasuk
sanksi untuk atau terhadap penggunaan sistem informasi.

Memahami dan mengenali subkultur organisasi yang dominan dapat membantu analis
sistem mengatasi penolakan terhadap perubahan yang muncul ketika sistem informasi
baru dipasang. Misalnya, analis mungkin merancang pelatihan pengguna untuk
mengatasi masalah khusus subkultur organisasi. Mengidentifikasi subkultur juga
dapat membantu dalam desain sistem pendukung keputusan yang disesuaikan untuk
interaksi dengan kelompok pengguna tertentu.

RINGKASAN

Ada tiga dasar organisasi yang luas untuk dipertimbangkan ketika menganalisis dan
merancang sistem informasi: konsep organisasi sebagai sistem, berbagai tingkat
manajemen, dan budaya organisasi secara keseluruhan.

Organisasi adalah sistem yang kompleks yang terdiri dari subsistem yang saling
terkait dan interdependen. Selain itu, sistem dan subsistem dicirikan oleh lingkungan
internal mereka pada suatu rangkaian dari terbuka ke tertutup. Sistem terbuka
memungkinkan pengiriman sumber daya secara gratis (orang, informasi, materi)
melalui batas-batasnya; sistem tertutup tidak mengizinkan aliran bebas input atau
output. Organisasi dan tim juga dapat diatur secara virtual dengan anggota jarak jauh
yang terhubung secara elektronik yang tidak berada di ruang kerja fisik yang sama.
Sistem perencanaan sumber daya perusahaan adalah sistem informasi organisasi
(perusahaan) terintegrasi yang dikembangkan dengan perangkat lunak khusus yang
disesuaikan yang membantu aliran informasi di antara area fungsional
di dalam organisasi. Mereka mendukung pandangan sistem organisasi.