Bab 3 Manajamen Proyek-1

BAB 3 .
MANAJEMEN PROYEK 1
BAB 3
Manajemen proyek
INISIASI PROYEK
Proyek sistem diprakarsai oleh berbagai sumber karena berbagai alasan. Beberapa proyek disarankan
akan selamat dari berbagai tahap evaluasi untuk dikerjakan oleh Anda (atau Anda dan Anda tim); yang
lain tidak akan dan tidak seharusnya sejauh itu. Pengusaha menyarankan proyek sistem untuk duaalasan
luas: (1) karena mereka mengalami masalah yang cocok untuk solusi sistem, dan (2) karena mereka
mengenali peluang untuk perbaikan melalui peningkatan, perubahan, atau inovasi. menghentikan sistem
baru ketika itu terjadi. Kedua situasi dapat muncul karena organisasi beradaptasi dengan dan mengatasi
perubahan alami dan evolusi.
Masalah dalam Organisasi
Manajer tidak suka menganggap organisasi mereka memiliki masalah, apalagi dibicarakan mereka atau
membaginya dengan seseorang dari luar. Manajer yang baik, bagaimanapun, menyadari bahwa
pengakuan gejala masalah atau, pada tahap selanjutnya, mendiagnosis masalah itu sendiri dan
kemudian menghadapinya sangat penting jika bisnis ingin tetap berfungsi pada potensi tertinggi.
Masalah muncul dengan berbagai cara. Salah satu cara mengonseptualisasikan masalah apa dan
bagaimana masalah itu muncul adalah dengan menganggapnya sebagai situasi di mana tujuan tidak
pernah tercapai atau tidak ada lagi bertemu. Umpan balik yang bermanfaat memberikan informasi
tentang kesenjangan antara kinerja aktual dan yang dimaksudkan. Dengan cara ini umpan balik
menyoroti masalah.
Dalam beberapa kasus, masalah yang memerlukan layanan analis sistem terbongkar karena
ukuran kinerja tidak terpenuhi. Masalah (atau gejala masalah) dengan proses yang terlihat dalam
keluaran dan yang dapat membutuhkan bantuan analis sistem mencakup kesalahan berlebihan dan
pekerjaan yang dilakukan terlalu lambat, tidak lengkap, salah, atau tidak sama sekali. Kesalahan dan
pekerjaan berlebihan lainnya dilakukan terlalu lambat, tidak lengkap, salah, atau tidak sama sekali. Lain
gejala masalah menjadi jelas ketika orang tidak memenuhi tujuan kinerja awal. Perubahan perilaku
karyawan seperti tingkat absensi tinggi yang tidak biasa, ketidakpuasan kerja yang tinggi, atau turnover
pekerja yang tinggi harus memperingatkan manajer akan masalah potensial. Setiap perubahan ini,
sendirian atau dalam kombinasi, mungkin merupakan alasan yang cukup untuk meminta bantuan analis
sistem.
BAB 3 . MANAJEMEN PROYEK 2
Meskipun kesulitan seperti yang baru saja dijelaskan terjadi di organisasi, umpan balik tentang
caranya yah organisasi sedang memenuhi tujuan yang diharapkan dapat datang dari luar, dalam bentuk
keluhan atau saran dari pelanggan, vendor, atau pemasok, dan penjualan yang hilang atau tiba-tiba lebih
rendah. Ini umpan balik dari lingkungan eksternal sangat penting dan tidak boleh diabaikan.
Ringkasan gejala masalah dan pendekatan yang berguna dalam deteksi masalah tersedia
ditampilkan dalam Gambar 3.1. Perhatikan bahwa memeriksa hasil, mengamati atau meneliti perilaku
karyawan, dan mendengarkan umpan balik dari sumber eksternal semuanya berharga dalam
menemukan masalah. Ketika bereaksi-ing ke akun masalah dalam organisasi, analis sistem memainkan
peran konsultan, ahli pendukung, dan agen perubahan, sebagaimana dibahas dalam Bab 1. Seperti yang
Anda harapkan, peran untuk analis sistem bergeser secara halus ketika proyek dimulai karena fokusnya
adalah pada peluang untuk perbaikan daripada pada kebutuhan untuk menyelesaikan masalah.
Mendefinisikan Masalah
Apakah menggunakan SDLC klasik atau pendekatan berorientasi objek, analis pertama mendefinisikan
masalah dan tujuan sistem. Ini membentuk dasar untuk menentukan apa yang perlu dicapai oleh sistem.
Metode seperti Six Sigma (lihat Bab 16 untuk detail) mulai dengan definisi masalah
Definisi masalah biasanya berisi semacam pernyataan masalah, dirangkum dalam satu atau dua
paragraf. Ini diikuti oleh serangkaian masalah, atau bagian utama, masalah yang independen. Masalah-
masalah tersebut diikuti oleh serangkaian tujuan, atau tujuan yang sesuai dengan masalah tersebut poin
demi poin. Masalah adalah situasi saat ini; tujuan adalah situasi yang diinginkan. Tujuannya mungkin
sangat spesifik atau kata-kata menggunakan pernyataan umum.
Berikut adalah beberapa contoh pertanyaan bisnis yang berkaitan dengan tujuan bisnis:
- Apa tujuan bisnis ini?
- Apakah bisnis itu untung atau nirlaba?
- Apakah perusahaan berencana untuk tumbuh atau berkembang?
- Bagaimana sikap (budaya) bisnis tentang teknologi?
- Berapa anggaran bisnis untuk TI?
- Apakah staf bisnis memiliki keahlian?
Tidak perlu dikatakan, analis sistem perlu memahami cara kerja suatu bisnis.
Bagian terakhir dari definisi masalah berisi persyaratan, hal-hal yang harus dicapai Dijelaskan,
bersama dengan solusi yang mungkin dan kendala yang membatasi pengembangan sistem. Bagian
persyaratan dapat mencakup keamanan, kegunaan, persyaratan pemerintah, dan begitu seterusnya.
Kendala seringkali termasuk kata tidak, yang menunjukkan batasan, dan mungkin berisi pengembalian
anggaran pembatasan atau batasan waktu.
Definisi masalah dihasilkan setelah menyelesaikan wawancara, observasi, dan dokumen analisis
dengan pengguna. Hasil dari pengumpulan informasi ini adalah banyak fakta dan penting pendapat yang
membutuhkan ringkasan. Langkah pertama dalam menghasilkan definisi masalah adalah menemukan
nomorr poin yang dapat dimasukkan dalam satu masalah.
Poin utama dapat diidentifikasi dalam wawancara di sejumlah cara:
1. Pengguna dapat mengidentifikasi masalah, topik, atau tema yang diulang beberapa kali,
terkadang oleh orang yang berbeda dalam beberapa wawancara.
2. Pengguna dapat berkomunikasi dengan metafora yang sama, seperti mengatakan bisnis
adalah perjalanan, perang, permainan, organisme, mesin, dan sebagainya.
3. Pengguna dapat berbicara panjang lebar tentang suatu topik.
4. Pengguna dapat langsung memberi tahu Anda bahwa "Ini adalah masalah besar."
5. Pengguna dapat berkomunikasi pentingnya dengan bahasa tubuh atau dapat berbicara
dengan tegas pada isu.
6. Masalahnya mungkin hal pertama yang disebutkan oleh pengguna.
Setelah masalah telah dibuat, tujuan harus dinyatakan. Kadang-kadang analis mungkin harus
melakukan wawancara lanjutan untuk mendapatkan informasi yang lebih tepat tentang tujuan. Setelah
tujuan dinyatakan, kepentingan relatif dari masalah atau tujuan harus ditentukan. Jika tidak ada cukup
dana untuk mengembangkan sistem yang lengkap, tujuan yang paling kritis harus diselesaikan dulu.
Identifikasi tujuan paling kritis paling baik dilakukan oleh pengguna (dengan dukungan analis), karena
pengguna adalah pakar domain di bidang bisnis mereka dan cara mereka bekerja paling baik dengan
teknologi dalam organisasi.
Salah satu teknik adalah meminta pengguna untuk menetapkan bobot untuk setiap masalah
atau tujuan yang pertama konsep definisi masalah. Ini adalah penilaian subyektif oleh pengguna, tetapi,
jika sejumlah pengguna semua memberi bobot dan rata-rata secara bersama-sama, hasilnya mungkin
mencerminkan gambaran yang lebih besar. Af-Jika bobot telah ditentukan, masalah definisi masalah dan
tujuan adalah Diurutkan agar mengurangi kepentingan, masalah yang paling penting terdaftar pertama.
Ada perangkat lunak seperti Expert Choice (www.expertchoice.com) dan perangkat lunak pendukung
keputusan lainnya yang dapat membantu menentukan bobot dan memprioritaskan tujuan.
Selain melihat melalui data dan mewawancarai orang-orang, cobalah untuk menyaksikan
masalahnya secara langsung. Ketika melihat situasi yang sama, seorang karyawan dapat melihat masalah
yang sangat berbeda dari sistem Para analis tidak. Ini juga memberi analis kesempatan untuk
mengkonfirmasi temuan mereka. Lewat sini mereka menggunakan banyak metode, sehingga
memperkuat kasus untuk mengambil tindakan yang tepat.
CONTOH DEFINISI MASALAH: MELAYANI CATHERINE. Katering Catherine kecil bisnis yang melayani
jamuan makan, resepsi, dan jamuan makan untuk acara bisnis dan sosial seperti makan siang dan
pernikahan. Itu terinspirasi oleh kecintaan Catherine pada memasak dan bakatnya menyiapkan makanan
enak. Pada awalnya itu adalah perusahaan kecil dengan beberapa karyawan bekerja proyek kecil.
Catherine bertemu dengan pelanggan untuk menentukan jumlah orang, tipe makanan, dan informasi
lain yang diperlukan untuk memenuhi suatu acara. Sebagai reputasi mereka untuk menciptakan yang
luar biasa makanan dan kualitas layanan mulai berkembang, jumlah acara mulai meningkat. Itu
membangun pusat konvensi baru, bersama dengan komunitas bisnis yang makmur di kota,
meningkatkan jumlah acara katering.
Catherine dapat mengelola bisnis menggunakan spreadsheet dan pengolah kata menemukan
kesulitan dalam mengikuti telepon tak berujung tentang jenis makanan apa yang tersedia- mampu,
perubahan jumlah tamu yang menghadiri acara, dan ketersediaan spesialisasi barang-barang etaris,
seperti vegan, vegetarian, rendah lemak, rendah karbohidrat, dan sebagainya. Milik Catherine
keputusan untuk mempekerjakan sejumlah karyawan paruh waktu untuk memasak dan melayani acara
berarti bahwa kerumitan personel penjadwalan semakin membebani sumber daya manusia baru
manajer. Catherine memutuskan untuk menyewa perusahaan konsultan bisnis dan TI untuk membantu
alamatnya masalah yang dihadapi perusahaan kateringnya.
Setelah melakukan wawancara dan mengamati sejumlah staf kunci, para konsultan menemukan
keprihatinan berikut:
1. Master chef memesan persediaan (produksi, daging, dan sebagainya) dari pemasok untuk
setiap acara. Pemasok akan memberikan diskon jika jumlah yang lebih besar dipesan pada satu waktu
untuk semua peristiwa yang terjadi dalam kerangka waktu tertentu.
2. Pelanggan sering dipanggil untuk mengubah jumlah tamu untuk suatu acara, dengan
beberapa perubahan dibuat hanya satu atau dua hari sebelum acara dijadwalkan.
3. Terlalu menyita waktu untuk Catherine dan stafnya untuk menangani setiap permintaan
katering, dengan sekitar 60 persen dari panggilan yang menghasilkan kontrak.
4. Konflik dalam jadwal karyawan terjadi dan beberapa acara kekurangan staf. Keluhan tentang ketepatan
waktu layanan menjadi lebih sering.
5. Catherine tidak memiliki informasi ringkasan tentang jumlah acara dan jenis makanan Akan sangat
membantu jika memiliki informasi tren yang akan membantu membimbing pelanggannya dalam pilihan
makanan mereka.
6. Acara sering diadakan di hotel atau ruang pertemuan lainnya, yang menyediakan pengaturan meja
untuk duduk makan bawah. Ada masalah dengan memiliki cukup pelayan dan perubahan dengan
jumlah tamu.
Definisi masalah ditunjukkan pada Gambar 3.2. Perhatikan bobot di

sebelah kanan, mewakili rata-rata dari bobot yang diberikan oleh setiap
karyawan. Tujuan sesuai dengan masalah. Setiap keberatan- tive digunakan
untuk membuat persyaratan pengguna.
Persyaratan pengguna kemudian digunakan untuk membuat use case dan diagram use case atau
aliran data proses diagram. Setiap tujuan dapat membuat satu atau beberapa persyaratan pengguna
atau beberapa tujuan dapat membuat satu atau mungkin tidak ada kasus penggunaan (kasus
penggunaan tidak sering dibuat untuk laporan sederhana), atau setiap persyaratan dapat membuat satu
proses diagram alir data.
Persyaratan pengguna untuk Cather- Catering in adalah untuk:
1. Buat situs Web dinamis untuk memungkinkan klien saat ini dan potensial untuk melihat dan
mendapatkan harga informasi untuk berbagai produk yang berbeda.
2. Memungkinkan klien saat ini dan potensial untuk mengirimkan permintaan dengan pilihan
katering mereka, dengan permintaan dialihkan ke manajer akun.
3. Tambahkan klien ke basis data klien, berikan mereka ID pengguna dan kata sandi untuk akses
proyek mereka.
4. Buat situs Web untuk klien untuk melihat dan memperbarui jumlah tamu untuk suatu acara
dan membatasi mengubah jumlah tamu ketika hari acara kurang dari lima hari di masa depan.
5. Dapatkan atau buat perangkat lunak untuk berkomunikasi langsung dengan personel fasilitas
acara.
6. Membuat atau membeli sistem sumber daya manusia untuk menjadwalkan karyawan paruh
waktu, memungkinkan manajemen untuk menambah karyawan dan menjadwalkan mereka
menggunakan sejumlah kendala.
7. Berikan pertanyaan atau laporan dengan informasi ringkasan. Setiap persyaratan dapat digunakan
untuk membuat rencana uji pendahuluan. Karena hanya sedikit informasi yang tersedia- mampu saat
ini, rencana pengujian akan direvisi sebagai proyek berlangsung.
Paket tes sederhana untuk Katering Catherine adalah:
1. Rancang data uji yang akan memungkinkan klien untuk melihat setiap jenis produk yang
berbeda.
2. Tes untuk memastikan bahwa permintaan katering telah dimasukkan dengan data yang valid,
serta masing-masing kemungkinan kondisi data tidak valid (data akan ditentukan kemudian). Pastikan
permintaannya dialihkan ke manajer akun yang sesuai.
3. Uji bahwa semua bidang data lulus semua kriteria validasi untuk setiap bidang. Uji data yang
baik untuk memastikan bahwa klien ditambahkan ke basis data klien, dan bahwa userID dan kata sandi
dengan benar ditugaskan.
4. Buat rencana pengujian yang akan menguji bahwa klien dapat melihat informasi acara. Uji itu
pembaruan tidak dapat dilakukan dalam waktu lima hari sejak acara. Rancang data uji yang akan
diperiksa memastikan pembaruan jumlah tamu untuk suatu acara dengan benar.
5. Uji bahwa perangkat lunak berfungsi dengan benar untuk berkomunikasi langsung dengan
personel fasilitas acara.
6. Uji sistem sumber daya manusia untuk menjadwalkan karyawan paruh waktu, memeriksa itu
karyawan telah ditambahkan dengan benar dan bahwa semua nilai yang tidak valid untuk setiap bidang
terdeteksi dan dilaporkan. Periksa perangkat lunak penjadwalan untuk pembaruan yang valid dan setiap
entri tidak valid.
7. Periksa apakah semua pertanyaan atau laporan berfungsi dengan benar dan berisi ringkasan
yang benar informasi.
Pemilihan Proyek
Proyek berasal dari berbagai sumber dan karena berbagai alasan. Tidak semua harus dipilih pelajaran
lanjutan. Anda harus jernih dalam pikiran Anda sendiri tentang alasan untuk merekomendasikan suatu
sistem belajar pada proyek yang tampaknya mengatasi masalah atau bisa membawa perbaikan.
Mempertimbangkan motivasi yang mendorong proposal pada proyek. Anda harus yakin bahwa proyek
sedang berjalan pertimbangan tidak diusulkan hanya untuk meningkatkan reputasi atau kekuasaan
politik Anda sendiri, atau orang atau kelompok yang mengusulkannya, karena ada kemungkinan besar
proyek semacam itu akan melakukannya menjadi salah dipahami dan akhirnya diterima dengan buruk.
Sebagaimana diuraikan dalam Bab 2, proyek prospektif perlu diperiksa dari perspektif sistem. tive
sedemikian rupa sehingga Anda mempertimbangkan dampak dari perubahan yang diusulkan pada
seluruh organisasi nisasi. Ingatlah bahwa berbagai subsistem organisasi saling terkait dan saling
tergantung, sehingga perubahan ke satu subsistem dapat memengaruhi yang lainnya. Meskipun Para
pembuat sion yang terlibat langsung pada akhirnya menetapkan batasan untuk proyek sistem, sebuah
sistem proyek tidak dapat direnungkan atau dipilih secara terpisah dari bagian lain dari organisasi.
Di luar pertimbangan umum ini ada lima kriteria khusus untuk pemilihan proyek:
1. Dukungan dari manajemen.

2. Waktu yang tepat dari komitmen proyek.
3. Kemungkinan meningkatkan pencapaian tujuan organisasi.
4. Praktis dalam hal sumber daya untuk analis dan organisasi sistem.
5. Proyek yang berharga dibandingkan dengan cara lain organisasi dapat menginvestasikan sumber
daya.
Pertama dan terpenting adalah dukungan dari manajemen. Sama sekali tidak ada yang bisa
dicapai tanpa dukungan dari orang-orang yang akhirnya akan membayar tagihan. Pernyataan ini tidak
berarti Anda tidak memiliki pengaruh dalam mengarahkan proyek atau orang lain selain manajemen
tidak bisa dimasukkan, tetapi dukungan manajemen sangat penting.
Kriteria penting lainnya untuk pemilihan proyek termasuk waktu untuk Anda dan organisasi.
tion. Tanyakan pada diri Anda dan orang lain yang terlibat apakah bisnis saat ini mampu menghasilkan
komitmen waktu untuk pemasangan sistem baru atau peningkatan yang sudah ada. Kamu harus juga
dapat melakukan seluruh atau sebagian dari waktu Anda selama durasi berlangsung.
Kriteria ketiga adalah kemungkinan untuk meningkatkan pencapaian tujuan organisasi seperti
(1) meningkatkan laba perusahaan, (2) mendukung strategi kompetitif organisasi, (3) meningkatkan
membuktikan kerjasama dengan vendor dan mitra, (4) meningkatkan dukungan operasi internal
sehingga barang dan jasa diproduksi secara efisien dan efektif, (5) meningkatkan dukungan keputusan
internal sehingga keputusan lebih efektif, (6) meningkatkan layanan pelanggan, dan (7) meningkatkan
karyawan moral. Proyek harus menempatkan organisasi pada target, bukan mencegahnya dari tujuan
utamanya.
Kriteria keempat adalah memilih proyek yang praktis dalam hal sumber daya dan kapasitas Anda.
pability serta bisnis. Beberapa proyek tidak akan jatuh dalam ranah pengalaman Anda tise, dan Anda
harus bisa mengenalinya.
Akhirnya, Anda perlu mencapai kesepakatan dasar dengan organisasi tentang kelayakan proyek
sistem relatif terhadap proyek lain yang mungkin dipertimbangkan. Ada banyak kesesuaian untuk
peningkatan, termasuk, (1) mempercepat proses, (2) merampingkan suatu proses melalui penghapusan
langkah-langkah yang tidak perlu atau digandakan, (3) menggabungkan proses, (4) reduksi memasukkan
input melalui perubahan bentuk dan tampilan layar, (5) mengurangi penyimpanan yang berlebihan, (6)
mengurangi output yang berlebihan, dan (7) meningkatkan integrasi sistem dan subsistem. Kembali-
anggotanya bahwa ketika suatu bisnis berkomitmen pada satu proyek, itu adalah melakukan sumber
daya yang dengan demikian menjadi datang tidak tersedia untuk proyek lain. Sangat berguna untuk
melihat semua proyek yang mungkin bersaing untuk sumber daya bisnis waktu, uang, dan orang.
MENENTUKAN KELAYAKAN
Setelah jumlah proyek dipersempit sesuai dengan kriteria yang dibahas sebelumnya, itu masih
perlu untuk menentukan apakah proyek yang dipilih layak. Definisi kelayakan kami jauh lebih dalam
daripada penggunaan istilah yang umum, karena sistem memproyeksikan kelayakan adalah terungkap
dalam tiga cara utama: secara operasional, teknis, dan ekonomis. Studi kelayakan bukan studi sistem
full-blown. Sebaliknya, studi kelayakan digunakan untuk mengumpulkan data luas untuk anggota
manajemen yang pada gilirannya memungkinkan mereka untuk membuat keputusan apakah akan
melanjutkan sebuah studi sistem.
Data untuk studi kelayakan dapat dikumpulkan melalui wawancara, yang dibahas secara rinci di
Bab 4. Jenis wawancara yang diperlukan berkaitan langsung dengan masalah atau peluang yang ada.
disarankan. Analis sistem biasanya mewawancarai mereka yang meminta bantuan dan mereka yang
secara langsung berkaitan dengan proses pengambilan keputusan, biasanya manajemen. Meskipun
penting untuk itu mengatasi masalah yang benar, analis sistem tidak boleh menghabiskan terlalu banyak
waktu melakukan kelayakan studi, karena banyak proyek akan diminta dan hanya sedikit yang dapat atau
harus dieksekusi. Studi kelayakan harus sangat dikompresi waktu, mencakup beberapa kegiatan dalam
waktu singkat rentang waktu.
Menentukan Apakah Itu Mungkin
Setelah seorang analis menentukan tujuan yang masuk akal untuk suatu proyek, analis perlu
menentukan apakah mungkin bagi organisasi dan anggotanya untuk melihat proyek sampai selesai.
Umumnya, proses penilaian kelayakan efektif dalam menyaring proyek-proyek yang tidak sesuai dengan
tujuan bisnis, secara teknis tidak mungkin, atau secara ekonomis tanpa prestasi.
Meskipun melelahkan, mempelajari kelayakan bermanfaat karena menyelamatkan bisnis dan

analis sistem waktu dan uang. Agar analis dapat merekomendasikan pengembangan lebih lanjut, a
proyek harus menunjukkan bahwa itu layak dalam ketiga cara berikut: secara teknis, ekonomi, dan secara
operasional, seperti yang ditunjukkan pada Gambar 3.3.
KELAYAKAN TEKNIS. Analis harus mencari tahu apakah mungkin untuk mengembangkan yang baru
sistem yang diberikan sumber daya teknis saat ini. Jika tidak, dapatkah sistem ditingkatkan atau
ditambahkan ke dalam a cara yang memenuhi permintaan yang dipertimbangkan? Jika sistem yang ada
tidak dapat ditambahkan ke atau ditingkatkan, pertanyaan berikutnya menjadi apakah ada teknologi
yang memenuhi spesifikasi. Pada saat yang sama, analis dapat bertanya apakah organisasi memiliki staf
yang cukup mahir untuk mencapai tujuan. Jika tidak, pertanyaannya adalah apakah mereka dapat
merekrut programmer, penguji, pakar, atau orang lain yang mungkin
memiliki pemrograman berbeda keterampilan dari mereka, atau
mungkin outsourcing proyek sepenuhnya. Masih pertanyaan lain
adalah apakah ada paket perangkat lunak yang tersedia yang dapat
mencapai tujuannya, atau melakukan perangkat lunak perlu
disesuaikan untuk organisasi?
KELAYAKAN EKONOMI. Kelayakan ekonomi adalah bagian kedua dari penentuan sumber daya. Itu
sumber daya dasar untuk dipertimbangkan adalah waktu Anda dan tim analisis sistem, biaya untuk
melakukannya studi sistem lengkap (termasuk waktu karyawan Anda akan bekerja dengan), biaya waktu
karyawan bisnis, taksiran biaya perangkat keras, dan taksiran biaya perangkat lunak atau pengembangan
perangkat lunak. Bisnis yang bersangkutan harus dapat melihat nilai investasi yang direnungkan
sebelumnya berkomitmen untuk mempelajari seluruh sistem. Jika biaya jangk pendek tidak dibayangi
oleh jangka panjang mendapatkan atau tidak menghasilkan pengurangan langsung dalam biaya operasi,
sistem ini tidak ekonomis sible dan proyek tidak boleh dilanjutkan lebih jauh.
KELAYAKAN OPERASIONAL. Misalkan sesaat bahwa sumber daya

teknis dan ekonomi keduanya dinilai cukup. Analis sistem masih harus
mempertimbangkan kelayakan operasional proyek yang diminta.
Kelayakan operasional tergantung pada sumber daya manusia yang tersedia untuk memproyeksikan dan
melibatkan memproyeksikan apakah sistem akan beroperasi dan digunakan setelah diinstal. Jika
pengguna benar-benar menikah dengan sistem saat ini, tidak melihat masalah dengannya, dan
umumnya demikian tidak terlibat dalam meminta sistem baru, resistensi terhadap penerapan sistem
baru akan kuat. Peluang untuk itu menjadi operasional rendah. Atau, jika pengguna sendiri telah
menyatakan kebutuhan akan sistem yang lebih operasional pada saat itu, dengan cara yang lebih efisien
dan mudah diakses, kemungkinan lebih baik bahwa sistem yang diminta tem akhirnya akan digunakan.
Banyak seni menentukan kelayakan operasional terletak pada antarmuka pengguna yang dipilih, seperti
yang kita lihat di Bab 14.
MEMUTUSKAN PERANGKAT KERAS DAN KEBUTUHAN PERANGKAT LUNAK
Menilai kelayakan teknis termasuk mengevaluasi kemampuan perangkat keras dan perangkat lunak
komputer untuk menangani beban kerja secara memadai.
Gambar 3.4 menunjukkan langkah-langkah yang diambil oleh analis sistem ing kebutuhan perangkat
keras dan lunak. Pertama, semua perangkat keras komputer saat ini yang dimiliki organisasi harus
diinventarisasi untuk menemukan apa yang ada dan apa yang dapat digunakan. Analis sistem perlu
bekerja dengan pengguna untuk menentukan perangkat keras apa yang akan dibutuhkan. Penentuan
perangkat keras hanya dapat dilakukan bersamaan dengan penentuan informasi manusia
Persyaratan. Pengetahuan tentang struktur organisasi (seperti dibahas pada Bab 2) dan bagaimana
pengguna berinteraksi dengan teknologi dalam pengaturan organisasi juga dapat membantu dalam
perangkat keras keputusan Hanya ketika analis sistem, pengguna, dan manajemen memiliki pemahaman
yang baik tentang jenis apa tugas harus diselesaikan, dapatkah opsi perangkat keras dipertimbangkan.
Inventarisasi Perangkat Keras Komputer
Mulailah dengan menginventarisir perangkat keras komputer apa yang sudah tersedia di organisasi.
Seperti yang akan menjadi jelas, beberapa opsi perangkat keras melibatkan perluasan atau daur ulang
perangkat keras saat ini, jadi penting untuk mengetahui apa yang ada di tangan. Jika inventaris perangkat
keras komputer yang diperbarui tidak tersedia, analis sistem perlu mengatur satu dengan cepat dan
meneruskannya.
Anda perlu mengetahui hal berikut:
1. Jenis peralatan: nomor model, pabrikan.
2. Status pengoperasian peralatan: sesuai pesanan, beroperasi, dalam penyimpanan,

membutuhkan perbaikan.
3. Perkiraan usia peralatan.
4. Kehidupan peralatan yang diproyeksikan.
5. Lokasi fisik peralatan.
6. Departemen atau orang yang dianggap bertanggung jawab atas peralatan.
7. Pengaturan keuangan untuk peralatan: dimiliki, disewakan, disewa.
Memastikan perangkat keras saat ini tersedia akan menghasilkan proses pengambilan
keputusan yang lebih baik ketika keputusan perangkat keras akhirnya dibuat, karena banyak dugaan
tentang apa yang ada akan dihilangkan. Melalui wawancara sebelumnya dengan pengguna, kuesioner
mensurvei mereka, dan mencari data arsip, Anda sudah akan tahu jumlah orang yang tersedia untuk
pemrosesan data serta keterampilan dan kemampuan mereka. Gunakan informasi ini untuk
memproyeksikan seberapa baik stafnya kebutuhan akan perangkat keras baru dapat terpenuhi.
Memperkirakan Beban Kerja

Langkah selanjutnya dalam memastikan kebutuhan perangkat keras adalah memperkirakan beban kerja.
Dengan demikian, analis sistem angka awal yang mewakili beban kerja saat ini dan yang diproyeksikan
untuk sistem sehingga ada perangkat keras yang diperoleh akan memiliki kemampuan untuk menangani
beban kerja saat ini dan masa depan.
Jika perkiraan dicapai dengan benar, bisnis tidak harus mengganti perangkat keras semata karena
pertumbuhan yang tidak terduga dalam penggunaan sistem. (Namun, acara lain, seperti teknologi
novations, dapat menentuka penggantian perangkat keras jika bisnis ingin mempertahankan keunggulan
kompetitifnya.) Karena kebutuhan, beban kerja disampel daripada benar-benar dimasukkan ke beberapa
komputer sistem.
Pedoman yang diberikan pada pengambilan sampel pada Bab 5 dapat digunakan di sini, karena
dalam beban kerja sampling, analis sistem mengambil sampel tugas yang
diperlukan dan sumber daya komputer diminta untuk menyelesaikannya.
Gambar 3.5 adalah perbandingan waktu yang dibutuhkan oleh informasi yang ada dan yang
diusulkan sistem yang seharusnya menangani beban kerja yang diberikan. Perhatikan bahwa perusahaan
saat ini menggunakan sistem komputer lama untuk menyiapkan ringkasan pengiriman ke gudang
distribusinya, dan dasbor berbasis web sedang disarankan. Perbandingan beban kerja melihat kapan dan
bagaimana setiap proses dilakukan, berapa banyak waktu manusia diperlukan, dan berapa banyak waktu
komputer diperlukan Perhatikan bahwa sistem yang baru diusulkan harus mengurangi waktu manusia
dan komputer yang diperlukan secara signifikan.
Mengevaluasi Perangkat Keras Komputer
Mengevaluasi perangkat keras komputer adalah tanggung jawab bersama manajemen,

pengguna, dan sistem. alysts. Meskipun vendor akan memberikan rincian tentang penawaran khusus
mereka, analis perlu untuk mengawasi proses evaluasi secara pribadi karena mereka akan memiliki
kepentingan terbaik dari bisnis di hati. Selain itu, analis sistem mungkin harus mendidik pengguna dan
manajemen tentang keuntungan dan kerugian umum dari perangkat keras sebelum mereka dapat
mengevaluasinya.
Berdasarkan inventaris terkini dari peralatan komputer dan taksiran memadai atas arus dan
perkiraan beban kerja, langkah selanjutnya dalam proses ini adalah mempertimbangkan jenis peralatan
yang tersedia itu tampaknya memenuhi kebutuhan yang diproyeksikan. Informasi dari vendor tentang
kemungkinan sistem dan konfigurasi sistem urations menjadi lebih relevan pada tahap ini dan harus
ditinjau dengan manajemen dan pengguna. Selain itu, beban kerja dapat disimulasikan dan dijalankan
pada sistem yang berbeda, termasuk yang sudah ada digunakan dalam organisasi. Proses ini disebut
sebagai pembandingan.
Kriteria yang harus digunakan analis dan pengguna sistem untuk mengevaluasi kinerja yang
berbeda perangkat keras sistem meliputi:
1. Waktu yang diperlukan untuk transaksi rata-rata (termasuk berapa lama untuk memasukkan
data dan berapa lama untuk menerima output).
2. Total kapasitas volume sistem (berapa banyak yang dapat diproses pada saat yang sama
sebelum masalah muncul).
3. Waktu idle CPU atau jaringan.

4. Ukuran memori yang disediakan.
Beberapa kriteria akan ditampilkan dalam demonstrasi formal; beberapa tidak dapat
disimulasikan dan harus diperoleh dari spesifikasi pabrik. Penting untuk menjadi jelas tentang yang
diperlukan dan fungsi yang diinginkan sebelum terlalu larut dalam klaim vendor selama demonstrasi.
Setelah persyaratan fungsional diketahui dan produk saat ini tersedia, dibela dan dibandingkan
dengan apa yang sudah ada dalam organisasi, keputusan dibuat oleh sistem Para analis bersama dengan
pengguna dan manajemen tentang apakah memperoleh perangkat keras baru diperlukan. Opsi dapat
dianggap sebagai yang ada pada kontinum dari hanya menggunakan peralatan siap tersedia dalam bisnis
hingga memperoleh peralatan yang sepenuhnya baru. Di antara keduanya opsi untuk membuat
modifikasi kecil atau besar pada sistem komputer yang ada.
UKURAN KOMPUTER DAN PENGGUNAAN. Kemajuan teknologi yang cepat menentukan bahwa
analis sistem jenis penelitian dari komputer yang tersedia pada waktu tertentu dimana proposal sistem
sedang tertulis. Ukuran komputer berkisar dari ponsel mini hingga ukuran kamar superkomputer.
Masing-masing memiliki atribut berbeda yang harus dipertimbangkan ketika memutuskan bagaimana
caranya menerapkan sistem komputer.
Akuisisi Peralatan Komputer
Tiga opsi utama untuk akuisisi perangkat keras komputer adalah membeli, menyewakan, atau
menyewanya. Ada kelebihan dan kekurangan yang harus ditimbang untuk setiap keputusan, seperti
ditunjukkan pada Gambar 3.6. Beberapa faktor yang lebih berpengaruh untuk dipertimbangkan dalam
memutuskan opsi mana terbaik untuk instalasi tertentu termasuk biaya awal versus jangka panjang,
apakah bisnis dapat mampu mengikat modal dalam peralatan komputer, dan apakah bisnis
menginginkan kontrol penuh dan tanggung jawab untuk peralatan komputer.
Membeli menyiratkan bahwa bisnis itu sendiri akan memiliki peralatan. Salah satu penentu
utama apakah akan membeli adalah proyeksi masa pakai sistem. Jika sistem akan digunakan lebih lama
dari empat hingga lima tahun (dengan semua faktor lain dianggap konstan), keputusan biasanya dibuat
untuk membeli. Perhatikan di contoh pada Gambar 3.7 bahwa biaya pembelian setelah tiga tahun lebih
rendah daripada biaya sewa atau menyewa. Ketika sistem menjadi lebih kecil, lebih kuat, dan lebih
murah, dan sebagai sistem terdistribusi mereka menjadi lebih populer, lebih banyak bisnis memutuskan
untuk membeli peralatan.
Menyewa, daripada membeli, perangkat keras komputer adalah kemungkinan lain. Peralatan
sewa ment dari vendor atau perusahaan leasing pihak ketiga lebih praktis ketika kehidupan
diproyeksikan dari sistem ini kurang dari empat tahun. Selain itu, jika perubahan signifikan dalam
teknologi sudah dekat, leasing adalah pilihan yang lebih baik. Leasing juga memungkinkan bisnis untuk
menaruh uangnya di tempat lain, di mana ia berada dapat bekerja untuk perusahaan daripada diikat
dalam peralatan modal. Selama periode yang panjang,
Namun, leasing bukanlah cara yang ekonomis untuk

mendapatkan peralatan komputer. Menyewa perangkat keras komputer
adalah pilihan utama ketiga untuk akuisisi komputer. Salah satunya
keuntungan utama dari menyewa adalah tidak ada modal perusahaan
yang terikat, dan karenanya tidak ada diperlukan. Juga, menyewa perangkat keras komputer
membuatnya lebih mudah untuk mengubah perangkat keras sistem. Fi- Pada akhirnya, perawatan dan
asuransi biasanya dimasukkan dalam perjanjian sewa. Karena tingginya biaya yang terlibat dan fakta
bahwa perusahaan tidak akan memiliki peralatan yang disewa, namun ing harus direnungkan hanya
sebagai langkah jangka pendek untuk menangani komunikasi yang tidak berulang atau terbatas
kebutuhan komputer atau waktu teknologi yang fluktuatif.
EVALUASI DUKUNGAN VENDOR UNTUK PERANGKAT KERAS KOMPUTER. Beberapa bidang utama
seharusnya dievaluasi ketika menimbang layanan dukungan yang tersedia untuk bisnis dari vendor.
Paling vendor menawarkan pengujian perangkat keras pada pengiriman dan garansi 90 hari yang
mencakup segala cacat pabrik, tetapi Anda harus memastikan apa lagi yang ditawarkan vendor. Vendor
dengan kualitas yang sebanding sering membedakan diri dari orang lain dengan
berbagai layanan dukungan yang mereka tawarkan. Daftar kriteria kunci yang harus
diperiksa ketika mengevaluasi dukungan vendor disediakan di Gambar 3.8. Sebagian
besar layanan dukungan vendor tambahan yang terdaftar di sana dinegosiasikan secara terpisah kontrak
sewa atau pembelian perangkat keras. Layanan dukungan termasuk pemeliharaan perangkat keras yang
rutin dan preventif, mensponsori waktu (dalam waktu enam jam, hari kerja berikutnya, dll.) jika terjadi
kerusakan peralatan darurat
down, pinjaman peralatan jika perangkat keras harus diganti secara permanen atau di luar lokasi
perbaikan diperlukan, dan pelatihan in-house atau seminar grup di luar lokasi untuk pengguna.
Membaca dengan teliti dukungan dokumen layanan yang menyertai pembelian atau penyewaan
peralatan dan jangan lupa untuk terlibat staf hukum yang tepat sebelum menandatangani kontrak untuk
peralatan atau layanan. Sayangnya, mengevaluasi perangkat keras komputer tidak sesederhana
membandingkan biaya dan memilih opsi yang paling murah.
Beberapa peristiwa lain yang biasa muncul pengguna dan manajemen meliputi (1) kemungkinan
menambahkan ke sistem jika perlu muncul kemudian; (2) kemungkinan berinteraksi dengan peralatan
dari vendor lain jika sistem perlu tumbuh; (3) manfaat membeli lebih banyak memori daripada yang
diproyeksikan seperlunya, dengan harapan bahwa bisnis pada akhirnya akan "tumbuh ke dalamnya";
dan (4) stabilitas perusahaan dari vendor. Persaingan di antara vendor telah membuat ide untuk
memproduksi perangkat keras yang kompatibel dengan perangkat keras pesaing yang penting bagi
kelangsungan hidup vendor. Sebelum menjadi yakin akan hal itu membeli kompatibilitas yang lebih
murah adalah cara untuk memberikan kemampuan tambahan pada sistem Anda, lakukan riset yang
cukup untuk merasa yakin bahwa vendor asli adalah entitas perusahaan yang stabil.
Evaluasi Perangkat Lunak
Analis dan organisasi semakin dihadapkan dengan keputusan membuat, membeli, atau melakukan
outsourcing kapan menilai perangkat lunak untuk proyek sistem informasi, terutama ketika
mempertimbangkan peningkatan ke sistem yang ada atau warisan.
Anda telah melihat keputusan yang diambil analis ketika memutuskan untuk menyewa, membeli, atau
menyewakan Perangkat keras. Beberapa pengambilan keputusan seputar pembelian iklan komersial
Perangkat lunak (COTS), “rental” perangkat lunak dari penyedia layanan aplikasi (ASP), atau pembuatan
perangkat lunak khusus untuk proyek ini analog dengan proses keputusan perangkat keras.
Perlu dicatat bahwa terlepas dari apakah Anda mengembangkan perangkat lunak atau membeli produk
COTS Untuk proyek tertentu, sangat penting untuk menyelesaikan analisis kebutuhan informasi manusia
sis pengguna dan sistem yang mereka gunakan pertama (seperti yang dibahas dalam bab sebelumnya).
Sebagai seorang analis, bagian dari keahlian yang Anda kembangkan adalah membuat penilaian yang
baik mengenai pengembangan perangkat lunak.
ware versus pembelian perangkat lunak COTS untuk sistem baru dan yang sudah ada. Bagian
berikut diskusikan kapan membuat perangkat lunak Anda sendiri, kapan membeli paket COTS, dan kapan
menggunakannya sebuah ASP. Gambar 3.9 merangkum kelebihan dan kekurangan dari masing-masing
opsi ini.
KAPAN MEMBUAT PERANGKAT LUNAK KUSTOM. Ada beberapa situasi yang membutuhkan
penciptaan perangkat lunak asli atau komponen perangkat lunak. Contoh yang paling mungkin adalah
ketika perangkat lunak COTS melakukannya tidak ada atau tidak dapat diidentifikasi untuk aplikasi yang
diinginkan. Atau, perangkat lunak mungkin ada tetapi tidak terjangkau atau tidak mudah dibeli atau
dilisensikan.
Perangkat lunak asli harus dibuat ketika organisasi berusaha untuk mendapatkan Keuntungan
tive melalui penggunaan sistem informasi yang diungkit. Ini sering
terjadi ketika seorang organisasi membuat e-niaga atau aplikasi inovatif
lainnya di mana tidak ada. Itu juga mungkin bahwa organisasi adalah
"penggerak pertama" dalam penggunaan teknologi tertentu atau
industri tertentu. Organisasi yang memiliki persyaratan sangat khusus atau ada di industri niche
Mencoba juga dapat mengambil manfaat dari perangkat lunak asli.
Keuntungan membuat perangkat lunak Anda sendiri termasuk mampu merespons pengguna khusus
dan kebutuhan bisnis, memperoleh keunggulan kompetitif dengan menciptakan perangkat lunak
inovatif, memiliki staf rumah tersedia untuk memelihara perangkat lunak, dan kebanggaan memiliki
sesuatu yang telah Anda buat. Kelemahan dari pengembangan perangkat lunak Anda sendiri termasuk
potensi untuk secara signifikan biaya awal yang lebih tinggi dibandingkan dengan pembelian perangkat
lunak COTS atau kontrak dengan ASP, kebutuhan untuk mempekerjakan atau bekerja dengan tim
pengembangan, dan fakta bahwa Anda bertanggung jawab atas hal tersebut pemeliharaan
berkelanjutan karena Anda adalah pembuat perangkat lunak.
KAPAN MEMBELI PERANGKAT LUNAK Boks. Perangkat lunak komersial yang tersedia termasuk
produk sepert Microsoft Office suite, yang mencakup pengolah kata untuk Word, Excel untuk
spreadsheet, Access untuk membangun basis data, dan aplikasi lainnya. Jenis lain dari perangkat lunak
COTS adalah untuk organisasi- sistem level daripada penggunaan kantor atau pribadi. Beberapa
penulis termasuk ERP yang populer (tetapi mahal) paket seperti Oracle dan SAP dalam contoh
perangkat lunak COTS mereka. Paket-paket ini berbeda secara radikal dalam jumlah penyesuaian,
dukungan, dan pemeliharaan yang diperlukan dibandingkan dengan Microsoft Kantor. Perangkat lunak
COTS juga dapat merujuk ke komponen atau objek perangkat lunak (juga disebut bangunan blok) yang
dapat dibeli untuk menyediakan fungsionalitas yang dibutuhkan tertentu dalam suatu sistem.
Pertimbangkan untuk menggunakan perangkat lunak COTS ketika Anda dapat dengan mudah
mengintegrasikan aplikasi atau paket ke dalamnya sistem yang ada atau yang direncanakan, dan ketika
Anda telah mengidentifikasi tidak ada keharusan untuk segera atau melanjutkan terlalu sering ubah
atau sesuaikan untuk pengguna. Prakiraan Anda harus menunjukkan bahwa organisasi Anda
merancang sistem untuk tidak mungkin mengalami perubahan besar setelah pembelian yang diusulkan
perangkat lunak COTS, seperti peningkatan dramatis dalam pelanggan atau ekspansi fisik yang besar.
Ada beberapa keuntungan membeli perangkat lunak COTS yang harus Anda ingat Anda
mempertimbangkan alternatif. Satu keuntungan adalah bahwa produk ini telah disempurnakan melalui
proses penggunaan dan distribusi komersial, sehingga seringkali ada fungsi tambahan dari- Fered.
Keuntungan lain adalah bahwa perangkat lunak yang dikemas biasanya diuji secara luas, dan dengan
demikian sangat bisa diandalkan.
Peningkatan fungsionalitas sering ditawarkan dengan perangkat lunak COTS, karena merupakan
produk komersial kemungkinan memiliki produk saudara, fitur tambahan, dan peningkatan yang
meningkatkan daya tariknya. Iklan- Selain itu, analis sering menemukan bahwa biaya awal perangkat
lunak COTS lebih rendah daripada biaya untuk ada pengembangan perangkat lunak in-house atau
penggunaan ASP.
Keuntungan lain dari pembelian paket COTS termasuk penggunaannya oleh banyak perusahaan
lain. Namun, para analis tidak bereksperimen pada klien mereka dengan aplikasi perangkat lunak satu-
satunya.Terakhir, perangkat lunak COTS menawarkan keuntungan dalam bantuan dan pelatihan yang
menyertai mengejar perangkat lunak yang dikemas.
Salah satu contoh penggunaan perangkat lunak COTS adalah dari perusahaan teater di sektor
nirlaba, di mana organisasi (terutama dalam seni pertunjukan) cenderung ketinggalan untuk
mendapatkan keuntungan mitra dalam adopsi teknologi komunikasi informasi (TIK). Teater- Perusahaan
diduga lambat untuk pindah ke Web. Ketika mereka ingin membuat aplikasi e-commerce Mereka
ditempatkan dalam posisi harus merekrut desainer luar untuk membuat e-commerce aplikasi untuk
mereka. Mengingat biaya dan kurangnya keahlian in-house, banyak organisasi nirlaba atau ganizations
tidak memindahkan bagian bisnis organisasi mereka ke Web, menunggu alih-alih untuk paket COTS,
seperti berbasis PC, perangkat lunak box-office, atau ASP seperti centang online eting agen dengan
otomatisasi sudah ada, untuk membuat layanan ini tersedia untuk pelanggan. Di- pengembangan
perangkat lunak rumahan tidak mungkin dilakukan oleh sebagian besar kelompok ini, yang biasanya
memilikinya staf dan anggaran TI kecil atau tidak ada, dan keahlian TI internal yang minimal.
Ada kerugian untuk penggunaan perangkat lunak COTS. Karena itu tidak dimaksudkan untuk
sepenuhnya tomizable, perusahaan teater kehilangan kemampuannya untuk mengubah perangkat lunak
untuk memasukkan fitur-fitur kunci dalam basis data donornya yang diandalkan oleh pengguna.
Perangkat lunak COTS juga dapat mencakup kesalahan yang bisa terjadi mengekspos organisasi terhadap
masalah tanggung jawab.
Ada kerugian lain yang perlu dipertimbangkan dengan pembelian perangkat lunak COTS, termasuk
fakta bahwa paket diprogram, daripada berfokus pada pengguna manusia yang bekerja di bisnis tidak.
Selain itu, pengguna harus hidup dengan fitur apa pun yang ada dalam perangkat lunak, apakah itu
sesuai atau tidak. Kerugian yang tumbuh dari ini adalah kemampuan kustomisasi terbatas dari sebagian
besar perangkat lunak yang dikemas. Kerugian lain untuk membeli perangkat lunak COTS termasuk
kebutuhan menyelidiki stabilitas keuangan vendor perangkat lunak, dan berkurangnya rasa memiliki dan
komitmen yang tidak terhindarkan ketika perangkat lunak dianggap sebagai produk daripada proses.
Untuk mencapai beberapa perspektif tentang sistem yang sedang dikembangkan, Anda harus
mengenali hal itu setengah dari proyek dibangun dari awal (dua pertiga menggunakan metode
tradisional seperti SDLC dan prototyping dan sepertiga menggunakan teknologi gesit atau berorientasi
objek). Sebagian besar dari ini dikembangkan oped menggunakan tim analisis sistem internal
pemrogram mungkin di rumah atau outsourcing.
Kurang dari setengah dari semua proyek dikembangkan dari aplikasi atau komponen yang ada. Itu
sebagian besar dimodifikasi, beberapa ekstensif. Kurang dari 5 persen perangkat lunak tidak tersedia
perangkat lunak yang tidak memerlukan modifikasi sama sekali.
KAPAN SAAT LAYANAN PERANGKAT LUNAK OUTSOURCE KE PENYEDIA LAYANAN APLIKASI.

Organisasi mungkin menyadari beberapa manfaat dari mengambil pendekatan yang sama sekali berbeda
untuk pengadaan perangkat lunak. Opsi ketiga ini adalah untuk melakukan outsourcing beberapa
kebutuhan perangkat lunak organisasi ke sebuah penyedia layanan aplikasi yang berspesialisasi dalam
aplikasi TI.
Ada manfaat khusus untuk melakukan outsourcing aplikasi ke penyedia layanan aplikasi (ASP).
Misalnya, organisasi yang ingin mempertahankan fokus strategis mereka dan melakukan apa yang
mereka inginkan terbaik di mungkin ingin melakukan outsourcing produksi aplikasi sistem informasi.
Selain itu, outsourcing kebutuhan perangkat lunak seseorang berarti bahwa organisasi yang melakukan
outsourcing mungkin dapat untuk menghindari kebutuhan untuk menyewa, melatih, dan
mempertahankan staf TI yang besar. Ini dapat menghasilkan penghematan yang signifikan.Ketika suatu
organisasi menggunakan ASP, ada sedikit atau tidak ada pengeluaran waktu karyawan yang berharga
tugas TI yang tidak penting (ini ditangani secara profesional oleh ASP).
Menyewa ASP tidak boleh dianggap sebagai formula ajaib untuk mengatasi kebutuhan perangkat
lunak- KASIH. Ada beberapa kelemahan dalam penggunaan ASP yang harus dipertimbangkan secara
serius. Satu dis Keuntungan umum adalah hilangnya kendali atas data perusahaan, sistem informasi,
karyawan TI, dan bahkan jadwal pemrosesan dan proyek. Beberapa perusahaan percaya bahwa inti dari
bisnis mereka adalah informasi mereka, sehingga pikiran melepaskan kendali atas hal itu sangat
menyusahkan. Lain Kerugiannya adalah kekhawatiran atas kelayakan finansial dari ASP yang dipilih.
Mungkin juga ada kekhawatiran tentang keamanan data dan catatan organisasi, serta kekhawatiran
tentang kerahasiaan data dan privasi klien. Akhirnya, ketika memilih ASP, ada potensi kerugian
keunggulan strategis perusahaan yang mungkin diperoleh melalui penyebaran sendiri perusahaan ment
dari aplikasi inovatif yang dibuat oleh karyawan mereka.
EVALUASI DUKUNGAN VENDOR UNTUK PERANGKAT LUNAK DAN ASPS. Apakah Anda membeli
COTS paket atau kontrak untuk layanan ASP, Anda akan berhadapan dengan vendor yang mungkin
memiliki sendiri kepentingan terbaik di hati. Anda harus mau mengevaluasi perangkat lunak dengan
pengguna dan tidak terlalu berlebihan dipengaruhi oleh promosi penjualan vendor. Secara khusus, ada
enam kategori utama untuk menilai perangkat lunak, seperti yang ditunjukkan pada Gambar 3.10:
efektivitas kinerja, efisiensi kinerja, kemudahan penggunaan, fleksibilitas, kualitas dokumentasi, dan
dukungan pabrikan.
Mengevaluasi perangkat lunak yang dikemas berdasarkan demonstrasi dengan data uji dari
konteks bisnismenyampinginya dan memeriksa dokumentasi yang menyertainya. Deskripsi vendor akan
sendiri tidak cukup. Vendor biasanya menyatakan bahwa perangkat lunak berfungsi saat meninggalkan
rumah persediaan mereka, tetapi mereka tidak akan menjamin bahwa itu akan bebas kesalahan di setiap
contoh atau bahwa itu tidak akan crash kapan tindakan yang salah dilakukan oleh pengguna. Jelas,
mereka tidak akan menjamin perangkat lunak paket mereka jika digunakan bersamaan dengan perangkat
keras yang rusak.
IDENTIFIKASI, PERAMALAN, DAN PERBANDINGAN BIAYA DAN MANFAAT
Biaya dan manfaat dari sistem komputer yang diusulkan harus selalu dipertimbangkan bersama, karena
mereka saling terkait dan seringkali saling tergantung. Meskipun analis sistem mencoba untuk
mengusulkan sebuah sistem yang memenuhi berbagai persyaratan informasi, keputusan untuk
melanjutkan dengan yang diusulkan sistem akan didasarkan pada analisis biaya-manfaat, bukan pada
persyaratan informasi. Dalam banyak hal, manfaat diukur dengan biaya, seperti yang terlihat pada
bagian selanjutnya.
Peramalan
Analis sistem diharuskan untuk memprediksi variabel kunci tertentu sebelum proposal diajukan klien.
Pada tingkat tertentu, seorang analis sistem akan bergantung pada analisis bagaimana-jika, seperti,
“Bagaimana jika Biaya bor hanya naik 5 persen per tahun selama tiga tahun ke depan, bukan 10 persen?
” Tetapi analis harus menyadari, bahwa ia tidak dapat mengandalkan analisis bagaimana-jika untuk
semuanya jika proposal ingin dipercaya, bermakna, dan berharga.
Analis sistem memiliki banyak model peramalan yang tersedia. Kondisi utama untuk pilihan-
Model adalah ketersediaan data historis. Jika tidak tersedia, analis harus beralih ke salah satu metode
penilaian: perkiraan dari tenaga penjualan, survei untuk memperkirakan mand, studi Delphi (ramalan
konsensus yang dikembangkan secara independen oleh sekelompok ahli melalui serangkaian iterasi),
membuat skenario, atau menggambar analogi historis.
Jika data historis tersedia, diferensiasi berikutnya antara kelas-kelas teknik melibatkan
apakah ramalan itu kondisional atau tanpa syarat. Bersyarat menyiratkan bahwa ada asosiasi antara
variabel dalam model atau bahwa hubungan sebab akibat seperti itu ada. Metode umum dalam hal ini
kelompok termasuk korelasi, regresi, indikator utama, ekonometrika, dan model input / output.
Peramalan tanpa syarat berarti analis tidak diharuskan untuk menemukan atau
mengidentifikasi sebab akibat hubungan. Akibatnya, analis sistem menemukan bahwa metode ini
berbiaya rendah, mudah mengimplementasikan alternatif. Termasuk dalam kelompok ini adalah
penilaian grafis, rata-rata bergerak, dan analisis data deret waktu. Karena metode ini sederhana, andal,
dan hemat biaya, maka sisa bagian ini berfokus pada mereka.
ESTIMASI TREN. Tren dapat diperkirakan dalam sejumlah cara berbeda. Satu jalan menuju
estimasi tren adalah dengan menggunakan moving average. Metode ini berguna karena beberapa
musiman, siklus, atau pola acak dapat dihaluskan, meninggalkan pola tren. Prinsip di balik bergerak rata-
rata adalah untuk menghitung rata-rata aritmatika data dari sejumlah periode tertentu; tiga bulan
moving average hanyalah rata-rata tiga bulan terakhir. Misalnya, penjualan rata-rata untuk Januari,
Februari, dan Maret digunakan untuk memprediksi penjualan untuk bulan April. Kemudian penjualan
rata-rata untuk Februari, Maret, dan April digunakan untuk memprediksi penjualan untuk Mei, dan
seterusnya.
Ketika hasilnya digambarkan, mudah terlihat bahwa data yang sangat berfluktuasi itu
dihaluskan. Metode moving average berguna untuk kemampuan penghalusannya, tetapi pada saat yang
sama ia memiliki banyak kerugiannya. Rata-rata bergerak lebih kuat dipengaruhi oleh nilai ekstrem
daripada oleh menggunakan penilaian grafis atau memperkirakan menggunakan metode lain seperti
kuadrat terkecil. Analis seharusnya pelajari peramalan dengan baik, karena seringkali memberikan
informasi yang berharga dalam membenarkan seluruh proyek.
Mengidentifikasi Manfaat dan Biaya
Manfaat dan biaya dapat dianggap sebagai berwujud atau tidak berwujud. Baik berwujud maupun tidak
berwujud manfaat dan biaya harus diperhitungkan ketika sistem dipertimbangkan.
MANFAAT TANGIBLE. Manfaat nyata adalah keuntungan yang terukur dalam dolar yang diperoleh dari
organisasi melalui penggunaan sistem informasi. Contoh manfaat nyata adalah peningkatan kecepatan
pemrosesan, akses ke informasi yang tidak dapat diakses, akses ke informasi berdasarkan waktu yang
lebih tepat daripada yang mungkin sebelumnya, keuntungan komputerkemampuan menghitung yang
unggul, dan mengurangi jumlah waktu yang dibutuhkan karyawan untuk menyelesaikannya tugas
khusus. Masih ada yang lain. Meskipun pengukuran tidak selalu mudah, manfaat nyata sebenarnya
dapat diukur dari segi dolar, sumber daya, atau waktu yang dihemat.
MANFAAT TIDAK BERWUJUD. Beberapa manfaat yang diperoleh organisasi dari penggunaan sistem
informasi sulit untuk diukur tetapi tetap penting. Mereka dikenal sebagai manfaat tak berwujud.
Manfaat tak berwujud termasuk meningkatkan proses pengambilan keputusan, meningkatkan

akurasi, menjadi datang lebih kompetitif dalam layanan pelanggan, mempertahankan citra bisnis yang
baik, dan meningkatkan kepuasan kerja bagi karyawan dengan menghilangkan tugas-tugas yang
membosankan. Seperti yang Anda dapat menilai dari daftar diberikan, manfaat tidak berwujud sangat
penting dan dapat memiliki implikasi yang luas untuk bisnis karena berkaitan dengan orang-orang baik di
luar maupun di dalam organisasi.
Meskipun manfaat tidak berwujud dari sistem informasi adalah faktor penting yang harus miring
ketika memutuskan apakah akan melanjutkan dengan sistem, sistem yang dibangun semata-mata karena
tidak berwujudmanfaatnya tidak akan berhasil. Anda harus mendiskusikan manfaat nyata dan tidak
berwujud dalam Anda proposal, karena menghadirkan keduanya akan memungkinkan pengambil
keputusan dalam bisnis untuk membuat sumur keputusan terinformasi tentang sistem yang diusulkan.
BIAYA TANGIBLE. Konsep biaya berwujud dan tidak berwujud menyajikan paralel konseptual
dengan manfaat nyata dan tidak berwujud yang telah dibahas. Biaya berwujud adalah yang bisa
diproyeksikan secara akurat oleh analis sistem dan personel akuntansi bisnis.
Termasuk dalam biaya nyata adalah biaya peralatan seperti komputer dan terminal, biaya
sumber daya, biaya waktu analis sistem, biaya waktu programmer, dan gaji ees. Biaya-biaya ini biasanya
mapan atau dapat ditemukan dengan mudah, dan memang biaya yang akan memerlukan pengeluaran
uang tunai dari bisnis.
BIAYA TIDAK BERWUJUD. Biaya tidak berwujud sulit diperkirakan dan mungkin tidak diketahui.
Mereka termasuk kehilangan keunggulan kompetitif, kehilangan reputasi sebagai yang pertama dengan
inovasi atau pemimpin sebuah lapangan, menurunnya citra perusahaan karena meningkatnya
ketidakpuasan pelanggan, dan tidak efektif pengambilan keputusan karena informasi yang tidak tepat
waktu atau tidak dapat diakses. Seperti yang dapat Anda bayangkan, itu adalah di sebelah mustahil
memproyeksikan jumlah dolar untuk biaya tidak berwujud secara akurat. Untuk membantu pengambil
keputusan siapa ingin mempertimbangkan sistem yang diusulkan dan semua implikasinya, Anda harus
memasukkan biaya tidak berwujud meskipun mereka tidak dapat diukur.
Membandingkan Biaya dan Manfaat
Ada banyak teknik terkenal untuk membandingkan biaya dan manfaat dari sistem yang diusulkan. tem.
Mereka termasuk analisis titik impas, payback, analisis arus kas, dan analisis nilai sekarang. Semua teknik
ini memberikan cara langsung untuk menghasilkan informasi kepada pembuat keputusan tentang
kelayakan sistem yang diusulkan.
ANALISIS BREAK-EVEN. Dengan membandingkan biaya saja, analis sistem dapat menggunakan analisis
titik impas untuk menentukan kapasitas impas dari sistem informasi yang diusulkan. Titik di mana total
biaya sistem saat ini dan sistem yang diusulkan berpotongan mewakili titik impas, titik di mana ia
menjadi menguntungkan bagi bisnis untuk mendapatkan sistem informasi baru.
Total biaya termasuk biaya yang berulang selama operasi sistem ditambah pengembangan biaya
tal yang terjadi hanya sekali (biaya satu kali memasang sistem baru), yaitu, biaya nyata yang baru saja
dibahas. Gambar 3.11 adalah contoh analisis titik impas pada toko kecil itu memelihara inventaris
menggunakan sistem manual. Ketika volume naik, biaya sistem manual naik pada tingkat yang
meningkat. Sistem komputer baru akan membutuhkan biaya yang besar di muka, tetapi dibiaya
cremental untuk volume yang lebih tinggi akan agak kecil. Grafik menunjukkan bahwa sistem komputer
tem akan efektif biaya jika bisnis terjual sekitar 600 unit per minggu.
Analisis impas berguna ketika bisnis tumbuh dan volume adalah variabel kunci di biaya. Salah
satu kelemahan analisis titik impas adalah bahwa manfaat diasumsikan tetap sama, terlepas dari sistem
mana yang ada. Dari penelitian kami tentang manfaat nyata dan tidak berwujud, kami tahu itu jelas
bukan itu masalahnya.
Analisis titik impas juga dapat menentukan berapa lama waktu yang dibutuhkan untuk manfaat
sistem untuk membayar kembali biaya pengembangannya. Gambar 3.12 menggambarkan suatu sistem
dengan periode pengembalian tiga setengah tahun.
ANALISIS TUNAI ARUS. Analisis arus kas memeriksa arah, ukuran, dan pola arus kas yang terkait
dengan sistem informasi yang diusulkan. Jika Anda mengusulkan penggantian sistem informasi lama
dengan yang baru dan jika sistem informasi baru tidak akan menghasilkan uang tunai tambahan untuk
bisnis, hanya pengeluaran tunai yang terkait dengan proyek. Jika demikian, sistem baru tidak dapat
dibenarkan atas dasar pendapatan baru yang dihasilkan dan harus diperiksa dengan cermat untuk
manfaat nyata lainnya jika ingin dikejar lebih lanjut.
Gambar 3.13 menunjukkan analisis arus kas untuk perusahaan kecil yang menyediakan layanan
pengiriman surat. wakil perusahaan kecil lainnya di kota. Proyeksi pendapatan adalah bahwa hanya $
5.000 yang akan dihasilkan meningkat pada kuartal pertama, tetapi setelah kuartal kedua, pendapatan
akan tumbuh pada tingkat yang stabil. Biaya akan besar di dua kuartal pertama dan kemudian level off.
Analisis arus kas digunakan untuk menentukan ketika sebuah perusahaan akan mulai menghasilkan
keuntungan (dalam hal ini, itu adalah pada kuartal ketiga, dengan arus kas $ 7.590) dan kapan akan
"keluar dari merah," yaitu, ketika pendapatan telah dibuat untuk awal investasi (pada kuartal pertama
tahun kedua, ketika akumulasi arus kas berubah dari a jumlah negatif ke positif $ 10.720).
Sistem yang diusulkan seharusnya meningkatkan pendapatan bersama dengan pengeluaran uang
tunai. Lalu ukurannya dari arus kas harus dianalisis bersama dengan pola arus kas yang terkait dengan
mengejar sistem baru. Anda harus bertanya kapan pengeluaran uang tunai dan pendapatan akan
terjadi, tidak hanya untuk pembelian awal tetapi juga selama umur sistem informasi.
ANALISA NILAI SAAT INI. Analisis nilai sekarang membantu analis sistem untuk mempresentasikan
pengambil keputusan bisnis nilai waktu investasi dalam sistem informasi juga arus kas (seperti yang
dibahas pada bagian sebelumnya). Nilai sekarang adalah cara untuk menilai semua pengeluaran
ekonomi dan pendapatan dari sistem informasi selama kehidupan ekonominya, dan untuk
membandingkan biaya hari ini dengan biaya masa depan dan manfaat hari ini dengan manfaat masa
depan.
Dalam Gambar 3.14, biaya sistem total $ 272.000 selama enam tahun dan total manfaat $
280.700. Sana- karena itu, kita dapat menyimpulkan bahwa manfaat lebih besar daripada biayanya.
Manfaat hanya mulai melampaui biaya Namun, setelah tahun keempat, dan dolar pada tahun keenam
tidak akan setara dengan dolar pada tahun tahun pertama.
Misalnya, investasi dolar pada 7 persen hari ini akan bernilai $ 1,07 pada akhir tahun dan akan
berlipat ganda dalam waktu sekitar 10 tahun. Nilai saat ini, oleh karena itu, adalah biaya atau manfaat
diukur dalam dolar hari ini dan tergantung pada biaya uang. Biaya uang adalah peluang biaya tunity,
atau tingkat yang bisa diperoleh jika uang yang diinvestasikan dalam sistem yang diusulkan itu
diinvestasikan dalam proyek lain (relatif aman).
Nilai sekarang $ 1,00 pada tingkat diskonto i dihitung dengan menentukan faktornya
di mana n adalah jumlah periode. Kemudian faktor tersebut dikalikan dengan

jumlah dolar, menghasilkan nilai sekarang seperti yang ditunjukkan pada
Gambar 3.15. Dalam contoh ini, biaya uang — tingkat diskonto — adalah
diasumsikan 0,12 (12 persen) untuk seluruh cakrawala perencanaan. Pengganda dihitung untuk masing-
masing periode: n 1, n 2, ..., n 6. Nilai sekarang dari biaya dan
manfaat kemudian dihitung dengan menggunakan dalam pengganda ini. Ketika langkah itu dilakukan,
total manfaat (diukur dalam dolar hari ini) adalah$ 179.484, dan dengan demikian kurang dari biaya
(juga diukur dalam dolar hari ini). Kesimpulannya adalah ditarik adalah bahwa sistem yang diusulkan
tidak bermanfaat jika nilai sekarang dipertimbangkan
Meskipun contoh ini, yang menggunakan faktor nilai sekarang, berguna dalam menjelaskan
konsep, semua spreadsheet elektronik memiliki fungsi nilai sekarang bawaan. Analis dapat langsung
berkomunikasi pute present value menggunakan fitur ini.
PEDOMAN UNTUK ANALISIS. Penggunaan metode yang dibahas dalam subbab sebelumnya tergantung
pada metode yang digunakan dan diterima dalam organisasi itu sendiri. Untuk pedoman umum, namun,
aman untuk mengatakan yang berikut:
1. Gunakan analisis titik impas jika proyek perlu dibenarkan dalam hal biaya, bukan manfaat, atau jika
manfaat tidak meningkat secara substansial dengan sistem yang diusulkan.
2. Gunakan pengembalian ketika manfaat nyata yang diperbaiki membentuk argumen yang meyakinkan
untuk sistem yang diajukan.
3. Gunakan analisis arus kas ketika proyek itu mahal relatif terhadap ukuran perusahaan atau ketika
bisnis akan terpengaruh secara signifikan oleh saluran besar (bahkan jika sementara) pada dana.
4. Gunakan analisis nilai sekarang ketika periode pengembaliannya panjang atau ketika biaya pinjaman
uang tinggi.
Metode apa pun yang dipilih, penting untuk diingat bahwa analisis biaya-manfaat harus didekati secara
sistematis, dengan cara yang dapat dijelaskan dan dibenarkan untuk manajer, yang akan akhirnya
memutuskan apakah akan melakukan sumber daya ke proyek sistem. Selanjutnya, kita beralih ke
pentingnya membandingkan banyak alternatif sistem.
PERENCANAAN DAN KONTROL AKTIVITAS
Analisis dan desain sistem melibatkan berbagai jenis kegiatan yang secara bersamaan membentuk: a
proyek. Analis sistem harus mengelola proyek dengan hati-hati jika proyek ingin berhasil.Y Manajemen
proyek melibatkan tugas umum perencanaan dan pengendalian.
Perencanaan mencakup semua kegiatan yang diperlukan untuk memilih tim analisis sistem,
menugaskan anggota dari tim untuk proyek yang sesuai, perkirakan waktu yang dibutuhkan untuk
menyelesaikan setiap tugas, dan jadwalkan proyek sehingga tugas diselesaikan tepat waktu. Kontrol
berarti menggunakan feed- kembali untuk memantau proyek, termasuk membandingkan rencana proyek
dengan evolusi yang sebenarnya. Selain itu, kontrol berarti mengambil tindakan yang sesuai untuk
mempercepat atau menjadwal ulang kegiatan untuk diselesaikan tepat waktu sambil memotivasi
anggota tim untuk menyelesaikan pekerjaan dengan benar.
Diperkirakan Diperlukan Waktu

Keputusan pertama analis sistem adalah menentukan jumlah detail yang
digunakan untuk mendefinisikan kegiatan. Tingkat detail terendah adalah
SDLC itu sendiri, sedangkan ekstrem tertinggi adalah untuk memasukkan
setiap langkah rinci. Jawaban optimal untuk perencanaan dan penjadwalan
terletak di antara keduanya.
Pendekatan terstruktur berguna di sini. Dalam Gambar 3.16 analis sistem memulai proyek telah
memecah proses menjadi tiga fase utama: analisis, desain, dan implementasi. Lalu
fase analisis selanjutnya dipecah menjadi pengumpulan data, aliran data dan analisis keputusan, dan
persiapan proposal. Desain dipecah menjadi desain entri data, desain input dan output, dan organisasi
data. Tahap implementasi dibagi menjadi implementasi dan evaluasi.
Dalam langkah-langkah selanjutnya analis sistem perlu

mempertimbangkan masing-masing tugas ini dan memecahkannya
lebih jauh sehingga perencanaan dan penjadwalan dapat terjadi.
Gambar 3.17 menunjukkan bagaimana analisis tersebut
Fase sis dijelaskan lebih terinci. Misalnya, pengumpulan data dipecah menjadi lima kegiatan, dari
melakukan wawancara hingga mengamati reaksi terhadap prototipe. Proyek khusus ini membutuhkan
analisis aliran data tetapi bukan analisis keputusan, sehingga analis sistem telah menulis dalam “analisis
aliran data ”sebagai langkah tunggal di fase tengah. Akhirnya, persiapan proposal rusak ke dalam tiga
langkah: melakukan analisis biaya-manfaat, menyiapkan proposal, dan menyajikan proposal.
Analis sistem, tentu saja, memiliki opsi untuk memecah langkah lebih jauh. Misalnya, analis
dapat menentukan masing-masing orang yang akan diwawancarai. Jumlah detail yang diperlukan
tergantung pada proyek, tetapi semua langkah penting harus muncul dalam rencana.
Kadang-kadang bagian paling sulit dari perencanaan proyek adalah langkah penting untuk
memperkirakan waktu yang dibutuhkan untuk menyelesaikan setiap tugas atau kegiatan. Ketika ditanyai
tentang alasan keterlambatan pada sebuah proyek tertentu, anggota tim proyek mengutip perkiraan
penjadwalan yang buruk yang menghambat keberhasilan proyek sejak awal. Tidak ada pengganti untuk
pengalaman dalam memperkirakan persyaratan waktu, dan analis sistem yang memiliki kesempatan
magang beruntung dalam kasus ini.
Perencana telah berusaha untuk mengurangi ketidakpastian yang melekat dalam menentukan
perkiraan waktu oleh memproyeksikan perkiraan yang paling mungkin, pesimis, dan optimis dan
kemudian menggunakan rata-rata tertimbang rumus untuk menentukan waktu yang diharapkan suatu
kegiatan akan dilakukan. Pendekatan ini menawarkan sedikit lebih dalamjalan kepercayaan, namun.
Mungkin strategi terbaik untuk dipatuhi analis sistem pendekatan terstruktur dalam mengidentifikasi
kegiatan dan menggambarkan kegiatan ini secara cukup rinci.Dengan cara ini, analis sistem setidaknya
akan dapat membatasi kejutan yang tidak menyenangkan.
Menggunakan Gantt Charts untuk Penjadwalan Proyek
Bagan Gantt adalah cara mudah untuk menjadwalkan tugas. Ini adalah bagan di mana bilah mewakili
setiap tugas atau aktivitas. Panjang setiap bilah mewakili panjang relatif tugas.
Gambar 3.18 adalah contoh dari grafik Gantt dua dimensi di mana waktu ditunjukkan pada
dimensi horizontal dan deskripsi kegiatan membentuk dimensi vertikal. Dalam mantan ini cukup bagan
Gantt menunjukkan tahap analisis atau pengumpulan informasi proyek. Perhatikan pada grafik Gantt
yang melakukan wawancara akan memakan waktu tiga minggu, mengelola kuesioner akan memakan
waktu empat minggu, dan seterusnya. Kegiatan-kegiatan ini tumpang tindih sebagian waktu. Dalam
bagan khusus simbol menandakan bahwa itu adalah minggu 9. Bar dengan naungan warna mewakili
proyek atau bagian dari proyek yang telah selesai, memberi tahu kami bahwa analis sistem berada di
belakang dalam memperkenalkan proyek totypes tetapi di depan dalam menganalisis aliran data.
Tindakan harus segera diambil untuk memperkenalkan prototype sehingga kegiatan lain atau bahkan
proyek itu sendiri tidak akan tertunda akibatnya.
Keuntungan utama dari grafik Gantt adalah kesederhanaannya. Analis sistem tidak hanya akan
menemukan bahwa teknik ini mudah digunakan tetapi juga cocok untuk komunikasi yang bermanfaat
dengan pengguna akhir. Keuntungan lain menggunakan grafik Gantt adalah bilah mewakili aktivitas atau
tugas ditarik ke skala; yaitu, ukuran bilah menunjukkan panjang relatif waktu yang diperlukan selesaikan
setiap tugas.
Menggunakan diagram PERT
PERT adalah singkatan untuk Program Evaluasi dan Teknik Review. Program (sinonim untuk suatu
proyek) diwakili oleh jaringan node dan panah yang kemudian dievaluasi untuk menentukan kegiatan
kritis, perbaiki jadwal jika perlu, dan tinjau kemajuan setelah proyek selesai dilakukan. PERT
dikembangkan pada akhir 1950-an untuk digunakan dalam sub-nuklir nuklir Angkatan Laut AS proyek
kelautan. Itu dilaporkan menghemat waktu pengembangan Angkatan Laut AS selama dua tahun.
PERT berguna ketika aktivitas dapat dilakukan secara paralel dan bukan secara berurutan.
Sistem analis dapat mengambil manfaat dari PERT dengan menerapkannya pada proyek sistem pada
skala yang lebih kecil, terutama ketika beberapa anggota tim dapat mengerjakan kegiatan tertentu pada
saat yang sama Saya sedang mengerjakan tugas lain.
Gambar 3.19 membandingkan grafik Gantt sederhana

dengan diagram PERT. Kegiatan dinyatakan sebagai bar di bagan
Gantt diwakili oleh panah pada diagram PERT. Panjang panah tidak
memiliki hubungan langsung dengan durasi aktivitas. Lingkaran
pada diagram PERT disebut peristiwa dan dapat diidentifikasi
dengan angka, surat, atau bentuk penunjukan sewenang-wenang lainnya. Itu node bundar hadir untuk
(1) mengenali bahwa suatu kegiatan selesai dan (2) menunjukkan kegiatan harus diselesaikan sebelum
kegiatan baru dapat dilakukan (diutamakan).
Pada kenyataannya, aktivitas C mungkin tidak dimulai sampai aktivitas A selesai. Diutamakan
bukan indi sama sekali tercantum dalam bagan Gantt, sehingga tidak mungkin untuk mengatakan apakah
aktivitas C dijadwalkan untuk mulai pada hari ke 4 sengaja atau kebetulan.
Sebuah proyek memiliki awal, tengah, dan akhir; awalnya

adalah acara 10 dan akhirnya adalah acara 50. Untuk menemukan
panjang proyek, setiap jalur dari awal hingga akhir diidentifikasi, dan
panjangnya dari setiap jalur dihitung. Dalam contoh ini jalur 10–20–40–
50 memiliki panjang 15 hari, sedangkan jalur 10–30–40–50 memiliki panjang 11 hari. Meskipun satu
orang mungkin bekerja di jalur 10–20–40–50 dan lainnya di jalur 10–30–40–50, proyek ini bukan
perlombaan. Proyek membutuhkan itu kedua set aktivitas (atau jalur) diselesaikan; akibatnya, proyek ini
membutuhkan waktu 15 hari untuk menyelesaikannya.
Jalur terpanjang disebut sebagai jalur kritis. Meskipun jalur kritis ditentukan oleh menghitung
jalur terpanjang, ini didefinisikan sebagai jalur yang akan menyebabkan seluruh proyek jatuh karena
belakang jika bahkan keterlambatan satu hari ditemui di atasnya. Perhatikan bahwa jika Anda tertunda
satu hari di jalur 10–20–40–50, seluruh proyek akan memakan waktu lebih lama, tetapi jika Anda
tertunda satu hari di jalan 10–30–40–50, seluruh proyek tidak akan menderita. Kelonggaran untuk
tertinggal agak di noncriti- jalur kal disebut waktu kendur.
Kadang-kadang, diagram PERT membutuhkan aktivitas pseudo, yang disebut sebagai aktivitas
dummy, untuk melayani logika atau memperjelas diagram. Gambar 3.20 menunjukkan dua diagram
PERT dengan boneka. Proyek 1 dan proyek 2 sangat berbeda, dan cara menggambar boneka membuat
perbedaan
bersih. Dalam proyek 1 kegiatan C hanya dapat dimulai jika A dan B selesai, karena semua panah ing ke
dalam simpul harus diselesaikan sebelum meninggalkan simpul. Namun dalam proyek 2, aktivitas C
membutuhkan hanya aktivitas B yang selesai dan karena itu dapat berlangsung sementara aktivitas A
masih berlangsung.
Proyek 1 membutuhkan 14 hari untuk menyelesaikannya, sedangkan proyek 2 hanya
membutuhkan 9 hari. Dummy dalam proyek- ect 1
diperlukan, tentu saja, karena itu menunjukkan hubungan
diutamakan yang penting. Boneka itu di proyek 2, di sisi lain,
tidak diperlukan, dan aktivitas A bisa ditarik dari 10 ke 40 dan
acara 20 dapat dihilangkan sepenuhnya.
Oleh karena itu, ada banyak alasan untuk menggunakan diagram PERT di atas grafik Gantt. PERT
diagram memungkinkan:
1. Identifikasi urutan urutan yang mudah.
2. Identifikasi jalur kritis dan aktivitas kritis dengan mudah.
3. Mudah penentuan waktu kendur.
CONTOH PERT. Misalkan seorang analis sistem sedang mencoba mengatur jadwal yang realistis
untuk data fase pengumpulan dan proposal analisis sistem dan siklus hidup desain. Analis sistem
melihat situasi dan daftar kegiatan yang perlu diselesaikan di sepanjang jalan. Daftar ini, yang muncul
pada Gambar 3.21, juga menunjukkan bahwa beberapa kegiatan harus mendahului kegiatan lainnya. Itu
perkiraan waktu ditentukan seperti yang dibahas dalam bagian sebelumnya dari bab ini.
MENGGAMBARKAN DIAGRAM PERT. Dalam menyusun diagram PERT, analis pertama-tama

memperhatikannya kegiatan yang tidak memerlukan kegiatan sebelumnya, dalam hal ini A (melakukan
wawancara) dan C (baca laporan perusahaan). Dalam contoh pada Gambar 3.22, analis memilih untuk
memberi nomor pada node 10, 20, 30, dan seterusnya, dan dia menggambar dua panah dari simpul awal
10. Panah-panah ini mewakili
kegiatan A dan C dan diberi label seperti itu. Kode bernomor 20 dan 30 ditarik pada akhir panah masing-
masing. Langkah selanjutnya adalah mencari aktivitas apa pun yang
hanya membutuhkan A sebagai pendahulu; tugas B (mengelola kuesioner)
adalah satu-satunya, sehingga dapat diwakili oleh panah yang ditarik dari
simpul 20 ke simpul 30.
Karena kegiatan D (menganalisis aliran data) dan E (memperkenalkan prototipe) memerlukan

kedua kegiatan tersebut B dan C harus diselesaikan sebelum dimulai, panah berlabel D dan E diambil dari
simpul 30, peristiwa yang mengakui selesainya B dan C. Proses ini dilanjutkan sampai en- Diagram ban
PERT selesai. Perhatikan bahwa seluruh proyek berakhir pada suatu peristiwa yang disebut simpul 80.
MENGIDENTIFIKASI JALAN KRITIS. Setelah diagram PERT dibuat, dimungkinkan untuk mengidentifikasi
jalur kritis dengan menghitung jumlah waktu aktivitas pada setiap jalur dan memilih yang terpanjang
jalan. Dalam contoh ini, ada empat jalan: 10–20–30–50–60–70–80, 10–20–30–40–60–70–80, 10–30–
50–60–70–80, dan 10–30–40–60–70–80. Jalan terpanjang adalah 10–20–30–50–60–70–80, yang
membutuhkan 22 hari. Sangat penting bahwa analis sistem dengan hati-hati memonitor aktivitas di
Internet jalur kritis agar seluruh proyek tepat waktu atau bahkan mempersingkat panjang proyek jika
diperlukan.
MENGELOLA PROYEK
Proses analisis dan desain bisa menjadi sulit, terutama ketika sistem sedang dirancang. veloped itu besar.
Untuk menjaga agar kegiatan pengembangan dapat dikelola dengan sebaik mungkin, kami biasanya
gunakan beberapa teknik manajemen proyek untuk membantu kita menjadi terorganisir.
Salah satu aspek penting dari manajemen proyek adalah bagaimana mengatur jadwal seseorang
untuk menyelesaikannya sistem tepat waktu, tetapi bukan satu-satunya hal yang dibutuhkan. Orang
yang bertanggung jawab, disebut manajer proyek Ager, sering merupakan analis sistem utama. Manajer
proyek perlu memahami cara menentukan apa yang dibutuhkan dan bagaimana memulai suatu proyek;
bagaimana mengembangkan definisi masalah; bagaimana cara ujian- ketidaklayakan penyelesaian
proyek sistem; cara mengurangi risiko; cara mengidentifikasi dan mengelola kegiatan; dan bagaimana
merekrut, mengelola, dan memotivasi anggota tim lainnya
Mengatasi Kompleksitas Sistem
Memperkirakan model, seperti Costar (www.softstarsystems.com) atau Construx (www.construx.com),

bekerja sebagai berikut: Pertama, analis sistem memasukkan perkiraan ukuran sistem. Ini bisa
dimasukkan dalam sejumlah cara berbeda, termasuk baris kode sumber sistem saat ini. Maka mungkin
akan membantu untuk menyesuaikan tingkat kesulitan berdasarkan seberapa akrabnya analis tersebut
jenis proyek ini.
Juga dipertimbangkan adalah variabel lain, seperti pengalaman atau kemampuan tim, jenis
platform atau sistem operasi, tingkat kegunaan perangkat lunak yang sudah jadi (misalnya, apa
diperlukan bahasa), dan faktor-faktor lain yang dapat menaikkan biaya. Setelah data dimasukkan, sitasi
dibuat, dan proyeksi kasar tanggal penyelesaian diproduksi. Sebagai proyek mendapat berlangsung,
estimasi yang lebih spesifik mungkin dilakukan.
Cara lain untuk memperkirakan jumlah pekerjaan yang perlu dilakukan dan seberapa besar staf
kebutuhan untuk menyelesaikan suatu proyek disebut analisis titik fungsi. Metode ini mengambil lima
komponen utama. ponents dari sistem komputer— (1) input eksternal, (2) output eksternal, (3)
permintaan eksternal, (4) in- file logis ternal, dan (5) file antarmuka eksternal — dan kemudian beri
peringkat dalam hal kompleksitas.
Analisis titik fungsi dapat memperkirakan waktu yang dibutuhkan untuk mengembangkan suatu
sistem di berbagai perusahaan. bahasa puter dan membandingkannya satu sama lain. Untuk informasi
lebih lanjut tentang titik fungsi analisis, kunjungi situs Web International Function Point Users Group di
www.ifpug.org.
MENGELOLA ANALISIS DAN AKTIVITAS DESAIN
Seiring dengan mengatur waktu dan sumber daya, analis sistem juga harus mengelola orang. Mengelola-
ment dicapai terutama dengan berkomunikasi secara akurat dengan anggota tim yang telah dipilih
karena kompetensi dan kompatibilitasnya. Sasaran untuk produktivitas proyek harus ditetapkan, dan
anggota tim analisis sistem harus termotivasi untuk mencapainya.
Merakit Tim
Membentuk tim itu diinginkan. Jika seorang manajer proyek memiliki kesempatan untuk membuat tim
impian orang yang terampil untuk mengembangkan sistem, siapa yang harus dia pilih? Secara umum,
manajemen proyek Agers perlu mencari orang lain yang memiliki nilai-nilai kerja tim yang dibimbing oleh
keinginan untuk memberikan sistem berkualitas tinggi tepat waktu dan sesuai anggaran. Karakteristik
anggota tim yang diinginkan lainnya di mencakup etika kerja, kejujuran, kompetensi yang baik; kesiapan
untuk mengambil kepemimpinan berdasarkan pengalaman tise; motivasi, antusiasme terhadap proyek,
dan kepercayaan dari rekan satu tim.
Manajer proyek perlu tahu tentang prinsip-prinsip bisnis, tetapi setidaknya tidak ada salahnya
satu orang lagi di tim yang mengerti bagaimana sebuah bisnis beroperasi. Mungkin orang ini seharusnya
menjadi spesialis di bidang yang sama dengan sistem yang sedang dikembangkan. Saat mengembangkan
situs e-niaga, tim dapat meminta bantuan seseorang dalam pemasaran; mereka yang mengembangkan
sistem inventaris dapat bertanya a orang yang berpengalaman dalam produksi dan operasi untuk
memberikan keahlian.
Sebuah tim idealnya harus memiliki dua analis sistem di dalamnya. Mereka dapat saling
membantu, memeriksa masing-masing pekerjaan orang lain, dan alihkan beban kerjanya sesuai dengan
itu. Tentunya ada kebutuhan untuk memiliki orang dengan keterampilan pemrograman di papan tulis.
Pengodean itu penting, tetapi orang yang tahu cara melakukan walk- sistem, tinjauan, pengujian, dan
dokumentasi juga penting. Beberapa orang baik dalam melihat gambaran besar, sementara yang lain
berkinerja baik ketika tugas dipecah menjadi yang lebih kecil untuk mereka. Setiap tim harus memiliki
kedua tipe individu.
Di luar dasar-dasar, manajer proyek harus mencari orang-orang dengan pengalaman dan
pengalaman thusiasm. Pengalaman sangat penting ketika mencoba memperkirakan waktu yang
diperlukan menyelesaikan proyek. Pengalaman dalam pemrograman bisa berarti kode dikembangkan
lima kali lebih cepat dibandingkan jika dikembangkan oleh tim yang tidak berpengalaman. Pakar
kegunaan juga merupakan tambahan yang bermanfaat tim.
Tim harus termotivasi. Salah satu cara untuk menjaga tim tetap berorientasi positif di seluruh
dunia seluruh proses adalah memilih orang-orang baik sejak awal. Carilah antusiasme, imajinasi, dan
sebuah kemampuan berkomunikasi dengan berbagai jenis orang. Atribut dasar ini memiliki potensi
untuk sukses. Hal ini juga membantu untuk merekrut penulis unggul dan pembicara fasih yang dapat
mempresentasikan proposal- juga dan bekerja secara langsung dengan pelanggan.
Kepercayaan adalah bagian penting dari sebuah tim. Semua anggota proyek perlu bertindak
secara bertanggung jawab dan setuju untuk melakukan yang terbaik dan menyelesaikan bagian mereka
dari proyek. Orang mungkin memiliki pekerjaan yang berbeda gaya, tetapi mereka semua harus setuju
untuk bekerja sama menuju tujuan bersama.
Strategi Komunikasi untuk Mengelola Tim
Tim memiliki kepribadian mereka sendiri, hasil dari menggabungkan setiap anggota tim dengan satu
sama lain dengan cara yang menciptakan jaringan interaksi yang sama sekali baru. Cara untuk mengatur
berpikir tentang tim adalah memvisualisasikan mereka sebagai selalu mencari keseimbangan antara
menyelesaikan bekerja di tangan dan menjaga hubungan di antara anggota tim.
Bahkan, tim akan sering memiliki dua pemimpin, bukan hanya satu. Biasanya satu orang akan
muncul siapa memimpin anggota untuk menyelesaikan tugas, dan orang lain akan muncul yang peduli
dengan hubungan sosial di antara anggota kelompok. Keduanya diperlukan untuk tim. Orang-orang ini
telah diberi label oleh peneliti lain sebagai, masing-masing, pemimpin tugas dan pemimpin sosial-
emosional. Setiap tim tunduk pada ketegangan yang merupakan hasil mencari keseimbangan antara
pencapaian ing tugas dan menjaga hubungan di antara anggota tim.
Agar tim dapat melanjutkan efektivitasnya, ketegangan harus terus diselesaikan. Minimiz- ing
atau mengabaikan ketegangan akan menyebabkan ketidakefektifan dan disintegrasi tim. Banyak dari
pelepasan ketegangan yang diperlukan dapat diperoleh melalui penggunaan umpan balik yang terampil
oleh semuaanggota tim bers. Namun, semua anggota perlu setuju bahwa cara mereka berinteraksi
(yaitu, proses) adalah penting cukup untuk mendapat waktu. Sasaran produktivitas untuk proses
dibahas di bagian selanjutnya.
Mengamankan kesepakatan tentang interaksi anggota yang tepat melibatkan menciptakan

eksplisit dan mencari norma-norma tim (harapan kolektif, nilai-nilai, dan cara berperilaku) yang
membimbing anggota dalam hubungan mereka. Norma tim menjadi miliknya dan tidak perlu ditransfer
dari satu tim ke tim lain. Norma-norma ini berubah seiring waktu dan lebih baik dianggap sebagai proses
interaksi timdaripada produk.
Norma dapat bersifat fungsional atau disfungsional. Hanya karena perilaku tertentu adalah
norma untuk sebuah tim tidak berarti itu membantu tim untuk mencapai tujuannya. Misalnya, sebuah
harapan bahwa anggota tim junior harus melakukan semua penjadwalan proyek mungkin menjadi
norma tim. Dengan mengikuti pada norma ini, tim memberikan tekanan ekstrem pada anggota baru dan
tidak mengambil kemajuan penuh Tingkat pengalaman tim. Ini adalah norma yang, jika dilanjutkan,
dapat membuat anggota tim buang sumber daya berharga.
Anggota tim perlu membuat norma eksplisit dan secara berkala menilai apakah norma
berfungsi. nasional atau disfungsional dalam membantu tim mencapai tujuannya. Harapan utama untuk
Anda Tim harus bahwa perubahan adalah norma. Tanyakan pada diri sendiri apakah norma tim
membantu atau menghambat kemajuan tim.
Menetapkan Tujuan Produktivitas Proyek
Ketika Anda telah bekerja dengan anggota tim Anda pada berbagai jenis proyek, Anda atau tim Anda
pemimpin akan memperoleh ketajaman untuk memproyeksikan apa yang dapat dicapai tim dalam
jumlah waktu tertentu. Menggunakan petunjuk yang dibahas di bagian sebelumnya dalam bab ini
tentang metode untuk memperkirakan waktu pengembalian berhenti dan menggabungkan mereka
dengan pengalaman akan memungkinkan tim untuk menetapkan produktivitas yang bermanfaat.
Analis sistem terbiasa memikirkan tujuan produktivitas bagi karyawan yang menunjukkan hasil
nyata, seperti jumlah blue jeans yang dijahit per jam, jumlah entri diketik dalam per menit, atau jumlah
item yang dipindai per detik. Sebagai produktivitas manufaktur meningkat, bagaimanapun, menjadi jelas
bahwa produktivitas manajerial harus mengimbangi. Dengan ini ingatlah bahwa sasaran produktivitas
untuk tim analisis sistem ditetapkan.
Tujuan perlu dirumuskan dan disetujui oleh tim, dan mereka harus didasarkan pada tim keahlian
anggota, kinerja lama, dan sifat dari proyek tertentu. Sasaran akan bervariasi agak untuk setiap proyek
yang dikerjakan, karena kadang-kadang seluruh sistem akan diinstal, sedangkan proyek lain mungkin
melibatkan modifikasi terbatas pada bagian dari sistem yang ada.
Memotivasi Anggota Tim Proyek
Meskipun motivasi adalah topik yang sangat kompleks, itu adalah hal yang baik untuk dipertimbangkan,
meskipun secara singkat, pada saat ini. Untuk menyederhanakan, ingatlah bahwa orang bergabung
dengan organisasi untu menyediakan beberapa Kebutuhan seperti makanan, pakaian, dan tempat
tinggal. Semua manusia, bagaimanapun, juga memiliki kebutuhan tingkat yang lebih tinggi, yang
meliputi afiliasi, kontrol, kemandirian, dan kreativitas. Orang termotivasi untuk memenuhi memenuhi
kebutuhan pada beberapa tingkatan.
Anggota tim dapat termotivasi, setidaknya sebagian, melalui partisipasi dalam penetapan
tujuan, seperti dijelaskan pada bagian sebelumnya. Tindakan menetapkan tujuan yang menantang
tetapi dapat dicapai dan kemudian secara berkala mengukur kinerja terhadap tujuan tampaknya berhasil
dalam memotivasi orang. Tujuan bertindak hampir sebagai magnet dalam menarik orang ke prestasi.
Bagian dari alasan penetapan tujuan memotivasi orang adalah bahwa anggota tim tahu sebelum
melakukan ulasan kinerja persis apa yang diharapkan dari mereka. Keberhasilan penetapan tujuan untuk
memotivasi bisa juga dianggap berasal, memberi setiap anggota tim otonomi dalam mencapai tujuan.
Al- meskipun tujuan sudah ditentukan sebelumnya, cara untuk mencapainya mungkin tidak. Dalam hal
ini anggota tim Saya bebas menggunakan keahlian dan pengalaman mereka sendiri untuk memenuhi
tujuan mereka.
Menetapkan tujuan juga dapat memotivasi anggota tim dengan menjelaskan bagi mereka dan
orang lain apa yang harus dilakukan untuk mendapatkan hasil. Anggota tim juga termotivasi oleh tujuan
karena tujuan menentukan level pencapaian yang diharapkan dari mereka. Penggunaan tujuan ini
menyederhanakan suasana kerja, tetapi itu juga menggemparkannya dengan kemungkinan bahwa apa
yang diharapkan memang bisa dilakukan
Mengelola Proyek E-niaga
Banyak pendekatan dan teknik yang dibahas sebelumnya dapat ditransfer ke proyek e-niaga pengelolaan.
Anda harus diingatkan, bahwa meskipun ada banyak kesamaan, ada juga banyak perbedaan. Satu
perbedaan adalah bahwa data yang digunakan oleh sistem e-commerce tersebar terpusat di seluruh
organisasi. Oleh karena itu, Anda tidak hanya mengelola data dalam perangkat mandiri bagian atau
bahkan satu unit soliter. Oleh karena itu, banyak politik organisasi dapat ikut berperan, karena unit
sering merasa protektif terhadap data yang mereka hasilkan dan tidak mengerti kebutuhan untuk itu
membaginya di seluruh organisasi.
Perbedaan mencolok lainnya adalah bahwa tim proyek e-niaga biasanya membutuhkan lebih
banyak staf dengan keterampilan, termasuk pengembang, konsultan, pakar basis data, dan integrator
sistem, dari seluruh organisasi. Kelompok proyek stabil yang didefinisikan dengan rapi, yang ada dalam
kelompok atau sistem IS kohesif tim pengembangan mereka akan menjadi pengecualian daripada aturan.
Selain itu, karena sangat membantu mungkin diperlukan pada awalnya, manajer proyek e-niaga perlu
membangun kemitraan secara eksternal dan jauh di depan implementasi, mungkin berbagi bakat di
seluruh proyek untuk membiayai biaya implementasi e-commerce dan untuk mengumpulkan jumlah
orang yang diperlukan dengan mantan yang diperlukan berhubungan Potensi politik organisasi untuk
mendorong ganjalan di antara anggota tim sangat nyata.
Salah satu cara untuk mencegah politik menyabot proyek adalah untuk manajer proyek e-niaga
untuk menekankan integrasi e-commerce dengan sistem internal organisasi dan karenanya lakukan
menekankan aspek organisasi yang tertanam dalam proyek e-commerce. Sebagai satu ekonomi kata
manajer proyek kepada kami, “Merancang ujung depan [apa yang dilihat konsumen] adalah bagian yang
mudah dari semua ini.Tantangan sebenarnya datang dari mengintegrasikan e-commerce secara strategis
ke semua organisasi sistem . "
Perbedaan keempat antara manajemen proyek tradisional dan manajemen proyek e-niaga
Karena itu karena sistem akan terhubung dengan dunia luar melalui Internet, keamanannya yang paling
penting. Mengembangkan dan mengimplementasikan rencana keamanan sebelum sistem baru ini di
tempat adalah proyek itu sendiri dan harus dikelola seperti itu.
Membuat Piagam Proyek
Bagian dari proses perencanaan adalah untuk menyepakati apa yang akan dilakukan dan pada jam
berapa. Analis siapa konsultan eksternal, serta mereka yang menjadi anggota organisasi, perlu
menentukan apa yang mereka pada akhirnya akan memberikan dan kapan mereka akan
mengirimkannya. Bab ini telah menguraikan cara-cara untuk tentukan tanggal pengiriman untuk sistem
yang lengkap dan juga bagaimana mengidentifikasi tujuan organisasi dan menilai kelayakan sistem yang
diusulkan.
Piagam proyek adalah narasi tertulis yang menjelaskan pertanyaan-pertanyaan berikut:

1. Apa yang diharapkan pengguna dari proyek (apa tujuannya)? Apa yang akan dilakukan sistem
untuk memenuhi kebutuhan (mencapai tujuan)?
2. Apa ruang lingkup (atau apa batas-batas) proyek? (Apa yang dipertimbangkan pengguna
berada di luar jangkauan proyek?)
3. Metode analisis apa yang akan digunakan analis untuk berinteraksi dengan pengguna dalam
mengumpulkan data, mengembangkan, dan menguji sistem?
4. Siapa peserta kunci? Berapa lama waktu yang diinginkan dan dapat dilakukan oleh pengguna
berpartisipasi?
5. Apa hasil proyek? (Apa yang baru atau yang diperbarui perangkat lunak, perangkat keras,
prosedur, dan dokumentasi yang diharapkan pengguna tersedia untuk interaksi ketika proyek sedang
berlangsung Selesai?)
6. Siapa yang akan mengevaluasi sistem dan bagaimana mereka akan mengevaluasinya? Apa
saja langkah dalam proses penilaian? Bagaimana hasilnya akan dikomunikasikan dan kepada siapa?
7. Berapa perkiraan waktu proyek? Seberapa sering analis melaporkan tonggak proyek?
8. Siapa yang akan melatih pengguna?
9. Siapa yang akan memelihara sistem?
Piagam proyek menjelaskan dalam dokumen tertulis hasil yang diharapkan dari proyek sistem.
dll (hasil) dan kerangka waktu untuk pengiriman. Ini pada dasarnya menjadi kontrak antara kepala analis
(atau manajer proyek) dan tim analisis mereka dengan permintaan pengguna organisasi- ing sistem baru.
Menghindari Kegagalan Proyek
Diskusi awal yang Anda lakukan dengan manajemen dan orang lain yang meminta proyek, bersama
dengan studi kelayakan yang Anda lakukan, biasanya merupakan pertahanan terbaik yang mungkin
dilakukan terhadap proyek yang diambil memiliki probabilitas kegagalan yang tinggi. Pelatihan dan
pengalaman Anda akan meningkatkan kemampuan Anda untuk menilai kelayakan proyek dan motivasi
yang mendorong orang lain untuk meminta proyek. Jika Anda bagian dari tim analisis sistem in-house,
Anda harus tetap mengikuti perkembangan iklim politik organisasi serta dengan situasi keuangan dan
persaingan.
Namun, penting untuk dicatat bahwa proyek sistem dapat dan memang memiliki masalah serius.
Mereka yang dikembangkan menggunakan metode gesit tidak kebal terhadap masalah seperti itu.
Untuk ilusi- trate apa yang bisa salah dalam suatu proyek, seorang analis sistem mungkin ingin
menggambar diagram tulang ikan (juga disebut diagram sebab-akibat atau diagram Ishikawa). Saat Anda
memeriksa Gambar 3.23, Anda akan melihat bahwa itu disebut diagram
tulang ikan karena menyerupai kerangka ikan.
Nilai diagram tulang ikan adalah untuk secara sistematis membuat daftar semua masalah yang
mungkin terjadi. bajingan. Dalam hal pendekatan gesit, akan sangat berguna untuk mengatur diagram
tulang ikan dengan mendaftar semua variabel kontrol sumber daya di atas dan semua kegiatan di bawah.
Beberapa masalah seperti itu karena jadwal tergelincir mungkin jelas, tetapi yang lain seperti cakupan
creep (keinginan untuk menambahkan fitur setelah Jika analis mendengar cerita baru) atau
mengembangkan fitur dengan nilai kecil tidak sejelas ini.
Anda juga dapat belajar dari kebijaksanaan yang diperoleh oleh orang-orang yang terlibat dalam
kegagalan proyek sebelumnya. Ketika diminta untuk merenungkan mengapa proyek gagal, programer
profesional mengutip pengaturan tanggal mustahil atau tidak realistis untuk diselesaikan oleh
manajemen, kepercayaan pada mitos yang sederhana menambahkan lebih banyak orang ke proyek akan
mempercepatnya (meskipun tanggal target asli pada proyek proyek tidak realistis), dan manajemen
berperilaku tidak masuk akal dengan melarang tim untuk mencari keahlian profesional dari luar
kelompok untuk membantu memecahkan masalah tertentu.
Ingatlah bahwa Anda tidak sendirian dalam keputusan untuk memulai suatu proyek. Meskipun
Anda tahu rekomendasi tim, manajemen akan memiliki pendapat akhir tentang apakah proyek yang
diusulkan layak untuk studi lebih lanjut (yaitu, investasi sumber daya lebih lanjut). Proses keputusan
Anda Tim harus terbuka dan berdiri untuk pengawasan dari orang-orang di luar itu. Anggota tim harus
menganggap bahwa reputasi dan kedudukan mereka dalam organisasi tidak dapat dipisahkan dari
proyek mereka menerima.
PROPOSAL SISTEM
Menyusun Proposal Sistem
Sementara piagam proyek melayani tujuan mengidentifikasi objek, menentukan ruang lingkup, dan
menandatangani tanggung jawab, analis masih perlu menyiapkan proposal sistem yang mencakup
banyak perincian tentang kebutuhan, opsi, dan rekomendasi sistem. Bagian ini mencakup tenda dan
gaya yang membentuk proposal sistem.
APA YANG HARUS TERMASUK DALAM PROPOSAL SISTEM. Sepuluh bagian utama terdiri dari sistem
tertulis usul. Setiap bagian memiliki fungsi tertentu, dan proposal akhirnya harus diatur dalam pesanan
berikut:
1. Surat pengantar.
2. Halaman judul proyek.
3. Daftar isi.
4. Ringkasan eksekutif (termasuk rekomendasi).
5. Garis besar studi sistem dengan dokumentasi yang sesuai.
6. Hasil terperinci dari studi sistem.

7. Alternatif sistem (tiga atau empat solusi yang mungkin).
8. rekomendasi analis sistem.
9. Ringkasan proposal.
10. Lampiran (berbagai macam dokumentasi, ringkasan fase, korespondensi, dan sebagainya).
Surat pengantar kepada manajer dan satuan tugas TI harus menyertai proposal sistem.
Seharusnya daftar orang-orang yang melakukan penelitian dan merangkum tujuan penelitian. Jaga agar
surat pengantar singkat dan ramah.
Sertakan pada halaman judul nama proyek, nama-nama anggota tim analisis sistem, dan tanggal
proposal diajukan. Judul proposal harus secara akurat mengungkapkan konten proposal, tetapi juga
dapat menunjukkan beberapa imajinasi. Daftar isi dapat bermanfaat bagi pembaca proposal panjang.
Jika panjang proposal kurang dari 10 halaman, hilangkan daftar isi.
Ringkasan eksekutif, dalam 250 hingga 375 kata, memberikan siapa, apa, kapan, di mana,
mengapa, dan bagaimana proposal, seperti paragraf pertama dalam sebuah berita. Ini juga harus
mencakup rekomendasi analis sistem dan tindakan manajemen yang diinginkan, karena beberapa orang
dia hanya akan punya waktu untuk membaca ringkasan. Itu harus ditulis terakhir, setelah sisa proposal
selesai.
Garis besar studi sistem memberikan informasi tentang semua metode yang digunakan dalam
studi ini dan siapa atau apa yang dipelajari. Setiap kuesioner, wawancara, pengambilan sampel data
arsip, observasi vation, atau prototyping yang digunakan dalam studi sistem harus dibahas dalam bagian
ini.
Bagian hasil terperinci ini menjelaskan apa yang telah ditemukan oleh analis sistem tentang
kebutuhan manusia dan sistem melalui semua metode yang dijelaskan dalam bagian sebelumnya.
Kesimpulan tentangmasalah yang dialami pekerja saat berinteraksi dengan teknologi dan sistem yang
muncul ke depan melalui penelitian ini harus dicatat di sini. Bagian ini harus mengangkat masalah atau
saran peluang yang melahirkan alternatif yang disajikan di bagian selanjutnya.
Di bagian alternatif sistem dari proposal, analis menyajikan dua atau tiga solusi alternatif yang
secara langsung mengatasi masalah yang disebutkan di atas. Alternatif yang Anda sajikan harus
menyertakan yang merekomendasikan menjaga sistem tetap sama. Setiap alternatif harus dieksplorasi
secara terpisah. Jelaskan biaya dan manfaat dari setiap situasi. Karena biasanya ada trade-off yang
terlibat dalam solusi apa pun, pastikan untuk memasukkan kelebihan dan kekurangan masing-masing.
Setiap alternatif harus dengan jelas menunjukkan apa yang harus dilakukan pengguna dan
manajer untuk mengimplementasikannya. Kata-katanya harus sejelas mungkin, seperti, "Beli komputer
notebook untuk semua manajer menengah," "Beli perangkat lunak yang dikemas untuk mendukung
pengguna dalam mengelola inventaris," atau "Ubah sistem yang ada melalui pendanaan upaya
pemrograman in-house."
Setelah tim analisis sistem mempertimbangkan alternatifnya, ia akan memiliki pendapat

profesional yang pasti tentang solusi mana yang paling bisa diterapkan. Bagian rekomendasi analis
sistem mengungkapkan solusi yang disarankan. Sertakan alasan yang mendukung rekomendasi tim
sehingga mudah untuk memahami mengapa itu dibuat. Rekomendasi harus mengalir secara logis dari
analisis sebelumnya dari solusi alternatif, dan harus jelas menghubungkan temuan interaksi manusia-
komputer dengan pilihan yang ditawarkan.
Ringkasan proposal adalah pernyataan singkat yang mencerminkan isi dari ringkasan eksekutif.
itu memberikan tujuan penelitian dan solusi yang direkomendasikan. Analis harus sekali lagi
menekankan pentingnya dan kelayakan proyek bersama dengan nilai rekomendasi untuk mencapai
tujuan pengguna dan meningkatkan bisnis. Akhiri proposal dengan nada positif.
Apendiks adalah bagian terakhir dari proposal sistem, dan dapat mencakup informasi apa pun
yang menurut analis sistem mungkin menarik bagi individu tertentu, tetapi itu tidak penting untuk
memahami studi sistem dan apa yang diusulkan.
Setelah proposal sistem ditulis, pilih dengan cermat siapa yang akan menerima laporan. Secara
pribadi serahkan laporan kepada orang yang telah Anda pilih. Visibilitas Anda penting untuk penerimaan
dan keberhasilan sistem.
Menggunakan Angka untuk Komunikasi yang Efektif
Penekanan sejauh ini di bagian ini adalah pada mempertimbangkan audiens Anda ketika menulis
proposal sistem. Tabel dan grafik serta kata-kata penting dalam menangkap dan berkomunikasi
Mengutamakan dasar-dasar sistem yang diusulkan. Desain yang baik tidak boleh dianggap remeh.
Mengintegrasikan angka ke dalam proposal Anda membantu menunjukkan bahwa Anda

responsif terhadap perbedaan. Cara orang menyerap informasi. Angka-angka dalam laporan melengkapi
informasi tertulis dan harus selalu ditafsirkan dengan kata-kata; mereka seharusnya tidak pernah berdiri
sendiri.
PENGGUNAAN TABEL YANG EFEKTIF. Meskipun tabel secara teknis bukan alat bantu visual,
mereka menyediakan a berbeda cara pengelompokan dan penyajian data
yang dianalisis yang ingin dikomunikasikan oleh analis pembaca proposal.
Tabel menggunakan kolom dan baris berlabel untuk menyajikan data statistik atau alfabet secara
terorganisir cara. Setiap tabel harus diberi nomor sesuai dengan urutan kemunculannya dalam proposal
dan harus berjudul. Gambar 3.24 menunjukkan tata letak dan pelabelan yang sesuai untuk suatu tabel.
Beberapa pedoman untuk tabel adalah sebagai berikut:
1. Mengintegrasikan tabel ke dalam tubuh proposal. Jangan menyerahkannya ke lampiran.
2. Coba paskan seluruh tabel secara vertikal pada satu halaman jika memungkinkan.
3. Nomor dan beri judul tabel di bagian atas halaman. Buatlah judulnya deskriptif dan bermakna.
4. Beri label setiap baris dan kolom. Gunakan lebih dari satu baris untuk judul jika perlu.
5.Gunakan meja kotak jika ruang memungkinkan. Kolom yang diatur secara vertikal akan meningkatkan
keterbacaan.
6. Gunakan catatan kaki jika perlu untuk menjelaskan informasi terperinci yang terdapat dalam tabel.
Beberapa metode untuk membandingkan biaya dan manfaat disajikan pada bagian sebelumnya. Hasil
perbandingan yang diajukan tersebut harus muncul dalam proposal sistem. Jika analisis titik impas
dilakukan,sebuah tabel yang menggambarkan hasil analisis harus dimasukkan. Pengembalian dapat
ditampilkan dalam tabel yang berfungsi sebagai dukungan tambahan untuk grafik. Tabel pendek yang
membandingkan sistem atau opsi computer mungkin juga dimasukkan dalam proposal sistem.
PENGGUNAAN GRAF YANG EFEKTIF. Ada banyak jenis grafik: grafik garis, kolom grafik, diagram batang,
dan diagram lingkaran untuk beberapa nama. Grafik garis, grafik kolom, dan diagram batang bandingkan
variabel, sedangkan diagram lingkaran dan diagram luas menggambarkan komposisi 100 persen sebuah
entitas.
Pedoman untuk memasukkan grafik yang efektif dalam proposal (lihat Gambar 3.25) adalah
sebagai berikut:
1. Pilih gaya grafik yang mengkomunikasikan makna yang Anda maksudkan dengan baik.
2. Integrasikan grafik ke dalam tubuh proposal.
3. Berikan grafik angka angka berurutan dan judul yang bermakna.

4. Beri label setiap sumbu dan setiap garis, kolom, batang, atau potongan pai pada grafik.
5. Sertakan kunci untuk menunjukkan garis-garis berwarna yang berbeda, bilah berarsir, atau
area yang saling silang.
Banyak detail yang masuk ke proposal sistem diperoleh dari wawancara, penyediaan ing
kuesioner, pengambilan sampel, menemukan data keras lainnya, dan dengan observasi. Topik-topik ini
adalah dibahas dalam dua bab berikutnya.
RINGKASAN
Lima dasar manajemen proyek utama yang harus ditangani oleh analis sistem adalah (1) inisiasi proyek
— mendefinisikan masalah, (2) menentukan kelayakan proyek, (3) perencanaan dan pengendalian
kegiatan, (4) penjadwalan proyek, dan (5) sistem pengelolaan anggota tim analisis. Ketika dihadapkan
dengan pertanyaan tentang bagaimana bisnis dapat memenuhi tujuan mereka dan memecahkan
masalah sistem, analis menciptakan definisi masalah. Definisi masalah adalah pernyataan formal
masalah, termasuk (1) masalah situasi saat ini, (2) masalah
tujuan untuk setiap masalah, (3) persyaratan yang harus dimasukkan dalam semua sistem yang
diusulkan, dan (4) kendala yang membatasi pengembangan sistem.
Memilih proyek adalah keputusan yang sulit, karena lebih banyak proyek akan diminta daripada
yang sebenarnya dapat dilakukan. Lima kriteria penting untuk pemilihan proyek adalah (1) bahwa proyek
yang diminta didukung oleh manajemen, (2) bahwa waktunya tepat untuk komitmen sumber daya, (3)
bahwa itu memindahkan bisnis ke arah pencapaian tujuannya, (4) agar praktis, dan (5) cukup penting
untuk dipertimbangkan daripada proyek lain yang mungkin.
Jika proyek yang diminta memenuhi kriteria ini, studi kelayakan operasional, teknis, dan ekonomi
dapat dilakukan. Melalui studi kelayakan, analis sistem mengumpulkan data yang memungkinkan
manajemen memutuskan apakah akan melanjutkan dengan studi sistem lengkap. Dengan
menginventarisir peralatan yang sudah tersedia dan dipesan, analis sistem akan dapat menentukan
dengan lebih baik apakah perangkat keras komputer baru, yang dimodifikasi, atau saat ini
direkomendasikan.
Perangkat keras komputer dapat diperoleh melalui pembelian, sewa, atau sewa. Vendor akan
menyediakan layanan dukungan seperti pemeliharaan preventif dan pelatihan pengguna yang biasanya
dinegosiasikan secara terpisah. Perangkat lunak dapat dibuat sebagai produk khusus, dibeli sebagai
paket perangkat lunak komersial (COTS), atau outsourcing ke penyedia layanan aplikasi (ASP).
Mempersiapkan proposal sistem berarti mengidentifikasi semua biaya dan manfaat dari
sejumlah alternatif.Analis sistem memiliki sejumlah metode yang tersedia untuk memperkirakan biaya,
manfaat, dan volume masa depantransaksi, dan variabel ekonomi yang memengaruhi biaya dan
manfaat. Biaya dan manfaat dapat berwujud (kuantitatif) atau tidak berwujud (nonquantifiable dan
tahan terhadap perbandingan langsung). Seorang analis sistem memiliki banyak metode untuk
menganalisis biaya dan manfaat, termasuk analisis titik impas, metode pengembalian, dan analisis arus
kas.
Perencanaan proyek mencakup estimasi waktu yang diperlukan untuk setiap aktivitas analis,
menjadwalkannya, dan mempercepatnya jika perlu untuk memastikan bahwa suatu proyek selesai tepat
waktu. Salah satu teknik yang tersedia untuk analis sistem untuk tugas penjadwalan adalah Gantt chart,
yang menampilkan aktivitas sebagai bar pada grafik.
Teknik lain, yang disebut Program Evaluasi dan Teknik Review (PERT), menampilkan kegiatan
sebagai panah pada jaringan. PERT membantu analis menentukan jalur kritis dan waktu kendur, yang
merupakan informasi yang diperlukan untuk pengendalian proyek yang efektif.
Direkomendasikan untuk membuat piagam proyek yang berisi harapan pengguna dan hasil
analis, karena tenggat waktu manajemen yang tidak realistis, menambah personel yang tidak dibutuhkan
ke proyek yang berusaha memenuhi tenggat waktu yang tidak realistis, dan tidak mengizinkan tim
pengembang untuk mencari bantuan ahli di luar kelompok langsung mereka, dikutip oleh programmer
sebagai alasan proyek gagal. Kegagalan proyek biasanya dapat dihindari dengan memeriksa motivasi
untuk proyek yang diminta, serta motif tim Anda untuk merekomendasikan atau menghindari proyek
tertentu.
Analis sistem memiliki tiga langkah utama yang harus diikuti untuk menyusun proposal sistem
yang efektif: mengatur konten proposal secara efektif, menulis proposal dalam gaya bisnis yang sesuai,
dan secara lisan mempresentasikan proposal sistem informatif. Agar efektif, proposal harus ditulis
dengan cara yang jelas dan dapat dimengerti, dan isinya harus dibagi menjadi 10 bagian fungsional.
Pertimbangan visual penting ketika menyusun proposal.

Bab 3 Manajamen Proyek-1

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Bab 3 Manajamen Proyek-1

Diunggah oleh

Hak Cipta:

Format Tersedia

BAB 3 .

Masalah dalam Organisasi

- Apa tujuan bisnis ini?

- Apakah bisnis itu untung atau nirlaba?

- Apakah perusahaan berencana untuk tumbuh atau berkembang?

- Bagaimana sikap (budaya) bisnis tentang teknologi?

- Berapa anggaran bisnis untuk TI?

- Apakah staf bisnis memiliki keahlian?

Poin utama dapat diidentifikasi dalam wawancara di sejumlah cara:

3. Pengguna dapat berbicara panjang lebar tentang suatu topik.

6. Masalahnya mungkin hal pertama yang disebutkan oleh pengguna.

Definisi masalah ditunjukkan pada Gambar 3.2. Perhatikan bobot di

Persyaratan pengguna untuk Cather- Catering in adalah untuk:

Paket tes sederhana untuk Katering Catherine adalah:

1. Dukungan dari manajemen.

Menentukan Apakah Itu Mungkin

Meskipun melelahkan, mempelajari kelayakan bermanfaat karena menyelamatkan bisnis dan

KELAYAKAN OPERASIONAL. Misalkan sesaat bahwa sumber daya

MEMUTUSKAN PERANGKAT KERAS DAN KEBUTUHAN PERANGKAT LUNAK

Inventarisasi Perangkat Keras Komputer

Anda perlu mengetahui hal berikut:

1. Jenis peralatan: nomor model, pabrikan.

2. Status pengoperasian peralatan: sesuai pesanan, beroperasi, dalam penyimpanan,

3. Perkiraan usia peralatan.

4. Kehidupan peralatan yang diproyeksikan.

5. Lokasi fisik peralatan.

6. Departemen atau orang yang dianggap bertanggung jawab atas peralatan.

7. Pengaturan keuangan untuk peralatan: dimiliki, disewakan, disewa.

Memperkirakan Beban Kerja

Mengevaluasi Perangkat Keras Komputer

Mengevaluasi perangkat keras komputer adalah tanggung jawab bersama manajemen,

3. Waktu idle CPU atau jaringan.

4. Ukuran memori yang disediakan.

Akuisisi Peralatan Komputer

Namun, leasing bukanlah cara yang ekonomis untuk

Evaluasi Perangkat Lunak

KAPAN SAAT LAYANAN PERANGKAT LUNAK OUTSOURCE KE PENYEDIA LAYANAN APLIKASI.

IDENTIFIKASI, PERAMALAN, DAN PERBANDINGAN BIAYA DAN MANFAAT

Mengidentifikasi Manfaat dan Biaya

Manfaat tak berwujud termasuk meningkatkan proses pengambilan keputusan, meningkatkan

Membandingkan Biaya dan Manfaat

di mana n adalah jumlah periode. Kemudian faktor tersebut dikalikan dengan

PERENCANAAN DAN KONTROL AKTIVITAS

Diperkirakan Diperlukan Waktu

Dalam langkah-langkah selanjutnya analis sistem perlu

Menggunakan Gantt Charts untuk Penjadwalan Proyek

Menggunakan diagram PERT

Gambar 3.19 membandingkan grafik Gantt sederhana

Sebuah proyek memiliki awal, tengah, dan akhir; awalnya

1. Identifikasi urutan urutan yang mudah.

2. Identifikasi jalur kritis dan aktivitas kritis dengan mudah.

3. Mudah penentuan waktu kendur.

MENGGAMBARKAN DIAGRAM PERT. Dalam menyusun diagram PERT, analis pertama-tama

Karena kegiatan D (menganalisis aliran data) dan E (memperkenalkan prototipe) memerlukan

Mengatasi Kompleksitas Sistem

Memperkirakan model, seperti Costar (www.softstarsystems.com) atau Construx (www.construx.com),

MENGELOLA ANALISIS DAN AKTIVITAS DESAIN

Strategi Komunikasi untuk Mengelola Tim

Mengamankan kesepakatan tentang interaksi anggota yang tepat melibatkan menciptakan

Menetapkan Tujuan Produktivitas Proyek

Memotivasi Anggota Tim Proyek

Mengelola Proyek E-niaga

Membuat Piagam Proyek