368 Bagian III • memperoleh sistem informasi
sistem di seluruh organisasi. Misalnya, di sebuah
perusahaan dengan banyak kantor cabang, mungkin layak
untuk dikonversi ke sistem baru hanya dalam satu kantor
cabang dan mendapatkan pengalaman memecahkan
konversi data dan masalah prosedural sebelum
menginstalsistem th perusahaan-lebar. Jika masalah besar
dihadapi, pelaksanaan perusahaan-lebar dapat tertunda
sampai mereka dipecahkan. Pendekatan percontohan
sangat berguna bila ada potensi risiko teknologi atau
organisasi tinggi yang terkait dengan proyek sysTems.
Untuk sistem yang besar dan kompleks, strategi
konversi bertahap mungkin merupakan pendekatan
terbaik. Misalnya, dengan pemrosesan pesanan besar dan
sistem kontrol inventaris, perusahaan mungkin pertama
kali mengonversi entri pesanan dan hanya memasukkan
pesanan pelanggan dan mencetaknya di formulir
perusahaan. Kemudian mungkin mengkonversi gudang
persediaan sistem kontrol ke komputer. Akhirnya,
mungkin link sistem entri pesanan ke sistem persediaan,
menghasilkan dokumen pengiriman, dan memperbarui
catatan persediaan secara otomatis. The downside ke
pendekatan ini adalah bahwa hal itu menghasilkan
periode implementasi yang panjang. Pengembangan
tambahan bekerja untuk antarmuka baru dan komponen
sistem lama juga biasanya diperlukan. Di sisi lain, strategi
pentahapan memungkinkan perusahaan untuk mulai
mencapai manfaat some dari sistem baru lebih cepat
daripada di bawah strategi lain. Sebuah strategi bertahap
mungkin berhubungan dengan tidak hanya pelaksanaan
sistem tetapi juga langkah sebelumnya dalam SDLC,
sehingga melanggar proyek besar ke dalam serangkaian
lebih kecil, ditambah proyek efisiensiTS. Kemudian dalam
bab ini kita akan menggambarkan proses formal yang
mengambil pendekatan inkremental ini disebut metode
Agile.
Dalam strategi migrasi (atau kalkun dingin),
organisasi sepenuhnya meninggalkan sistem lama ketika
mengimplementasikan yang baru. Dalam beberapa
industrhal ini dapat dilakukan selama akhir pekan liburan
dalam rangka untuk memungkinkan untuk hari ketiga
untuk kembali ke sistem lama dalam hal kegagalan besar.
Strategi yang migrasi memiliki risiko yang lebih besar,
tetapi menarik ketika sangat sulit untuk mengoperasikan
keduae lama dan sistem baru secara bersamaan.
Beberapa juga berpendapat bahwa total "rasa sakit adalah
sama" untuk implementasi sistem, Apakah
diimplementasikan sebagai migrasi atau tidak, dan bahwa
strategi ini bergerak organisasi ke lingkungan operasi baru
lebih cepat.
Kombinasis dari empat strategi ini juga
dimungkinkan. Sebagai contoh, ketika menerapkan modul
sistem melalui strategi konversi bertahap, satu masih
memiliki pilihan pendekatan paralel atau migrasi untuk
mengkonversi setiap fase sistem. Demikian pula, sebuah
strategi percontohan CoULD termasuk strategi paralel di
situs percontohan.
OPERASI langkah kedua tahap implementasi adalah untuk
mengoperasikan aplikasi baru dalam "mode produksi." Hal
ini umum untuk organisasi IS untuk mempertahankan tiga
versi aplikasi:
• versi pengembangan (dalam keadaan parsial dari
comple-tion sebagai kemampuan baru sedang
ditambahkan atau koreksi sedang dilakukan),
• Versi tes (sebuah rilis tentatif baru dari applica-tion
akan melalui proses pengujian yang dijelaskan
sebelumnya), dan
• Versi produksi (The version sebenarnya "Run").
Dalam langkah operasi, tanggung jawab IS untuk aplikasi
(atau rilis berikutnya dari aplikasi) diserahkan ke operasi
komputer dan personel dukungan teknis. Tim proyek
biasanya dibubarkan, meskipun satu atau lebih anggota
dapat ditugaskan ke tim dukungan.
Aplikasi baru biasanya tidak dipindahkan ke status
produksi kecuali dokumentasi yang memadai telah
diberikan kepada staf operasi komputer. Menerapkan
sistem yang besar dan kompleks tanpa dokumentasi
sangat berisiko. Dokumentasi datang dalam setidaknya
dua rasa: dokumentasi sistem untuk spesialis IS yang
mengoperasikan dan memelihara sistem komputer dan
dokumentasi pengguna bagi mereka yang menggunakan
sistem.
Keberhasilan operasi sistem aplikasi memerlukan
PEOPLE dan komputer untuk bekerja sama. Jika perangkat
keras atau perangkat lunak gagal atau orang terputus-
putus, operasi sistem mungkin tidak memuaskan. Dalam
sebuah sistem yang besar dan kompleks, ribuan hal bisa
salah, dan sebagian besar perusahaan mengoperasikan
banyak sistem tersebut secara bersamaan. Dibutuhkan
manajemen yang sangat baik dari operasi komputer untuk
memastikan bahwa semuanya bekerja dengan baik secara
konsisten dan mengandung dan memperbaiki kerusakan
ketika semuanya tidak beres.
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 369
PEMELIHARAAN proses membuat perubahan pada sistem
setelah itu telah dimasukkan ke dalam mode produksi
(yaitu, setelah tahap operasi siklus hidupnya) disebut
sebagai pemeliharaan. Alasan yang paling jelas untuk
pemeliharaan adalah untuk memperbaiki kesalahan
dalam perangkat lunak yang tidak ditemukan dan
dikoreksi sebelum implementasi awal. Biasanya sebuah
number bug dalam sistem melakukan menghindari proses
pengujian, dan untuk besar, sistem yang kompleks
mungkin memakan waktu berbulan-bulan, atau bahkan
bertahun-tahun, untuk menemukan mereka.
Pemeliharaan juga dapat diperlukan untuk
beradaptasi sistem untuk perubahan dalam lingkungan-
organisasi, lainnya systems, perangkat keras dan sistem
baru perangkat lunak, dan peraturan pemerintah.
Penyebab utama lain untuk pemeliharaan adalah
keinginan untuk meningkatkan sistem. Setelah beberapa
pengalaman dengan sistem baru, manajer biasanya
memiliki sejumlah ide tentang bagaimana untuk
memperbaikinya, mulai dari perubahan kecil untuk modul
yang sama sekali baru. Perubahan kecil biasanya
diperlakukan sebagai pemeliharaan, tetapi skala besar
tambahan
mungkin perlu
persetujuan
sebagai
permintaan
pembangunan
baru. Pengembangan baru
Pemeliharaan
100%
Waktu
Gambar 9,5 persen dari sumber daya pengembangan yang
dikhususkan untuk pemeliharaan
Karena baik lingkungan bisnis dan teknologi berubah
dengan cepat, perubahan berkala terhadap sistem besar
yang khas. Di masa lalu total biaya selama siklus hidup
sistem yang khas telah diperkirakan sekitar 80 persen
pada pemeliharaan dan hanya 20 persen pada
pengembangan asli dari aplikasi. Akibatnya, banyak
organisasi IS harus mengalokasikan sejumlah besar
spesialis IS mereka untuk mempertahankan sistem,
daripada mengembangkan yang baru. Pada awal 1990-an,
sumber daya pemeliharaan yang memakan sebanyak 75
persen dari total sumber daya pengembangan sistem di
banyak organisasi besar (lihat gambar 9,5). Organisasi IS
bertanggung jawab untuk membuat perubahan yang
diperlukan dalam sistem sepanjang hidupnya, serta untuk
menghilangkan bug yangdiidentifikasi kembali sebelum
meluncurkan sistem baru dalam mode produksi.
Untuk membuat perubahan dalam sebuah sistem,
programmer pemeliharaan harus terlebih dahulu
menentukan program apa yang harus diubah dan
kemudian apa bagian tertentu dari setiap program perlu
diubah. ProgramMer juga harus memahami logika dari
bagian kode yang sedang diubah. Dengan kata lain,
seseorang harus memahami sistem dalam beberapa detail
dalam rangka untuk mengubahnya.
Karena sistem dapat sangat kompleks, dokumentasi
sistem sangat penting dalam memberikan tingkat
pemahaman yang diperlukan. Ini memunculkan kesulitan
lain — dokumentasi harus diubah ketika sistem diubah
atau dokumentasi akan memberikan informasi misleading
tentang sistem daripada bantuan dalam memahaminya.
Kebanyakan pemrogram terutama tertarik dalam
pemrograman dan tidak dihargai untuk memperbarui
dokumentasi, sehingga di banyak organisasi IS
dokumentasi sistem lama akandatang usang dan termasuk
ketidakakuratan.
Selanjutnya, ketika perubahan yang dibuat dalam
sistem yang kompleks, efek riak mungkin terjadi
sedemikian rupa sehingga perubahan memiliki dampak
yang tak terduga pada beberapa bagian lain dari sistem.
Sebagai contoh, perubahan dalam program dapat
mempengaruhi program lain yang menggunakan output
dari program pertama. Perubahan ke baris kode dapat
mempengaruhi hasil baris kode lain di bagian yang sama
sekali berbeda dari program tersebut. Perubahan lain
harus dilakukan untuk memperbaiki masalah tersebut dan
bahwa ChanGE mungkin menyebabkan masalah yang tak
terduga di tempat lain.
Masalah utama lain dengan pemeliharaan adalah
bahwa kebanyakan IS profesional lebih memilih untuk
bekerja pada sistem baru menggunakan teknologi baru
daripada mempertahankan sistem lama. Pemeliharaan
oleh karena itu sering dianggap sebagai rendah-Status
370 Bagian III • memperoleh sistem informasi
bekerja, meskipun sangat penting untuk bisnis.
Pemeliharaan sering merupakan penugasan pertama dari
programmer yang baru dipekerjakan, dan sebagian besar
organisasi tidak memiliki mekanisme untuk memastikan
bahwa orang yang sangat baik pemeliharaan dihargai
dengan baik.
Dari perspektif bisnis manager, tantangan
pemeliharaan utama yang mendapatkan itu dilakukan
ketika dibutuhkan dan berurusan dengan masalah sistem
baru diperkenalkan sebagai bagian dari proses
pemeliharaan. Proporsi yang tinggi dari masalah
operasional disebabkan oleh kesalahan diperkenalkan
ketika Making perubahan pemeliharaan. Perubahan pada
sistem produksi harus dikelola dengan cermat. Perubahan
pemeliharaan biasanya dibuat untuk salinan sistem
produksi dan kemudian sepenuhnya diuji sebelum
diimplementasikan. Proses manajemen rilis yang efektif
untuk Changing dari versi lama ke sistem yang lebih baru
sangat penting untuk menghindari memperkenalkan
sejumlah besar masalah baru ketika mempertahankan
sistem operasi.
Jika jumlah spesialis IS yang memadai tidak tersedia
untuk proyek pemeliharaan sistem, manajer seringkali
harus mengalami penundaan yang lama sebelum
perubahan yang diperlukan dilakukan. Gambar 9,6 grafis
menampilkan kesenjangan melebar yang dapat terjadi
antara kebutuhan organisasi dan kinerja sistem dari waktu
ke waktu. Selain itu, sebagai sistem semakin tua dan
berulang kali ditambal, tdia probabilitas masalah kinerja
menjadi lebih besar dan Reengineering atau solusi
pengganti mungkin diperlukan.
Kebutuhan
organisasi
Kinerja sistem
Waktu
FIGURE 9,6kesenjangan pelebaran antara kebutuhan organisasi dan
kinerja sistem
Tim proyek SDLC
Sebagian besar sistem aplikasi dikembangkan oleh tim
proyek sementara. Ketika proyek sistem selesai, tim
dibubarkan, tetapi inti kecil dari tim mungkin tetap
memberikan kontinuitas untuk tugas pemeliharaan.
Sebagian besar tim proyek termasuk perwakilan dari
organisasi is dan Departemen bisnis yang relevan. Jika
beberapa unit organisasi atau beberapa tingkat orang
dalam unit akan menggunakan sistem, tim proyek
mungkin termasuk perwakilan dari hanya beberapa unit
yang berbeda ini, including tingkat yang lebih tinggi
manajer dan pengguna akhir berpengalaman yang akan
bekerja dengan aplikasi baru pada setiap hari. Pemilihan
tim proyek karena itu penting untuk keberhasilan proyek
sistem tertentu.
Tim proyek juga dapat bervariasi dalam
keanggotaan selama siklus hidup sistem: beberapa
anggota mungkin ditugaskan penuh waktu untuk proyek
secara keseluruhan, sementara yang lain mungkin
bergabung dengan tim proyek hanya sementara sebagai
pengetahuan spesifik atau keterampilan yang diperlukan.
Selain manajer IS dalam peran kepemimpinan project,
personil is lainnya akan ditugaskan sesuai kebutuhan
untuk aplikasi tertentu, termasuk sistem analis, programer
aplikasi, administrasi data spesialis, telekomunikasi
spesialis, dan lain-lain. Hal ini juga tidak biasa bagi spesialis
IS dari luar organisasi untuk juga digunakan pada proyek
sistem. Para spesialis IS dipekerjakan dari perusahaan
kontrak mungkin membawa pengetahuan IS tertentu
untuk proyek atau mungkin diperlukan karena kurangnya
sumber daya internal yang tersedia untuk menetapkan
untuk tproyek dia. Personil ini bisa begitu baik
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 371

diintegrasikan ke dalam proyek bahwa mereka hampir
tidak dapat dibedakan dari internal perusahaan is personil.
Secara historis, manajer proyek untuk aplikasi
kustom selalu manajer is. Namun, saat ini, seorang
manajer bisnis dengan pengetahuan manajemen
teknologi informasi (TI) mungkin akan diminta untuk
menjadi manajer proyek, atau proyek mungkin memiliki
dua manajer proyek: sebuah bisnisaanager bertanggung
jawab atas semua kegiatan pengguna, terutama untuk
tahap pelaksanaan, dan manajer IS bertanggung jawab
atas
kegiatan
semua
personil
Siapa yang harus memimpin proyek IT
IS.
Jika proyek melibatkan teknologi baru dan mutakhir,
Beberapa
Maka harus dikelola oleh seseorang dari Departemen IS.
panduan Jika dampak proyek akan memaksa perubahan kritis dalam bisnis, maka
tentang harus dikelola oleh seseorang dari unit bisnis.
apakah Jika proyek sangat besar dan kompleks,
manajer Maka harus be dikelola oleh seorang spesialis dalam manajemen proyek.
proyek Jika proyek berbagi semua karakteristik di atas,
Kemudian manajemen senior harus mempertimbangkan beberapa pemimpin proyek.
tertentu
harus
[Radding, 1992, berdasarkan Applegate]
datang
dari
organisasi IS, unit bisnis, atau keduanya disediakan dalam
kotak "siapa yang harus memimpin proyek It?" Pers
praktisi menyarankan bahwa menugaskan baik TI dan
manajer bisnis untuk memimpin proyek TI adalah cara
untuk mengencangkan keselarasan keseluruhan antara
organisasi TI dan bisnis. Menurut laporan baru-baru ini,
Cisco Systems, Inc, adalah memberikan TI dan pemimpin
bisnis tanggung jawab bersama untuk setiap proyek TI
(Hoffman, 2003).
Apakah peran ini bersama atau tidak, manajer
proyek bertanggung jawab atas keberhasilan proyek —
untuk memberikan sistem yang berkualitas, tepat waktu,
dan sesuai anggaran. Mengelola sebuah proyek sistem
biasanya melibatkan koordinasi usaha dari banyak orang
dari unit organisasi yang berbeda, beberapa di antaranya
bekerja untuk proyek hanya pada bagian-waktu atau
temporAry dasar. Manajer Proyek harus merencanakan
proyek, menentukan tugas SDLC yang harus dilakukan dan
keterampilan yang diperlukan untuk setiap tugas, dan
memperkirakan berapa lama masing-masing akan
mengambil. Keterampilan sumber daya IS yang ditugaskan
untuk proyek dapat sama pentingnyadenganjumlah
sumber daya yang ditugaskan.
Dokumentasi sistem yang dihasilkan pada setiap
langkah dari metodologi SDLC menyediakan alat utama
untuk komunikasi di seluruh anggota tim dan untuk
menilai kualitas upaya pengembangan sepanjang masa
sistem. Sebagian besar organisasi mengharuskan sistem
yang sesuai dengan proses SDLC termasuk manajemen
bisnis di luar tim proyek untuk memberikan tanda-off
formal pada setiap tonggak proyek.
Peran analis sistem juga merupakan salah satu
yang penting. Ini adalah profesional dilatih untuk bekerja
dengan manajer bisnis dan pengguna akhir untuk
menentukan kelayakan dari sistem baru dan untuk
mengembangkan persyaratan sistem rinci untuk aplikasi
kustom. Selama fase konstruksi, mereka bekerja dengan
yang lain adalah spesialis dalam merancang sistem dan
membantu untuk memantau kepatuhan terhadap
persyaratan sistem. Seorang analis sistem yang baik
memiliki kemampuan memecahkan masalah,
pengetahuan tentang kemampuan IT, dan pemahaman
yang kuat tentang kegiatan bisnis yang terlibat dalam
APplikasi. Peran analis sistem perlu dimainkan dengan
baik agar beberapa pengguna perspektif untuk
diperhitungkan. Terkadang para analis sistem juga
menyediakan fungsi penting dalam menyediakan cek dan
saldo untuk spesialis Eager untuk bekerja dengan
teknologi baru namun belum terbukti dengan memastikan
bahwa risiko bisnis yang terkait dengan teknologi baru
keputusan proyek.
Peran kunci lainnya, termasuk peran bisnis utama
(misalnya, sponsor, juara), dibahas dalam chapter pada
manajemen proyek it (Lihat Bab 11).
372 Bagian III • memperoleh sistem informasi
Mengelola proyek SDLC
Semua proyek sistem biasanya diukur dengan tiga kriteria
keberhasilan utama: (1) tepat waktu pengiriman IS yang
(2) berkualitas tinggi dan memenuhi persyaratan bisnis
dan (3) adalah dengandalam anggaran proyek. Teknik
manajemen proyek tambahan untuk mencapai tujuan ini
akan dipertimbangkan dalam bab 11.
Sangat penting untuk keberhasilan proyek
pengembangan kustom menggunakan metodologi SDLC
adalah tiga karakteristik: ukuran proyek yang mudah
dikelola, definisi persyaratan yang akurat, dan sponsor
eksekutif.
DIKELOLA proyek ukuran pengalaman telah meyakinkangly
menunjukkan bahwa proyek TI kustom sangat besar
sangat sulit untuk memberikan dalam anggaran, yang
merupakan salah satu alasan jenis proyek ini dianggap
berisiko ketika mengembangkan kasus bisnis. Di sisi lain,
proyek yang mengambil lebih sedikit orang teknis yang
ytelinga atau kurang untuk menyelesaikan lebih mungkin
untuk memenuhi kriteria keberhasilan untuk proyek. Hal
ini menunjukkan bahwa sistem besar harus dipecah
menjadi modul yang relatif independen dan dibangun
sebagai urutan kecil, proyek yang dapat dikelola, bukan
sebagai satu proyek rakasa.
PERSYARATAN yang akurat definisi proses air terjun SDLC
didasarkan pada premis bahwa persyaratan untuk sistem
baru dapat dan harus didefinisikan secara rinci pada awal
proses. The downside adalah bahwa jika persyaratan tidak
kitaLL didefinisikan, atau secara signifikan berubah selama
proyek, mungkin ada biaya besar overruns dan sistem bisa
tidak memuaskan. Studi awal telah menunjukkan bahwa
sekitar setengah dari jumlah total persyaratan kesalahan
(atau kelalaian) biasanya terdeteksi di tdia persyaratan
langkah definisi. Lebih lanjut, kesalahan terdeteksi dalam
fase implementasi biaya sekitar 150 kali lebih banyak
untuk memperbaiki sebagai kesalahan terdeteksi dalam
fase definisi (Boehm, 1976). Oleh karena itu setiap upaya
harus dimasukkan ke dalam mendapatkan sebagai akurat
memerlukandokumen definisi ments mungkin. Hal ini
membutuhkan sistem analis terampil dalam
memunculkan persyaratan serta dalam proses dan teknik
representasi data. Hal ini juga membutuhkan akses ke
pengguna bisnis berpengetahuan tentang kedua operasi
bisnis saat ini dan sistem yang dibayangkan.
SPONSOR eksekutif meskipun semua proyek sistem besar
memerlukan sponsorship Bisnis, intensitas dan lamanya
waktu yang terlibat dengan proyek SDLC yang khas berarti
bahwa sponsor tingkat eksekutif sangat penting untuk
sukses. Kunci bdarmawisata manajer perlu memahami
potensi manfaat dari sistem yang diusulkan dan
didedikasikan untuk menyumbangkan sumber daya untuk
tim proyek sistem, serta penggunaan berkelanjutan
aplikasi kustom baru. Karena beberapa pengelola bisnis
danpengguna en-d juga akan ditugaskan ke tim proyek,
sponsor bisnis harus bersedia mendedikasikan sumber
daya ini untuk tim proyek, kadang secara penuh waktu
untuk kehidupan proyek.
Meskipun tidak setiap tim proyek memiliki
pengguna akhir sebagai anggota tehm formal, pengguna
akhir sering berpartisipasi dengan memberikan informasi
tentang proses kerja saat ini atau prosedur dan
mengevaluasi desain layar dari perspektif pengguna akhir.
Ini, juga, membutuhkan waktu jauh dari kegiatan bisnis
normal. Keterlibatan pengguna dalamproyek batang sy
sebenarnya telah dikaitkan dengan penerimaan pengguna
dan penggunaan sistem baru (hartwick dan barki, 1994).
Namun, manajer bisnis harus bersedia mendedikasikan
sumber daya bisnis ini di seluruh proyek yang diperlukan,
bukan hanya pada saat pelaksanaan.
Beath dan Orlikowski (1994) telah menunjukkan
bahwa metodologi pengembangan sistem dapat berbeda
dalam asumsi mereka tentang IS dan peran pengguna atas
kehidupan proyek. Sebagai contoh, dua metodologi yang
telah dipraktekkan lebih umum di luarAmerika U olisi (
metode etika dan metodologi sistem lunak) secara khusus
dirancang untuk memfasilitasi keterlibatan pengguna
lebih.
Implementasi sistem juga memerlukan pengelolaan
perubahan organisasi. Kecuali ada sponsor bisnis yang
kuat, tidak akan adat menjadi inisiatif yang kuat untuk
membuat perubahan pada bisnis sebagai bagian dari
upaya proyek sistem. (Lihat Bab 11 untuk beberapa
pedoman untuk mengelola perubahan bisnis.)
Keuntungan dan kerugian SDLC
Proses SDLC adalah pendekatan yang sangat terstruktur
Suite terbaikd untuk pengembangan aplikasi yang besar
dan kompleks untuk satu atau lebih unit bisnis. Ringkasan
keuntungan dan kerugian pendekatan SDLC disediakan
dalam gambar 9,7 dan dibahas dalam paragraf berikut.
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 373

Kerugian berfungsi sebagai cautioNS tentang perilaku mempertimbangkan kembali keputusan desain
terbaik dari SDLC dan menyarankan keadaan ketika SDLC sebelumnya.
mungkin bukan yang terbaik pendekatan pengembangan Kerugian utama yang melekat in metodologi.
sistem kustom. Dalam bagian berikutnya, kami akan Pertama, keberhasilan proyek tergantung pada spesifikasi
meninjau beberapa pendekatan alternatif yang mengatasi yang akurat dan lengkap dari persyaratan rinci pada awal
masalah ini tentang SDLC. proses pembangunan (definisi fase). Ada beberapa
Advantusia
• Proses yang sangat terstruktur dan sistematis
• Kontrol yang cermat pada proses, termasuk dampak pada sistem
terkait
• Definisi persyaratan menyeluruh
• Jelas tonggak dengan manajemen bisnis sign-off

Kerugian
• Tidak memperhitungkan baik untuk kebutuhan berkembang selama
proyek
• Proses yang memakan waktu (dan mahal)
• Komitmen atas-bawah diperlukan
• Perlawanan dalam praktek untuk umpan balik atau akan kembali ke
tahap sebelumnya
• Peran pengguna sistem mungkin sempit didefinisikan
• Tetap tonggaktanggal selesai d

Gambar 9,7 keuntungan dan kerugian pendekatan SDLC tradisional

Di tangan spesialis IS kompeten dan manajer bisnis
berpengetahuan, SDLC adalah proses yang sistematis
dengan langkah formal dengan jelas IS dan peran
pengguna, pemeriksaan formal, dan teknik untuk analisis,
Desain, pengujian, dan implementasi. Alat ini dan disiplin
ketat yang terkait dengan metodologi SDLC membantu
manajer proyek sistem menghasilkan sistem yang
direkayasa dengan baik tepat waktu dan sesuai anggaran.
Kedua, proses sistematik mencakup kontrol yang
menilai dampak sistem yang ada di bawah perkembangan
sistem yangada. Kontrol ini membahas konsep organisasi
sebagai seperangkat sistem, dengan antarmuka yang
dirancang dengan cermat antara subsistem.
Ketiga, persyaratan secara formal dan menyeluruh
dikembangkan. Semua pihak memahami dan Agree pada
persyaratan. Dengan demikian, sistem ini cenderung tidak
istimewa, melainkan akan menyeimbangkan kebutuhan
semua pengguna.
Akhirnya, proses ini transparan dengan tonggak
yang jelas di mana pihak yang berkepentingan sign-off
bahwa dana lebih lanjut harus mengalokasikand untuk
melanjutkan ke langkah berikutnya. Tonggak ini juga
memberikan peserta titik formal untuk mengidentifikasi
kebutuhan untuk mundur ke tahap atau langkah
sebelumnya, jika situasi menunjukkan perlunya
masalah serius dengan ketergantungan ini. Misalnya,
banyak aplikasi yang disesuaikan saat ini adalah solusi
unik. Karena proyek ini dimulai dengan pemahaman yang
tidak lengkap tentang apa yang akan dilakukan sistem
informasi unik ini, mungkin perlu mencoba beberapa
pendekatan sebelum menemukan yang optimal. Baru
technologies mungkin juga terlibat, dan sampai
kemampuan teknologi ini lebih baik dipahami, mungkin
sulit untuk mengembangkan seperangkat perusahaan
persyaratan atau untuk memperkirakan waktu untuk
melakukan beberapa langkah proyek. Dengan tekanan
untuk memenuhi apa yang sakit-Conceived tenggat waktu,
jalan pintas dapat diambil yang mempengaruhi kualitas
proyek dan sistem. Masalah lain dengan persyaratan up-
front rinci spesifikasi adalah bahwa lingkungan bisnis saat
ini berubah begitu cepat bahwa ada dapat perbedaan
yang signifikan dalam kebutuhan business antara waktu
persyaratan ditentukan dan waktu sistem yang terinstal.
Meskipun SDLC memungkinkan untuk backtracking
langkah sebelumnya jika perlu, loop umpan balik ini sering
diabaikan dalam praktek. Sebaliknya, output dari satu
langkah adalah fRozen; perubahan yang diminta dicatat
dan ditangani hanya selama pemeliharaan.
Perhatikan bahwa proses SDLC juga memerlukan
Total sistem analisis biaya-manfaat berdasarkan fase
definisi awal. Proses pembenaran dapat sulit untuk dicapai
374 Bagian III • memperoleh sistem informasi

dengan menggunakan pendekatan ttandak seperti laba PROTOTYPING METHODOLOGY

atas investasi (ROI) perhitungan ketika teknologi baru
Metodologi SDLC didasarkan pada premis bahwa
yang terlibat atau persyaratan tidak lengkap.
kebutuhan bisnis untuk sistem akan statis selama masa
Kedua, proses SDLC memakan waktu. Pada tahun proyek. Dengan demikian, persyaratan sistem harus
1980-an, proyek sistem yang khas memakan waktu sepenuhnya dan akhirnya ditentukan sebelum fase
beberapa tahun, dan laju perubahan bisnis menerima ini. konstruksi dimulai. Setelah irements diperlukan
Hari ini, dengan omset personil, ancaman dari pesaing telahdisepakati, mengubah mereka mengarah pada biaya
baru, dan kondisi berubah pada kecepatan internet, waktu proyek yang signifikan dan potensi penundaan jadwal.
pengiriman yang panjang tersebut tidak dapat diterima.
Pada paruh kedua 1980-an, pertumbuhan
Ketiga, karena proses SDLC yang panjang dan
ketersediaan bahasa nonprosedural generasi keempat
mahal,diperlukan sponsorship yang kuat sekre tive. Tanpa
dan sistem manajemen database relasionals mulai
sponsor bisnis yang kuat, manajer bisnis dan pengguna
menawarkan pendekatan alternatif. Alat ini
akan enggan untuk mendedikasikan waktu mereka untuk
memungkinkan untuk awalnya membangun sebuah
proyek sistem bukannya bekerja pada kegiatan lain yang
sistem (atau bagian dari sistem) lebih cepat dan kemudian
mereka biasanya diukur.
berulang kali merevisi setelah pengguna telah
Keempat, meskipun dalam theory yang SDLC mencobanya dan memberikan umpan balik mereka
memungkinkan untuk umpan balik dan backtracking, ada
kepada para pengembang. Dengan demikian,
perlawanan yang kuat dalam praktek untuk agakpertama awalnya mendefinisikan sistem di atas
melakukannya. Pada setiap tonggak, ada "pergi-tidak-
kertas dan kemudian membangunnya, sistem awal dapat
pergi" keputusan tentang apakah akan bergerak maju: direvisi berdasarkan pengalaman pengguna dan
mungkin ada beberapa kesediaan untuk mengulang
pemahaman yang Diperoleh dari versi sebelumnya.
beberapa aspek dari langkah sebelumnya, tetapi biasanya
Pendekatan ini sangat kuat karena, meskipun
ada perlawanan yang besar untuk kembali beberapa
kebanyakan orang menemukan it sangat sulit untuk
langkah, bahkan ketika situasi menuntut ini. Oleh karena
menentukan secara rinci persis apa yang mereka
itu, tidak jarang bahwa sebuah proyek dihentikan pada
butuhkan dari sistem baru, cukup mudah bagi mereka
tonggak sejarah karena proyek ini tidak berjalan dengan
untuk menunjukkan apa yang mereka tidak suka tentang
baik atau situasi bisnis telah berubah sejak proyek the
layar komputer bahwa mereka dapat mencoba dan
dimulai.
penggunaan.
Kelima, peran pengguna sistem, dan pada
Pendekatan umum ini paling sering dikenal sebagai
kenyataannya masing-masing peserta, biasanya sangat
Prototyping. Ini adalah jenis proses pengembangan
sempit didefinisikan. Hal ini dapat membatasi pengguna
evolusi . Konsep Prototyping juga dapat diterapkan untuk
teknologi cerdas, terutama dalam organisasi yang secara
proses di mana sistem nyata dikembangkan bagi
teratur memindahkan karyawan antara TI dan posisi bisnis
pengguna untuk mencoba serta untuk situasi di mana
umum sebagai bagian dari pengembangan karir mereka.
hanya "mainan" (nonoperational, biasanya dibuang tanpa
Akhirnya, SDLC cenderung memberlakukan tanggal
mengkonversi ke sistem operasional) prototipe adalah
yang ketat untuk setiap tonggak dan penyelesaian. Jika
Dikembangkan. Sebagai contoh, prototipe layar input dan
tanggal tersebut tidak terpenuhi, untuk alasan apa pun,
output yang sering dikembangkan bagi pengguna untuk
proyek dapat dianggap sebagai kegagalan. Meskipun baik
bekerja dengan sebagai bagian dari persyaratan definisi
untuk menempatkan batas t ime realistispada setiap
atau desain rinci langkah. Contoh lain dari Prototyping
proyek, waktu untuk menyelesaikan adalah satu dari tiga
termasuk "pertama-of-a-seri" prototipe di mana prototipe
proyek trade-off (bersama dengan proyek lingkup dan
yang benar-benar operasional digunakan sebagai pilot dan
sumber daya proyek).
"fitur yang dipilih" prototipe di mana hanya beberapa fitur
Selanjutnya kita melihat pendekatan alternatif untuk
penting yang termasuk dalam Prototype dan lebih fitur
pengembangan sistem yang membahas beberapa
ditambahkan dalam modul kemudian (Kendall dan
kelemahan ini.
Kendall, 1999).
Pada bagian berikutnya, pertama-tama kita
mendiskusikan Prototyping sebagai alternatif lengkap
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 375

untuk metodologi SDLC tradisional: langkah-langkahnya,
pertimbangan manajemen proyek, dan keuntungan dan
kerugiannya secara keseluruhan dibandingkan dengan
SDLC Metodologi. Pendekatan ini sangat menarik ketika
persyaratan sulit untuk didefinisikan ("kita akan tahu apa
yang kita inginkan ketika kita melihatnya"), ketika salah
satu atau beberapa pemangku kepentingan/pengguna
mana Probabilitas keberhasilan tidak jelas tetapi
penghargaan untuk sukses tampaknya sangat tinggi.
The Prototyping langkah
Gambar 9,8 menyajikan langkah untuk metodologi evolusi
untuk mengembangkan baru, sistem kerja. ProcESS

Langkah 1: identifikasi sistem dasar

Persyaratan

Langkah 2: kembangkan awal

Prototipe

Langkah 3: Peninggi prototipe

dancatatan perubahan yang
diinginkan

Langkah 5: evaluasi Langkah 4: merevisi dan

sistem operasional
sebagai meningkatkan
prototipe

Langkah 6: membuat Baru

modifikasi
diperlukanatau pengabaian Persyaratan

Langkah 7: menginstal,
dan memelihara
mengoperasikan,

Gambar 9,8 Prototyping siklus hidup

yang terlibat, ketika sistem Cal critidiperlukan dengan
cepat, ketika masalah komunikasi telah ada di masa lalu
antara pengguna akhir dan pengembang, atau ketika
sistem akan digunakan jarang (atau bahkan hanya sekali)-
sehingga efisiensi operasi bukan merupakan
pertimbangan utama. Perhatikan bahwa ini semua
karakteristik sistem yang berlaku untuk beberapa jenis
sistem dukungan manajerial.
Prototyping sebagai alternatif untuk metodologi
SDLC tidak praktis untuk besar, upaya sistem yang
kompleks. Namun, ketika Prototyping digunakan dalam
proses SDLC untuk membantu menentukan persyaratan
aplikasi kustom baru, dapat meningkatkan kemungkinan
bahwa proyek sistem sukses. Prototyping menyediakan
cara praktis bagi organisasi untuk bereksperimen dengan
sistem nyata, bukan hanya diagram abstrak, di
manapersyaratanNTS tidak sepenuhnya jelas dan di
dimulai dengan identifikasi persyaratan dasar dari versi
awal dari sistem (langkah 1). Para analis/Builder (s) dan
pengguna (s) bertemu dan setuju pada input, pengolahan
data, dan sistem output. Ini tidak lengkap requir rinci;
sebaliknya, ini adalah titik awal untuk sistem. Jika
beberapa pembangun dan pengguna terlibat, sesi desain
aplikasi bersama (JAD) dapat digunakan untuk
menentukan persyaratan (Lihat Deskripsi JAD di bagian
berjudul "pendekatan yang lebih baru" kemudian dalam
bab ini).
Pada langkah 2, pembangun sistem menghasilkan
sistem prototipe awal sesuai dengan persyaratan dasar
yang disepakati pada langkah 1. Pembangun sistem
memilih alat perangkat lunak, menemukan data yang
diperlukan dan membuat data ini dapat diakses oleh
sistem, dan membangun sistem menggunakan bahasa
tingkat yang lebih tinggi. Langkah ini harus mengambil dari
beberapa hari untuk beberapa minggu, tergantung pada
376 Bagian III • memperoleh sistem informasi
ukuran sistem dan kompleksitas. Catatan, langkah ini
bekerja terbaik saat data berkualitas tinggi yang sudah ada
di beberapa database saat ini dan akses kedata ing ada
dapat dengan cepat diperoleh.
Ketika prototipe awal selesai, itu diberikan kepada
pengguna dengan petunjuk yang mirip dengan berikut:
"berikut adalah prototipe awal. Saya tahu bahwa itu bukan
apa yang Anda butuhkan, tapi itu titik awal. Cobalah
sebuahd menuliskan segala sesuatu tentang hal itu bahwa
Anda tidak suka atau yang perlu ditambahkan ke sistem.
Ketika Anda mendapatkan daftar yang baik, kami akan
membuat perubahan yang Anda sarankan. "
Langkah 3 adalah tanggung jawab pengguna. Dia
bekerja dengan sistem ini, mencatat hal yang perlu
ditingkatkan, dan kemudian bertemu dengan
analis/pembangun untuk mendiskusikan perubahan. Pada
langkah 4, pembangun memodifikasi sistem untuk
menggabungkan perubahan yang diinginkan dan
persyaratan tambahan yang telah muncul dari pekerjaan
analisis lebih lanjut. Dalam rangka untuk menjaga
everyone terlibat secara aktif, kecepatan adalah penting.
Terkadang pembangun bisa duduk dengan pengguna dan
membuat perubahan dengan segera; untuk sistem yang
lebih besar, perubahan mungkin memerlukan waktu
beberapa minggu. Langkah 3 dan 4 diulang sampai
pengguna puas denganversi sistem THT. Ini adalah
langkah iteratif dalam proses Prototyping. Ketika
pengguna puas bahwa prototipe telah cukup
dikembangkan, langkah 5 dimulai.
Langkah 5 melibatkan evaluasi prototipe akhir
sebagai sistem operasi. Ini spemilihan dicatat,
bagaimanapun, bahwa tidak semua prototipe menjadi
sistem operasional. Sebaliknya, mungkin diputuskan
bahwa sistem prototipe harus hanya dibuang. Atau, bisa
diputuskan bahwa tidak ada biaya tambahan harus
dikhususkan untuk aplikasi karena sistem tidak dapat
dikembangkan yang memecahkan masalah asli. Artinya,
proses Prototyping membantu organisasi memutuskan
bahwa manfaat sistem tidak lebih besar daripada
pengembangan tambahan atau biaya operasional, atau
keduanya, atau bahwa biaya developing sistem secara
operasional efisien terlalu tinggi. Pada titik ini juga bisa
diputuskan bahwa sistem akan diimplementasikan tetapi
sistem perlu dibangun menggunakan alat yang berbeda
untuk mencapai efisiensi kinerja.
Jika prototipe to menjadi sistem operasional, pada
langkah 6 pembangun melengkapi tahap konstruksi
dengan membuat perubahan yang diperlukan untuk
meningkatkan efisiensi operasional dan untuk antarmuka
aplikasi baru dengan sistem operasional yang
menyediakan Data. Ini adalah Alsehingga langkah di mana
semua diperlukan kontrol, backup dan pemulihan
prosedur, dan dokumentasi yang diperlukan harus
diselesaikan. Jika prototipe hanya sedikit dimodifikasi,
langkah ini berbeda dari akhir fase konstruksi dari
metodologi SDLC in bahwa sebagian besar (atau semua)
dari sistem sudah diuji. Langkah 7 serupa dengan fase
implementasi SDLC: sistem baru diinstal dan dipindahkan
ke status operasional. Hal ini mungkin fase implementasi
jauh lebih mudah daripada di bawah proses Traelemen
SDLC karena setidaknya beberapa pengguna yang dituju
sudah terbiasa dengan sistem. Langkah 7 juga mencakup
pemeliharaan. Karena alat canggih yang mungkin
digunakan untuk membangunnya, perubahan mungkin
akan lebih mudah dibuat.
Tim Prototyping project
Mengelola proses pengembangan evolusi jelas
merupakan gabungan IS dan tanggung jawab manajemen
pengguna. Apakah peran manajer proyek dimainkan oleh
IS sendiri, personil bisnis saja, atau keduanya IS dan
personil Bisnis, kedua kelompok harus bersama-sama
menentukan kapan harus terus meminta revisi untuk
prototipe dan kapan harus mengakhiri Tryout-dan-revisi
iteratif langkah. Manajer Bisnis perlu menentukan apakah
solusi yang memuaskan telah dikembangkan, dan manajer
IS perlu menentukan apakah semua kemampuan
teknologi yang relevan telah dieksplorasi.
Karena hanya persyaratan dasar yang didefinisikan,
sistem analis dan prototipe Builder (yang mungkin satu
dan sama) perlu memiliki beberapa keahlian yang berbeda
dari yang diperlukan untuk SDLC patunganSS. teknik untuk
memunculkan persyaratan abstrak dan penekanan pada
dokumentasi terperinci di bawah proses SDLC digantikan
oleh ketergantungan yang berat pada keterampilan untuk
membangun sistem dengan cepat menggunakan alat
canggih. Prototip awal dinilai lebih dalam haltampilan dan
nuansa t pewaris dari perspektif pengguna dan kurang
dalam hal kualitas teknis dari perspektif kinerja sistem.
Interaksi antara spesialis IS dan pusat pengguna di sekitar
solusi pengembangan kreatif dan reaksi pribadi
terhadapmuka dan Keluaran sistem pengguna.
Sebuah metodologi Prototyping juga memerlukan
peran pengguna bisnis khusus. Karena ada keterlibatan
pengguna terus-menerus dengan berbagai versi sistem,
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 377
pengguna bisnis yang ditunjuk harus dapat dibebaskan
dari tanggung jawab lain untuk bekerja dengan aplikasi
dan untuk menyarankan perubahan selama kehidupan
proyek. Terkadang lebih dari satu orang memainkan peran
pengguna akhir yang kritis ini, yang akan memerlukan
struktur dan proses untuk mencapai kesepakatan ketika
perubahan yang disarankan dari pengguna yang berbeda
berada di conflict. Pengguna bisnis juga perlu bersabar
dan memahami bahwa setiap iterasi menghasilkan sistem
yang mungkin "tidak benar."
Mengelola Prototyping proyek
Mengelola proyek pengembangan baru dengan
metodologi yang didasarkan pada proses iteratif atau
evolusimemerlukan pemikiran yang berbeda daripada
mengelola proyek menggunakan metodologi SDLC
berdasarkan pendekatan pembangunan yang sangat
terstruktur. Apakah manajer proyek dan pembangun
sistem perlu mendekati proyek dengan cara yang berbeda:
tujuannya adalah untuk merespon quicktc untuk
permintaan pengguna dengan "baik-cukup" prototipe
beberapa kali daripada untuk menghasilkan sistem yang
sebenarnya rekayasa yang ketat pada awal proyek. Hal ini
mungkin memerlukan beberapa perubahan budaya dalam
organisasi IS. IS profesional yang telah membangun karir
mereka pada keterampilan dan sikap yang dibutuhkan
oleh pendekatan SDLC mungkin perlu untuk memperoleh
keterampilan baru untuk pendekatan Prototyping.
IS manajer juga menemukan proyek mengelola
Prototyping lebih bermasalah karena sulit untuk
merencanakan berapa lama waktu yang dibutuhkan,
berapa banyak iterasi akan diperlukan, atau tepat ketika
sistem pembangun akan bekerja pada sistem. Manajer
Proyek harus memiliki sumber daya IS yang memadai yang
tersedia untuk pembangunan sistem agar dapat merespon
dengan cepat permintaan pengguna atas perubahan
sistem dalam jadwal yang telah disepakati. Pengguna
yang akan mencoba setiap versi prototipe harus
berkomitmen untuk proses dan harus bersedia dan
mampu mencurahkan waktu dan usaha yang diperlukan
untuk menguji setiap versi prototipe secara tepat waktu.
IS manajer mungkin rightfully merasa bahwa mereka
memiliki lebih sedikit kontrol atas lingkup proyek. Salah
satu bahaya potensial dari Prototyping adalah bahwa
langkah iteratif akan terus dan terus dan bahwa biaya
proyek akan tetap terakumulasi. Hubungan kerja yang
baik antara personil IS dan pengguna yang bertanggung
jawab untuk proyek yang diperlukan untuk pindah ke
langkah evaluasi prototipe (langkah 5) pada waktu yang
optimal. Joint IS-user akuntabilitas akan muncul untuk
menjadi kunci keberhasilan untuk jenis proyek.
Tergantung pada alat perangkat lunak yang
digunakan untuk build prototipe, efisiensi operasional
prototipe yang dievaluasi di langkah 5 mungkin secara
signifikan lebih rendah daripada sistem yang
dikembangkan menggunakan metodologi SDLC
tradisional. Standar teknis yang ditetapkan oleh organisasi
juga mungkin tidak ketatdiikuti, dan dokumentasi
mungkin tidak memadai. Investasi substansial dalam alat
rekayasa perangkat lunak (CASE) yang dibantu komputer
(Lihat bagian akhir bab ini berjudul "pendekatan yang
lebih baru"), alat manajemen database, dan spesialis
training mungkin diperlukan sebelum organisasi dapat
berhasil mengimplementasikan prototipe akhir sebagai
sistem akhir.
Prototyping keuntungan dan kerugian
Keunggulan Metodologi pengembangan evolusi
mengatasi kerugian yang melekat padametodologi SD LC.
Pertama, hanya persyaratan sistem dasar yang
diperlukan di ujung depan proyek. Ini berarti bahwa
sistem dapat dibangun dengan menggunakan pendekatan
evolusi yang tidak mungkin untuk mengembangkan
melalui metodologi SDLC. Selanjutnya, prototyping dapat
digunakan untuk membangun sistem yang secara radikal
mengubah cara kerja selesai, seperti ketika proses kerja
sedang didesain ulang atau jenis yang sama sekali baru
dari alat dukungan manajerial telah dibayangkan tetapi
tidak pernah terlihat. Hal ini hampir mustahil untuk
menentukan persyaratan untukse jenis sistem pada awal
proses pengembangan sistem. Prototyping juga
memungkinkan perusahaan untuk mengeksplorasi
penggunaan teknologi yang lebih baru, karena harapan di
bawah metodologi evolusi adalah bahwa pembangun
akan mendapatkannya tepat selama beberapa iterasi,
bukan pertama kalinya.
Kedua, sistem kerja awal tersedia untuk pengujian
pengguna jauh lebih cepat. Dalam beberapa kasus,
manajer bisnis sebenarnya mungkin menggunakan
prototipe kerja untuk merespon dalam beberapa cara
untuk masalah saat ini atau setidaknya untuk
Qumenjijikkan belajar bahwa pendekatan sistem tertentu
tidak akan menjadi solusi terbaik. Meskipun proses
378 Bagian III • memperoleh sistem informasi

lengkap mungkin memakan waktu beberapa bulan, Ketiga, karena sifat yang lebih interaktif dari proses,
pengguna mungkin memiliki prototipe kerja dalam dengan Hands-on penggunaan model sistem kerja, kuat
beberapa minggu atau bulan yang memungkinkan mereka top-down commitmberdasarkan pada proses
untuk menanggapi masalah yang ada sekarang dan pembenaran yang dibuktikan dengan baik mungkin kurang
semakin penting; seringkali seorang manajer bisnis tidak diperlukan di luar-
bisa menunggu berbulan-bulan, biarkan sendiri tahun,
untuk sistem tertentu yang akan dibangun.
Fase definisi
Analisis kelayakan
Prototyping untuk
menentukanpersyaratanTS
Tahap konstruksi
Desain sistem
Sistem bangunan
Pengujian sistem
Tahap implementasi
Instalasi
Operasi
Pemeliharaan

Gambar 9,9 SDLC dengan Prototyping untuk menentukan

persyaratan
mengatur proyek. Sebaliknya, biaya dan manfaat dari
sistem dapat diturunkan setelah pengalaman dengan
prototipe awal.
Keempat, pengguna awal penerimaan dari sebuah
aplikasi yang dikembangkan dengan proses evolusi
cenderung lebih tinggi daripada dengan SDLC process. Hal
ini sebagian karena proses evolusi menghasilkan
keterlibatan yang lebih aktif dan lebih banyak kontrol
bersama dari proses pada bagian pengguna.
Kerugian dari sebuah metodologi evolusi terkait
dengan proses membangun evolusi. Prototipe end
biasanya tidak memiliki beberapa fitur keamanan dan
kontrol yang ditemukan dalam sistem yang dikembangkan
dengan proses SDLC. Ini juga mungkin tidak mengalami
jenis yang sama pengujian ketat. Dokumentasi versi final
dapat kurang lengkap karenasifat iter proses. Karena
fokusnya adalah mendapatkan persyaratan yang benar
serta tampilan dan nuansa antarmuka pengguna, fitur
infrastruktur penting lainnya dari sistem mungkin tidak
cukup tepat. Namun, banyak dari kelemahan ini dapat
benarEd pada langkah 6 ketika prototipe terakhir
dikonversi ke sistem yang dapat masuk ke produksi. Dalam
beberapa kasus, akan diperlukan untuk prototipe akhir ini
untuk pergi melalui audit yang sama dan kontrol pengujian
sistem yang dikembangkan oleh SDLC sebelum dapat
APterbukti untuk masuk ke produksi. Keprihatinan khusus
akan setiap dependensi sistem baru memiliki dengan
sistem yang ada, biasanya untuk pertukaran data.
Di masa lalu, ketidakefisienan operasional alat
generasi keempat juga memberikan kontribusi pada
kekurangan prototipe akhir. Namun, dengan kemajuan
terbaru dalam perangkat keras dan perangkat lunak untuk
pengembang dan pengguna akhir, masalah ini telah
menjadi jauh lebih penting daripada menerapkan sistem
yang memenuhi kebutuhan pengguna. Seperti yang
dijelaskan sebelumnya, potensi defisit inidinilai pada
langkah 5 dan dikoreksi pada langkah 6 dari metodologi
evolusi dalam gambar 9,8.
Kelemahan potensial lainnya terkait dengan
pengelolaan ekspektasi pengguna. Sering kali, sistem
prototipe tampaknya begitu baik bahwa pengguna enggan
untuk Wait untuk berfungsi dengan baik, sistem operasi
didokumentasikan.
Prototyping dalam proses SDLC
Sebagai alat generasi keempat telah menjadi biasa,
penggabungan beberapa langkah dari proses evolusi
menjadi metodologi SDLC juga menjadi umum. Dalam
paragraf berikut kami menjelaskan dua cara bahwa
Prototyping umumnya dimasukkan ke dalam proses SDLC.
Pertama, prototyping digunakan dalam fase definisi
untuk membantu pengguna menentukan persyaratan
sistem, terutama untuk antarmuka pengguna (Computer
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 379
layar dan navigasi). Seperti yang ditunjukkan pada gambar
9,9, proses SDLC masih dimulai dengan analisis kelayakan.
Namun, untuk langkah definisi persyaratan, spesialis IS
menggunakan alat pengecatan layar untuk menghasilkan
versi layar awal dan laporan yang dapat kamiuji coba. Ini
mungkin contoh prototipe nonoperational, di mana
desain layar tidak terhubung ke database Live. Setelah
persyaratan telah ditentukan dengan bantuan
serangkaian prototip, sisa langkah dalam proses SDLC
tetap sama. Namun, pembangun sistem juga dapat
membuat penggunaan layar selama desain dan
membangun langkah, dan mereka mungkin sebenarnya
menggunakan kode komputer yang dihasilkan oleh alat
Prototyping dalam sistem akhir.
Cara kedua prototyping digunakan lebih kompleks
dan termasuk pelaksanaan percontohan prototipe kerja.
Jenis prototipe ini biasanya adalah firstof-a-Series jenis
sistem percontohan. Tidak seperti strategi peluncuran
pilot yang dibahas untuk tahap pelaksanaan proses SDLC,
di mana sebuah sistem lengkap pertama kali
diimplementasikan hanya dalam sebagian dari organisasi,
di sini tujuannya adalah untuk menggunakan prototipe
skala-down hanya dalam jumlah minimal lokasi dalam
organisasi dalam rangka untuk menilai kelayakan dalam
operasi setting. Seperti yang ditunjukkan pada gambar
9,10, fase definisi proses SDLC digantikan oleh tiga langkah
dalam fase Prototyping/piloting.
Prototyping/piloting tahap
Tentukan persyaratan dasar
Prototipe sistem
Percontohan prototipe
Fase konstruksi SDLC
Modifikasi sistem desain
Sistem bangunan
Pengujian sistem
Fase implementasi SDLC
Instalasi
Operasi
Pemeliharaan
Gambar 9,10 Prototyping/piloting fase menggantikan fase
definisi SDLC
Setelah persyaratan dasar ditentukan (langkah 1),
prototipe kerja dikembangkan (langkah 2). Prototipe awal
cukup dikembangkan untuk menunjukkan solusi teknis
menggunakan perangkat keras dankomponen ftware
sehingga biasanya tidak pernah digunakan sebelumnya
dalam organisasi. Pada langkah 3, prototipe diperpanjang
untuk menjadi prototipe kerja yang dapat dipiloted
dengan subset dari pengguna yang ditargetkan.
Pendekatan Prototyping/piloting ini dalam SDLC
sangat berguna untuk proyek besar dan berisiko yang
melibatkan risiko teknologi atau risiko organisasi, atau
keduanya. Sebagai contoh, salah satu tujuan utama
mungkin untuk menunjukkan kemampuan dasar atau
memberikan bukti-of-konsep tes solusi teknis. Tujuan
utama kedua mungkin untuk mendapatkan sponsor
eksekutif untuk membeli ke sistem yang diusulkan.
Dengan bekerja dengan prototipe dengan data langsung,
manajer bisnis dapat mengevaluasi potensi manfaat (dan
risiko) dariaplikasi baru t dia dalam pengaturan
operasional. Harapannya adalah bahwa ini hanya sebuah
prototipe, dikembangkan dengan biaya minimal, yang
akan dimodifikasi sebelum sistem yang sebenarnya
dibangun.
Sebagai contoh, perubahan fungsi berdasarkan
menggunakan prototipe dalampengaturan pil, serta
perubahan dalam teknologi, diantisipasi sebelum sistem
akhir akan diimplementasikan di semua lokasi. Prototipe
digunakan untuk membantu "menjual" sistem untuk
pengguna kunci serta mereka yang memiliki otoritas
anggaran. Jika pilot successful, apa yang dipelajari dari
menggunakan prototipe kerja sekarang dapat dimasukkan
ke dalam desain yang akan digunakan untuk
pembangunan sistem yang sebenarnya. Belajar dari
langkah percontohan juga membantu pengguna
mempersiapkan diri untuk perubahan organisasi yang
diperlukan untuk implement sistem penuh. Langkah yang
tersisa sesuai dengan proses SDLC yang khas.
PENDEKATAN BARU
Tuntutan pengembangan lebih cepat sistem aplikasi baru
telah terus meningkat selama dekade terakhir. Pada
bagian ini, kami membahas secara singkat dua pendekatan
tHat telah terbukti menghasilkan pengembangan yang
lebih cepat dari aplikasi yang disesuaikan dengan kualitas
tinggi dari ukuran tertentu: metodologi Rad dan
pendekatan pengembangan perangkat lunak yang gesit.
Pengembangan aplikasi cepat (RAD)
Pengembangan aplikasi yang cepat (RAD) adalah
metodologi hibrida yang menggabungkan aspek
metodologi SDLC dan Prototyping. Mirip dengan
380 Bagian III • memperoleh sistem informasi
metodologi SDLC, beberapa varian RAD ada dalam
organisasi dan konsultan. Tujuannya adalah untuk
menghasilkan sistem dalam waktu kurang dari satu tahun.
Beberapa organisasi mengadopsi pendekatan Rad
mengharuskan semua proyek sesuai dalam jangka waktu
yang singkat — seperti enam bulan (Clark et al., 1997).
RAD biasanya diterapkan, banyak seperti prototyping,
dalam isolasi dari sistem lain, sehingga saling
ketergantungan antara sistem tidak dianggap.
Siklus hidup RAD dikembangkan oleh guru James
Martin mencakup empat langkah, dengan iterasi antara
dan paralel melakukan antara langkah 2 dan 3, mirip
dengan metodologi Prototyping (Lihat gambar 9,11).
Persyaratan perencanaan langkah menggabungkan
elemen dariproyek TI elemen proposal inisiasi dan langkah
dari fase definisi SDLC. Untuk langkah desain pengguna,
sesi desain aplikasi bersama (jad) dan alat otomatisasi
(kasus) perangkat lunak yang digunakan untuk
menyelesaikan pekerjaan lebih cepat.
Sesi JAD dapat berlangsung beberapa jam atau
dapat diadakan selama beberapa hari berturut-turut. Hal
ini sering diadakan di lokasi dihapus dari tempat kerja
biasa para peserta sehingga
Persyaratan
Perencana
an
Desain
pengguna
Konstruksi
Migrasi
Gambar 9,11 empat langkah Rad Life Cycle
bahwa tugas dapat terkonsentrasi pada tanpa gangguan.
Lokasi terpencil juga membantu menyiapkan forum bagi
perwakilan pengguna untuk bekerja melalui area
ketidaksepakatan; mencapai pemahaman bersama adalah
sangat penting ketika Cross-sistem fungsional sedang
dikembangkan. Sesi JAD dipimpin oleh seorang fasilitator
yang tidak hanya terampil dalam analisis sistem dan teknik
desain tetapi juga terampil dalam mengelola interaksi
kelompok; seseorang yang di luar organisasi terkadang
digunakan dalamperan fasilitator untuk memiliki pihak
ketiga yang netral yang dapat membantu menyelesaikan
konflik dan menjaga agar grup tetap fokus pada hasil sesi
jad.
Seperti yang ditunjukkan pada gambar 9,12, alat
rekayasa perangkat lunak komputer (kasus) termasuk
alat analisis Front-end SuCH sebagai alat pembuatan
diagram, alat analisis, dan tampilan komputer dan alat
generator laporan untuk mendukung definisi persyaratan
dan desain sistem; back-end alat untuk menghasilkan
kode (dalam satu atau lebih bahasa komputer) dari
diagram dan dokumen desain lainnya; dan repositori
terpusat untuk logika pemrosesan, struktur data,
Spesifikasi lain, dan dokumen manajemen proyek untuk
sistem perangkat lunak. Sistem kasus siklus penuh, juga
disebut alat kasus terpadu (I-Case) , mengombinasikan
fungsi Front-end dan back-end untuk menghasilkan
sistem kerja.
Kembali ke gambar 9,11, dalam fase konstruksi kode
komputer yang dihasilkan menggunakan alat kasus.
Anggota tim bisnis membantu memvalidasi layar dan fitur
desain lainnya, dan pendekatan iteratif kemudian
digunakan untuk membuat DesiGN perubahan dan
menghasilkan kode baru untuk validasi. Sebuah
pendekatan migrasi digunakan untuk mengkonversi
organisasi ke sistem baru. Dengan menggunakan
pendekatan implementasi ini, pengujian sistem harus
dilakukan pada waktu yang hampir sama bahwa pelatihan
pengguna danpersiapan nizational orga lainnya sedang
dicapai.
Pemeriksaan terstruktur dan Tinjauan sistem yang
merupakan keunggulan dari pendekatan SDLC juga
digunakan dalam pendekatan RAD. Namun, tidak seperti
pendekatan SDLC tradisional, ketika pengguna
menandatangani pada kasus-based Designn dokumen,
harapan adalah bahwa mereka juga akan terlibat dalam
langkah konstruksi, di mana perubahan desain tambahan
dapat dibuat sesuai kebutuhan. Selain pengujian
kegunaan intensif dengan keterlibatan pengguna akhir,
prosedur jaminan kualitas yang ketatRe juga dibangun ke
dalam metodologi rad.
RAD adalah metodologi yang bekerja dengan baik
dalam lingkungan bisnis yang ditandai dengan perubahan
yang cepat. Tim desain yang lebih kecil dan waktu
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 381

pengembangan yang lebih pendek yang terkait dengan masih diproduksi dengan cepat tetapi kurang cenderung
Rad juga dapat mengakibatkan total biaya yang lebih menjadi solusi perangkat lunak yang optimal untuk bisnis.
rendah develmengembangkan. Sebagai contoh, Angkatan
Laut A.S. telah melaporkan penghematan pengembangan Agile methbau
sistem hingga 50 persen dan penghematan pemeliharaan Tidak ada satu sistem Metodologi pengembangan bekerja
tahunan sebesar 20 persen (Valacich et al., 2009). Di sisi dalam setiap keadaan lebih baik daripada semua
lain, peningkatan kecepatan terkadang dapat juga metodologi lain. Inilah sebabnya mengapa terstruktur,
memiliki kekurangannya. Misalnya, fungsi noncritical atau cepat, dan metodologi lain semua telah dikembangkan.
standar kualitas mungkin dikorbankan, seperti antarmuka Pengembangan sistem sulit karena berbagai alasan,
pengguna yang konsisten di seluruh layar dan standar Including berikut:
penamaan elemen data.
Gambar 9,13 meringkas beberapa kelebihan dan • Persyaratan adalah tentang berurusan dengan
kekurangan dari RAD. Seperti prototyping, sebuah metode masalah bisnis bukan fitur perangkat lunak, namun
RADology sangat tergantung pada keterlibatan oleh bagaimana kita menerapkan metode yang berbeda
pengguna kunci. Jika pengguna kunci ini tidak dibebaskan sering mencoba untuk memisahkan kedua aspek
untuk bekerja pada proyek RAD, aplikasi kustom mungkin terlalu banyak.
• Alat pembuatan diagram: mendukung representasi grafik
untuk proses, data, dan diagram struktur kontrol
• Layar komputer dan generator laporan: digunakan untuk
prototipe antarmuka pengguna untuk input (tampilan layar, bentuk) dan
laporan sebagai bagian dari persyaratan definisi • alat analisis:
Checkers otomatis untuk hilang, tidak konsisten, atau spesifikasi yang
salah dalam diagram, formulir, dan laporan
• Repositori Central: penyimpanan terpadu dari spesifikasi
sistem, diagram, laporan, dan dokumen manajemen proyek
• Dokumentasi generatORS: menghasilkan dokumentasi teknis
dan pengguna dalam format standar
• Generator kode: generasi otomatis program dan kode definisi
database dari diagram, formulir, laporan, dan dokumen desain lainnya

Gambar 9,12 jenis kasus alat (berdasarkan valacich, George, dan Hoffer, 2009)
Keuntungan
• Dramatis tabungan dalam waktu pengembangan
• Berfokus pada persyaratan sistem yang penting
• Kemampuan untuk dengan cepat mengubah desain sistem pada
permintaan pengguna

Kerugian
• Kualitas dapat dikorbankan untukkecepatan r
• Komitmen yang menyita waktu untuk personel pengguna utama
• Kemungkinan pintas pada standar internal dan modul usabilitas

FIGURE 9.13 RAD Advantages and Disadvantages

• Bisnis (dan pengembang, juga) mungkin tidak
knowapa yang mungkin dengan itu, sehingga
mereka dapat membatasi kebutuhan mereka untuk
apa yang mereka anggap mungkin atau aturan bisnis
saat ini daripada apa yang bisa dilakukan dengan
"Out-of-The-Box" berpikir.
• Kondisi bisnis yang terus berubah, persyaratan
sofreezing selalu berarti berada di luar langkah
sekali sistem diimplementasikan (by the way, ada
kebenaran yang sama dengan buku pelajaran!)
• Sering tidak ada konsensus tentang apa yang
diperlukan (karena situasi yang berbeda atau
budaya dalam kelompok pengguna yang berbeda),
382 Bagian III • memperoleh sistem informasi
sehingga perjanjian mungkin tidak dapat dicapai
sampai ke proyek.
• Pergantian personil selama proyek, baik dari
komunitas pengguna dan tim pengembangan,
berarti ide baru, keterampilan baru, dan
pendapatan kembali.
Metodologi yang berbedaes berusaha untuk mengatasi
masalah ini dengan cara yang berbeda.
Dalam beberapa tahun terakhir, sebuah disiplin
pengembangan perangkat lunak yang gesit telah muncul
sebagai metodologi alternatif untuk proyek yang lebih
kecil (misalnya, tim proyek tidak lebih besar dari 20) dalam
rangka untuk mengatasi beberapa masalah inis. Tujuannya
adalah untuk memberikan perangkat lunak dengan tingkat
cacat yang sangat rendah, berdasarkan satu set empat
nilai kunci:
• Kesederhanaan
• Komunikasi
• Umpan balik
• Keberanian
Sebuah proyek bukanlah sebuah aplikasi penuh,
melainkan satu modul atau bagian kerja dari sebuah
aplikasi penuh. Ini empat principles didasarkan pada "The
Agile manifesto," yang telah diadopsi oleh 17 pemimpin di
lapangan (Lihat www. agilealliance.
org, http://agilemanifesto.org, dan Hoffer et al, 2011).
Sebuah "seluruh tim" pendekatan yang diambil di
mana perwakilan bisnis (pelanggan) dan anggota tim
teknis (programmer) bekerja di ruang kerja Co-terletak
(terkadang disebut bullpen) setiap hari. Penekanan
ditempatkan pada interaksi antara peserta ini, bukan pada
proses yang mereka ikuti, alat yang mereka gunakan, atau
kontrak formal antara pengembang dan CLient. Harian,
tatap muka percakapan antara anggota tim inti ini, bukan
dokumentasi dan wawancara dengan subyek ahli,
mendominasi persyaratan penentuan. Anggota tim
menggunakan proses memanfaatkan adaptasi daripada
perencanaan. Versi perangkat lunak yang bekerja, bukan
artefak, adalah ukuran kemajuan, dan komponen kerja ini
atau kenaikan (potongan dari keseluruhan) diproduksi
sangat sering. Pendukung menyarankan bahwa
pendekatan yang lebih teknik dari metode pengembangan
sistem tradisional gagal karena tidak dirancang untuk
menangani perubahan persyaratan (karena mengubah
bisnis atau pemahaman yang lebih baik kebutuhan) di
sebagian besar perangkat lunak kegiatan pembangunan.
Perubahan persyaratan yang terlambat disambut dengan
metode Agile. Bahkan, prinsip inti of metode Agile adalah
untuk merespon perubahan daripada mematuhi rencana.
Pembelajaran terjadi melalui persyaratan repletion dan
readdressing secara bertahap.
Metode Agile mirip dengan metode iteratif lainnya,
seperti Prototyping dan Rad, tetapi berbeda dalam sikluss
untuk pengiriman produk kode baru jauh lebih pendek
(pada kenyataannya, kanbanare menjadi minggu bukan
bulan) dan dalam kolaborasi yang sangat dekat dari
anggota tim. Penekanan adalah pada perangkat lunak
kerja atas dokumentasi yang komprehensif. Gambar 9,14
Rilis 1 Rilis 2 Rilis 3
Langk Fokus
ah
Kelayakan Fungsi
Persyaratan
Desain
Coding
Pengujian
Dokumentasi
Instalasi Arsitektur
Waktu
Gambar 9,14 proses pengembangan sistem Agile
mencirikan pendekatan lincah, dengan rilis perangkat
lunak sering dan bersepeda cepat atas fase
pengembangan sistem definisi, konstruksi, dan
pelaksanaan dan berbagai langkah mereka. Beberapa
melihat bagan ini sebagai rute dari yo-yo dari waktu ke
masa. Setiap releASE adalah refactoring dan peningkatan
akumulasi rilis sebelumnya; pekerjaan sebelumnya tidak
dihapus. Perangkat lunak ini akan lebih baik dengan setiap
rilis. Rilis awal lebih fokus pada masalah arsitektur (lem
yang akan memegang potongan bersama-sama),
sedangkan r akhirrilis bor jauh ke dalam fungsi tertentu.
Aplikasi ini terdiri dari himpunan semua rilis dan dapat di
bawah terus berubah. Ada kebutuhan untuk langkah awal
untuk membangun arsitektur keseluruhan untuk sistem
aplikasi sehingga setiap Bagian dapat dikembangkan dan
semua potongan akan cocok bersama-sama (ingat gambar
8,1).
Metode Agile adalah perubahan radikal dalam
pengembangan sistem dan dapat ditentang oleh staf
pengembangan sistem (Wailgum, 2007). Beberapa
melihat metode Agile terlalu didominasi oleh pengguna
yang tidak mengerti TI atau terlalu tergantung pada
sumber daya yang langka pengembang ahli yang akan
digunakan untuk banyak proyek pengembangan sistem.
Individu di tim dapat disebut "orang ungu," karena mereka
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 383
adalah generalis, baik bisnis maupun spesialis IT (oDD
referensi untuk menggabungkan "merah" dan "biru"
untuk mendapatkan ungu). Yang lain merasa bahwa
kurangnya desain yang dalam-depan kompromi arsitektur
suara yang dibutuhkan untuk kuat dan mudah untuk
mempertahankan sistem organisasi. Karena pengujian
terjadi di seluruh pengembangan cycle, bukan pada poin
tetap dikontrol oleh staf jaminan kualitas, beberapa
percaya pengujian terlalu ad hoc dan myopic. Beberapa
percaya kurangnya atau terbatas melakukan perencanaan
dan dokumentasi adalah bahaya. Untuk alasan ini dan
lainnya, metode Agile masih muncul sebagai pendekatan
yang diterima untuk pengembangan sistem. Proyek yang
sukses menggunakan metode Agile membuat organisasi
lebih memperhatikan potensi metodologi Agile.
Fowler (2003) merekomendasikan bahwa
metodologi Agile yang paling cocok untuk situdengan
persyaratan dinamis, berdedikasi dan termotivasi anggota
tim, dan pelanggan bersedia menjadi anggota tim inti dan
juga bahwa tim inti dapat disimpan relatif kecil (20 atau
anggota yang lebih sedikit).
Agile adalah istilah umum yang mencakup berbagai
metode SPspesifik dan teknik. Beberapa metode dan
teknik tangkas yang lebih banyak digunakan adalah Crystal
Clear, pengembangan perangkat lunak adaptif, scrum,
pengembangan fitur yang digerakkan, dan pemrograman
ekstrem. Sisa dari bagian ini menyajikan ikhtisar
dariberbagaimetode dan teknik ini sebagai cara untuk
mengilustrasikan apa yang mungkin terjadi pada sebuah
proyek menggunakan pendekatan Agile dan untuk
mengilustrasikan beberapa prinsip penting yang
melampaui semua metode Agile.
EXTREME PROGRAMMING dalam satu pendekatan Agile,
disebut extrEME Programming (XP), para programmer
menulis kode produksi secara berpasangan. Dengan
menggunakan desain sederhana (definisi dan konstruksi
menyatu bersama-sama) dan pengujian sering, tim
menghasilkan kecil, rilis sepenuhnya terintegrasi yang
lulus semua tes penerimaan pelanggan dalam waktu yang
sangat singkat (misalnya, setiap dua minggu). Setiap siklus
dimulai dengan pengguna menulis cerita untuk
menggambarkan kebutuhan mereka untuk aplikasi
(Serena, 2007). Siklus menganalisis, Desain, kode, dan tes
secara integral dihubungkan dan diulang sampai solusi ng
workidikembangkan. Perubahan kode sering (biasanya
setiap hari). Tim pemrograman menguji kode mereka
sendiri (yang merupakan perubahan radikal dari
metodologi pengujian tradisional). Kedua anggota dari
pasangan pemrograman melakukan coding dan pengujian
secara paralel, sehingga Duttidak dibagi oleh satu orang
coding dan pengujian lainnya. Hal ini diklaim bahwa proses
tersebut menghasilkan kode yang lebih tinggi kualitas
lebih cepat (untuk situasi yang diuraikan sebelumnya).
Pasangan pemrograman kemudian mungkin
membubarkan diri untuk membentuk pasangan baru dan
dengan demikian dengan cepat SHadalah pengetahuan
khusus mereka dan kode selesai. Ciri lain dari pendekatan
XP adalah obsesi dengan umpan balik dan pengujian.
Sebagai program yang diuji oleh tim yang dirilis ke
repositori kolektif, setiap pasangan programmer dapat
meningkatkan salah satu c Ode kolektifsetiapsaat,
mengikuti standar pengkodean umum yang diadopsi oleh
semua tim.
XP berfokus pada masalah langsung, tidak
mengantisipasi kebutuhan masa depan. Ini dan faktor
lainnya menjaga desain sederhana, tujuan utama dari
teknik ini. Tiga sifat yang mencirikan desain sederhana:
• Sistem harus mengkomunikasikan semua yang Anda
inginkan untukberkomunikasi (yaitu, lengkap dan
mendokumentasikan diri) • sistem harus berisi tidak
ada kode duplikat (sehingga menggunakan kembali
kode modul sangat penting, maka kesederhanaan
dan standar adalah kunci untuk reusability)
• Sistem harus memiliki jumlah paling sedikit dari
com-ponents mungkin
SCRUM Yes, bagi Anda penggemar Rugby, asal-usul
metode Agile scrum dalam olahraga tim ini, di mana
gerakan yang diatur dengan baik antara anggota tim
adalah penting. Scrum Master (SM) menyelenggarakan
kerja tim scrum, berfungsi sebagai penghubung tim
dengan tim laind dengan klien, dan memonitor kinerja tim.
Scrum menekankan tim proyek independen, koordinasi
dan komunikasi antara dan dalam tim, pemantauan kerja
yang berulang-ulang dan berkesinambungan, dan metode
kerja yang sangat efisien. Sebuah kendaraan besar yang
scrum uSES untuk tujuan ini adalah pertemuan (Cho et al.,
2006):
• Harian scrum pertemuan yang sangat singkat (5
sampai 15 menit) "stand up" sesi untuk masing-
masing tim di mana pengembang pada laporan tim
pada prestasi sejak pertemuan terakhir, apa yang
harus dilakukan sebelum berikutnya meeting, dan
masalah yang mungkin menghambat kemajuan.
384 Bagian III • memperoleh sistem informasi
• Scrum scrum bertemu dengan tim SMs berkumpul
untuk pendek ("berdiri") pertemuan harian dan
bulanan untuk pertemuan lebih lama untuk
meninjau koordinasi antara tim dan masalah antar
tim.
• Perencanaan Sprint pertemuan setiap tim sayaTS
bulanan (untuk sampai satu hari panjang)
mengalokasikan unit kerja dalam proyek jaminan
simpanan untuk anggota tim. Setiap unit kerja
diprioritaskan, dan berdasarkan prioritas ini,
interdependences, dan perkiraan waktu kerja, tugas
dijadwalkan dan ditugaskan sehingga mereka dapat
diselesaikan selama bulan berikutnya.
• Sprint review Rapat tim ini ulasan pertemuan (dalam
sebuah pertemuan yang mungkin berlangsung
sampai hari) prestasi dari rencana kerja bulanan,
mengidentifikasi daerah untuk perbaikan, dan
menyoroti apa yang telah berjalan dengan baik.
Dalam beberapa hal, pertemuan ini menjadi
"produk yang adil" untuk anggota dari tim lain, klien,
dan staf pendukung TI (misalnya, dari jaminan
kualitas dan administrasi data) diundang untuk
melihat hasil menengah.
Pertemuan tambahan atau presentasi yang diperlukan
untuk berbagihasil PR oject dengan klien.
Pertemuan yang sering dan bervariasi ini
memfasilitasi komunikasi dan berbagi ide dan
memberikan tekanan kepada rekan untuk menunjukkan
kemajuan yang nyata. Quality Assurance (QA) dibangun ke
dalam setiap tim dengan memasukkan anggota staf QA
pada setiap tim. RoLe of SM adalah kuncinya dan harus
dijaga dengan cermat. Produk kerja dianggap sebagai
output dari tim. Oleh karena itu, sifat tim scrum cenderung
mendorong kepemilikan tim dan berbagi ide dan solusi
untuk masalah di antara anggota tim.
Mengelola proyek perangkat lunak menggunakan staf
outsourcing
Meskipun mempekerjakan kontraktor di tempat untuk
membantu dengan perangkat lunak kustom proyek telah
menjadi praktek yang luas selama beberapa dekade, hari
ini ada fokus baru pada menjaga biaya pengembangan
perangkat lunak dengan outsourcing bagian dari PRoject
untuk off-pekerja situs, terutama pekerja lepas pantai di
pasar tenaga kerja yang berbeda dan kurang mahal.
Keuntungan lain dari menggunakan sumber daya eksternal
untuk membantu atau menggantikan staf internal untuk
pekerjaan pengembangan kustom adalah untuk
memanfaatkan keahlian teknisdan tersedia di rumah
(beberapa kontraktor mengkhususkan diri pada teknologi
tertentu atau daerah aplikasi ), untuk mempekerjakan
kapasitas di atas garis dasar untuk jumlah pekerjaan
pembangunan organisasi dapat membenarkan pada
waktu tertentu, untuk membebaskan staf internal untuk
bekerja pada proyek yang lebih strategis atau proprietary
yang harus disimpan di-rumah, dan untuk dapat
menyelesaikan proyek lebih cepat (karena ketika staf
internal atau keahlian tersedia). Beberapa organisasi
sebenarnya outsourcing kelompok pengembangan
seluruh sistem mereka; thbiasanya terjadi ketika
organisasi merasa misinya tidak termasuk mengelola
pengembangan sistem informasi. Beberapa organisasi
kecil mungkin merasa mereka tidak mampu untuk
mempertahankan kualitas staf pengembangan TI.
Outsourcing off-site dapat melibatkan kontrak
dengan perusahaan dalam negara atau wilayah yang sama
("Onshore") atau tidak ("Offshore"). Offshore Outsourcing
sering didorong oleh harga karena biaya tenaga kerja
secara tradisional telah 40 untuk 60 persen kurang oleh
Offshoring work untuk kelompok pengembangan sistem di
India, Eropa Timur, atau Asia. Seperti yang akan dibahas
secara lebih rinci dalam Bab 13, beberapa risiko yang
signifikan outsourcing lepas pantai adalah hilangnya
beberapa kontrol (atau setidaknya kontrol lebih sulit
karena perbedaan zona waktus), bahasa dan budaya
hambatan, dan ancaman pembajakan Intelektual.
Menurut Poria (2004), alternatif lepas pantai
kemungkinan adalah pilihan yang sangat menguntungkan
ketika ada kondisi berikut:
• Persyaratan sistem dapat didefinisikan dengan baik
danwiLL tetap relatif stabil atas proyek.
• Waktu adalah esensi dan ketersediaan 24/7 Re-
sumber untuk bekerja pada proyek yang
menguntungkan.
• Biaya proyek (atau program) adalah
importantpertimbangan.
Penelitian oleh Holmström et al. (2006)
menunjukkan bahwa metode Agile scrum dan EXtreme
Programming berguna dalam mengatasi beberapa risiko
proyek pengembangan perangkat lunak lepas pantai.
Metode ini, dengan komunikasi eksplisit dan mekanisme
koordinasi, dapat mengurangi dampak negatif dari jarak
antara anggota tim. Panduan untuk mengelola interaksi
sehari-hari secara efektif dengan pemilik proyek di luar
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 385
situs juga telah dikembangkan. Sebagai contoh, beberapa
pedoman kunci yang diterbitkan oleh kelompok minat
sourcing (dan diringkas dalam McNurlin dan sprague,
2004) dan oleh Rottman dan lacity (2004) adalah sebagai
berikut:
Mengelola ekspektasi, bukan Staf staf agen
outsourcing tidak berada di bawah kendali langsung
perusahaan klien dan juga imbalan mereka yang
terikat pada klien, jadi mode fasilitasi dari working
adalah yang terbaik di mana fokusnya adalah pada
hasil.
Ambil tindakan eksplisit untuk mengintegrasikan
pekerja di luar situs yang mengelola proyek di
seluruh kelompok kerja memerlukan lebih banyak
formalitas, seperti hasil dan langkah eksplisit yang
disepakati. Staf in-House bahkan mungkin
mendapatkan keuntungan dari pindah ke
perusahaan agen penjual untuk bekerja
berdampingan dengan mereka dan mempelajari
bagaimana mereka bekerja sama secara internal.
Berkomunikasi secara rutin manajer yang
bertanggung jawab atas hubungan dengan para
pemilik proyek perlu menjaga jalur komunikasi tetap
terbuka.
Sebuahcara informal yang dibandoning dapat
mengakibatkan peningkatan kekakuan karena
model bisnis mereka, penyedia layanan mungkin
memiliki proses yang lebih disiplin daripada
organisasi klien, yang dapat menyebabkan solusi
kualitas yang lebih tinggi.
Buat kantor manajemen proyek terpusat PMO
adalah pusat keunggulan untuk mengelola proyek;
unit khusus PMO dapat berkonsentrasi pada
pengelolaan proyek lepas pantai, yang dapat
menjadi sangat tidak efisien karena risiko yang
disebutkan sebelumnya.
Mulailah dengan proyek percontohan proyek
percontohan kecil akan menguji hubungan kerja,
membangun kepercayaan, dan mengembangkan
pengalaman untuk proyek yang lebih penting
kemudian.
Hire keahlian hukum lepas pantai konsultan hukum
khusus dapat membantu dalam menulis kontrak
untuk mengelola implikasi pajak, melindungi
kekayaan intelektual, alamat perbedaan dalam
sistem hukum dan peraturan, menangani masalah
visa bagi pekerja yang telah untuk melakukan
perjalanan antara organisasi Anda dan tdia
kontraktor, menentukan kiriman tepat dan istilah
(sering disebut Perjanjian tingkat layanan), dan
membantu dalam menyelesaikan sengketa.
Gunakan link komunikasi yang aman dan berlebihan
link komunikasi tersebut membantu untuk
memastikan dokumentasi sensitif yang harus dibagi
antara organisasi Anda dan kontraktor tiba dan
terlindung dari pencurian.
PENGEMBANGAN APLIKASI PENGGUNA
PENDUKUNG (UAD)
Setelah IBM Corp. memperkenalkan komputer mikro
pertamanya (disebut "komputer pribadi" atau PC) pada
akhir 1981, mikrokomputer mulaimuncul di desktop
manajer dan analis bisnis. Banyak dari PC ini dibeli oleh
manajer bisnis menggunakan peralatan kantor anggaran
tanpa pengetahuan atau dukungan dari Departemen IS.
Sampai ada "panggilan untuk bantuan" dari pengguna
komputer or Business Manager, Departemen is mungkin
tidak bahkan diketahui apa hardware dan software yang
digunakan dalam bisnis.
Pada awal 1990-an, ketika jaringan area lokal yang
memungkinkan berbagi sumber daya mikrokomputer
(termasuk printer dan data) mulai dipasang di organisasi,
manajer is mulai mengimplementasikan pendekatan yang
kurang reaktif untuk mendukung pengguna
mikrokomputer. Penggunaan komputer desktop juga
menjadi lebih luas karena meningkatnya keaksaraan
komputer di antara entry-level karyawan yang telah
belajar PC (atau Mac) aplikasi sebagai bagian dari program
kuliah mereka. Manajer Bisnis melek komputer mengenali
bahwa spreadsheet kecil dan aplikasi database, serta
laporan dengan grafis, biasanya bisa lebih cepat
dikembangkan oleh pekerja mereka sendiri. Tnya berarti
bahwa manajer bisnis tidak harus mengisi permintaan
proyek formal untuk aplikasi yang akan dikembangkan
oleh staf is, yang biasanya akan memakan waktu lebih
lama atau mungkin tidak akan disetujui untuk sumber daya
is sama sekali.
Hari ini, tantangan keseluruhan dalam mengelola
pengembangan aplikasi pengguna adalah untuk
menemukan cara terbaik untuk memaksimalkan potensi
manfaat dari pengembangan aplikasi oleh pengguna tanpa
membuat tingkat yang tidak dapat diterima risiko kepada
386 Bagian III • memperoleh sistem informasi

organisasi untuk menggunakan aplikasi dikembangkan Integrasi Bisnis, dan (3) peningkatan risiko operasional
oleh u Sers minimal terlatih. karena omset pengembang. Mari kita mengatasi masing-
masing downside ini secara lebih mendalam.
Keuntungan dan kerugian dari aplikasi Pertama, downside utama dapat potensi hilangnya
Userdikembangkan kontrol kualitas. Berdasarkan metode pelatihan dan kerja
mereka, profesional IS mendesain kontrol yang kuat ke
Memahami potensi keuntungan dan kerugian dari aplikasi dalam sistem informasi baru: kontrol untuk akses data dan
yang dikembangkan pengguna sangat penting untuk input, kontrol untuk penghitungan dan output lainnya,
membuat pilihan yang baik tentang apakah aplikasi baru serta kontrol aplikasi untuk pencadangan dan keandalan.
harus userdikembangkan atau IS-developed (yaitu, Seperti dalam profesi apapun, produk yang dikembangkan
internal, eksternal, atau dibeli). Lebih dari 25 tahun yang oleh mereka yang kurang pelatihan dan experieNCE akan,
lalu, guru IT produktif James Martin mengejutkan banyak pada rata, menjadi kualitas yang lebih rendah. Tergantung
profesional TI dengan menganjurkan bahwa organisasi pada jenis dan ukuran aplikasi, ada juga biaya organisasi
berinvestasi dalam produk perangkat lunak bagi pengguna yang terkait dengan memiliki tidak terlatih, atau sebagian
untuk mengembangkan aplikasi mereka sendiri: terlatih, karyawan menghabiskan cukup banyak waktu
pada apa yang bisa much lebih efisien dicapai oleh TI
Penurunan biaya yang terus menerusuntuk
Profesional. (Demikian pula, waktu yang dihabiskan oleh
komputer kini telah melewati titik di mana
manajer bisnis pada pengembangan aplikasi dapat waktu
komputer telah menjadi lebih murah daripada
yang dihabiskan dari pekerjaan inti mereka dan
orang.
kompetensi.) Bug yang tidak terdeteksi dalam logika
— JAMES MARTIN, pengembangan aplikasi pemrosesan, kurangnya jejak audit, prosedur
tanpa programer, 1982 pencadangan dan keamanan yang tidak memadai, dan
sistem yang tidak didokumentasikan jauh lebih umum
Keuntungan utama UAD adalah karena pengguna (1) pada sistem userdikembangkan daripada yang
tidak harus menjelaskan persyaratan informasi mereka dikembangkan oleh profesional is yang terlatih (schultheis
untuk seorang analis yang tidak akrab dengan konteks dan Sumner , 1991). Kesalahan dalam program
bisnis dan (2) tidak harus menunggu untuk IS sumber daya spreadsheet sangat umum, dan keputusan bisnis
yang akan ditugaskan untuk bekerja pada proyek mereka. berdasarkan data yang salah dapat membahayakan
Sebaliknya, the manajer bisnis dapat menentukan kapan kelangsungan hidup bisnis (Lihat sidebar yang berjudul
pekerja sendiri harus menghabiskan waktu untuk "kesalahan dalam spreadsheet").
menggunakan alat komputer untuk mengembangkan
aplikasi baru. Hal ini sering dapat mengakibatkan respon
yang lebih tepat untuk informasi tertentu. Manajer bisnis
juga mendapatkan kontrol total atas biaya
pengembangan: tidak ada tagihan balik biaya dari
Departemen is internal atau kewajiban kontraktual
dengan vendor luar jika karyawan manajer sendiri dapat
mengembangkan aplikasi. Pengembangan aplikasi
pengguna (UAD) juga dapat menjadi keuntungan yang
jelas ketika internal adalah sumber daya yang relatif
langka: dalam situasi ini, mungkin yang terbaik bagi
sebuah organisasi untuk menggunakan sumber daya is
untuk bekerja pada proyek yang membutuhkan lebih
canggih, IT khusus skillsets atau untuk aplikasi yang
melayani beberapa pengguna departments.
Namun, organisasi juga perlu mengenali potensi
kerugian untuk aplikasi yang dikembangkan oleh spesialis
non-IS: (1) kurangnya kontrol aplikasi untuk keamanan dan
kualitas data, (2) hilangnya kesempatan untuk TI dan
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 387

Kedua, ketika sistem adalah developed di luar Akhirnya, aplikasi yang dikembangkan pengguna
organisasi is, ada juga kemungkinan yang lebih besar yang digunakan secara berkelanjutan dapat menimbulkan
bahwa risiko operasional. Sistem korporat yang dijalankan di
peluang server di
untuk pusat
integrasi data
data tidak
Kesalahan dalam spreadsheet
terjawab.
Karyawan Pengguna akhir menghasilkan model spreadsheet yang tak terhitung jumlahnya setiap tahun, seringkali
untuk memandu keputusan misi-kritis. Beberapa konsultan telah mengklaim bahwa sesuatu seperti sepertiga
waktu
dari semua model spreadsheet operasional mengandung kesalahan. Konsultan rumah air satu harga
yang melaporkan audit empat model spreadsheet besar untuk klien dan menemukan 128 kesalahan.
dihabiskan Berbagai jenis kesalahan contaidi spreadsheet yang telah diidentifikasi meliputi berikut ini:
• Kesalahan mekanis— kesalahan pengetikan, kesalahan penunjuk, dan slip sederhana lainnya.
Kesalahan mekanis dapat sering, tetapi mereka memiliki kesempatan tinggi tertangkap oleh orang yang
membuat kesalahan.
• Kesalahan logika— formula salah karena memilih algoritma yang salah atau membuat formula
yang salah untuk mengimplementasikan algoritma. Kesalahan logika murni dihasilkan dari selang dalam
logika, sedangkan kesalahan logika domain terjadi karena pengembang tidak memilikipengetahuan
wilayah SS yang diperlukan. Beberapa kesalahan logika juga lebih mudah untuk diidentifikasi daripada
yang lain: kesalahan mudah-untuk-bukti telah disebut kesalahan Eureka, dan sulit-untuk-bukti
kesalahan telah disebut kesalahan Cassandra.
• Kelalaian kesalahan-hal yang ditinggalkan dari model yang harus ada di sana. Mereka sering hasil
dari salah tafsir dari situasi. Penelitian faktor manusia telah menunjukkan bahwa kesalahan kelalaian
memiliki tingkat deteksi yang rendah.
• Kesalahan kualitatif-cacat yang tidak menghasilkan kesalahan quantita segera, tetapi dapat
menyebabkan kesalahan kuantitatif selama nanti "What-if" analisis atau ketika update yang dibuat
untuk model spreadsheet, atau kesalahan yang menyebabkan pengguna untuk salah menafsirkan model
membuat pemeliharaan menjadi sulit, menyebabkan peningkatan biaya pengembangan dan potensi
kesalahan baru.
Untuk mengurangi tingkat kesalahan memerlukan teknik agresif-mirip dengan disiplin diikuti oleh
pengembang aplikasi yang lebih kompleks.

[Berdasarkan panko, 1996, dan panko dan Halverson, 1996]

"Reinventing" aplikasi (dan data) dengan fungsionalitas
yang mirip dengan aplikasi yang sudah digunakan oleh
workgroup lain, atau hilang kesempatan untuk organisasi
yang lebih besarnilai Al dengan menyertakan fitur lain
pengguna akan menemukan menarik. Ketika unit bisnis di
seluruh organisasi secara independen mengembangkan
aplikasi yang menggunakan definisi perangkat lunak dan
data yang mereka pilih sendiri, hasilnya adalah lusinan,
atau bahkan ratusan, dari apa yangdisebut sebagai Silo
terisolasi atau "pulau" dari Otomatisasi. Risikonya
mencakup tidak hanya data yang tidak dapat dibagikan
tetapi juga laporan yang bertentangan dengan indikator
bisnis utama, terutama jika sumber data yang berbeda,
aturan Bisnis, atau periode waktu digunakan oleh aplikasi
derbagai.
dipantau dan dipelihara oleh spesialis komputer. Namun,
responsibilities untuk operasi yang sedang berlangsung
dan pemeliharaan aplikasi userdikembangkan biasanya
milik unit bisnis yang dibuat dan memiliki aplikasi-dan
mungkin sebenarnya dikelola oleh satu karyawan yang
awalnya dikembangkan itu. Jika asli mengembangkanr dari
aplikasi database atau aplikasi spreadsheet (terutama satu
dengan logika kompleks) bergerak ke unit kerja yang
berbeda, atau bahkan yang berbeda
388 Bagian III • memperoleh sistem informasi

Karakteristik aplikasi
Lingkup (Personal, Departmental, organisasi)
Kritik/dampak (Risk ExposUre)
Ukuran dan penggunaan (satu kali, periodik, berkelanjutan)
Kompleksitas masalah bisnis (kesamaan tugas, struktur masalah)

Karakteristik alat
Alat kecanggihan/kompleksitas
Keterkaitan

Karakteristik pengembang
Keahlian, pengalaman, dan ketersediaan Developer pengguna
IS keterampilan spesialis, pengalaman, dan ketersediaan

Gambar 9,15 aplikasi, alat, dan faktor risiko pengembang

organisasi, sistem yang dikembangkan pengguna mungkin
harus ditinggalkan karena kurangnya pengetahuan dan
dokumentasi penduduk dalam unit bisnis (Klepper dan
Sumner, 1990). Eksposur risiko ini terutama besar ketika
aplikasi sedang digunakan sebagaialat pendukung agerial
pria untuk keputusan dengan dampak tinggi atau sebagai
pengolahan transaksi reguler dan sistem pelaporan di
workgroup atau Departemen tingkat.
Jenis risiko organisasi yang terkait dengan
pengembangan aplikasi pengguna meningkat sangat
When aplikasi yang dikembangkan pengguna
diperbolehkan untuk berkembang biak tanpa koordinasi
yang memadai dan pengawasan. Tanggung jawab
manajemen pertama adalah mengidentifikasi Kapan suatu
aplikasi harus dikembangkan oleh pengguna atau
dikembangkan — dengan menilai manfaat dan risiko.
KeledaiSing risiko dari UAD
Mari kita beralih sekarang ke masalah dalam kondisi apa
aplikasi tertentu harus dikembangkan oleh pengguna
bisnis daripada profesional TI. Seperti diringkas dalam
gambar 9,15, tiga jenis faktor harus dipertimbangkan: ICS
karakterisdari aplikasi yang akan dikembangkan, alat yang
tersedia untuk UAD, dan sumber daya manusia (is atau
pengguna) yang diperlukan untuk kedua aplikasi
berkualitas tinggi dan handal, berkelanjutan
pengoperasian dan pemeliharaan selama masa pakai
aplikasi.
APLIKASI KARAKTERISTICS beberapa karakteristik aplikasi
perlu diperhitungkan. Pertama, risiko organisasi yang
terkait dengan UAD berbeda tergantung pada lingkup yang
dimaksudkan (atau penggunaan organisasi) dari aplikasi
yang akan dikembangkan. Organisasi menilai risikos
berdasarkan tiga tingkat cakupan aplikasi yang biasanya
memiliki tingkat risiko yang sangat berbeda (pyburn, 1986
– 1987), seperti yang ditunjukkan di bawah ini. Aplikasi
pribadi biasanya memiliki risiko yang paling sedikit,
sedangkan aplikasi organisasi memiliki risiko terbesar.
• Aplikasi personal dikembangkan dan digunakan
(dioperasikan) oleh pengguna utama untuk
pembuatan keputusan pribadi, sering menggantikan
pekerjaan yang sebelumnya dilakukan secara
manual
• Aplikasi Departemen dikembangkan oleh satu
pengguna tetapi dioperasikan dan digunakan (dan
mungkin ditingkatkan) oleh beberapa pengguna di
Departemen; aplikasi Departemen sering berevolusi
dari aplikasi yang awalnya dikembangkan untuk
penggunaan pribadi
• Aplikasi organisasi yang digunakan oleh beberapa
usersacross sejumlah Departemen
Selain lingkup aplikasi, potensi dampak keputusan
manajerial berdasarkan aplikasi, serta ukuran aktual dari
aplikasi dan yang dimaksudkanuntuk sering penggunaan,
juga perlu dipertimbangkan. Kecil, aplikasi satu kali
biasanya kandidat yang baik untuk aplikasi yang
dikembangkan pengguna.
Akhirnya, kompleksitas masalah bisnis yang
didukung oleh aplikasi perlu dinilai dalam dua cara yang
berbeda: the derajat yang tugas Umum dan sejauh mana
masalah yang dibahas adalah didefinisikan dengan baik.
Jika aplikasi menangani masalah analitis yang tidak
terstruktur, kombinasi bisnis dan keahlian spesialis IS
mungkin diperlukan untuk Develop aplikasi perangkat
lunak terbaik dan database untuk mengatasinya. Di sisi
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 389

lain, aplikasi untuk mendukung tugas bisnis yang sudah Panduan untuk pengembang pengguna
dipahami dengan baik (umum), seperti sistem untuk
Ketika sistem yang dikembangkan oleh IS profesional,
melacak status beberapa proyek Departemen atau untuk
mereka menggunakan metodologi (dijelaskan sebelumnya
melacak komunikasidengan berbagai pemasok, biasanya
dalam chap ini) sesuai untuk aplikasi tertentu. Untuk
kandidat yang lebih baik untuk solusi yang dikembangkan
sistem yang dikembangkan pengguna, pengembang
pengguna.
pengguna (atau pengelola bisnis yang akuntabel) biasanya
memilih metode pengembangan yang akan digunakan.
Alat karakteristik dua karakteristik alat yang penting untuk
Panko (1988) menunjukkan bahwa metodologi yang paling
dipertimbangkan adalah kompleksitas perangkat lunak
tepat untuk aplikasi yang dikembangkan
yang akan digunakan untuk mengembangkan sistem dan
penggunatergantung pada tiga karakteristik aplikasi:
sejauh mana aplikasi ini harus saling berhubungan dengan
lingkup (penggunaan pribadi atau Departemen), ukuran
aplikasi lain (atau database). Sebagai contoh, fungsi
(kecil hingga besar), dan sifat masalah bisnis yang
spreadsheet relatif sederhana untuk desain dan aplikasi
didukung oleh aplikasi (sederhana untuk kompleks).
spreadsheet yang relatif sederhana untuk
Dalam kerangka panko, SMsemua aplikasi untuk
diimplementasikan, sedangkan alat data pertambangan
masalah sederhana yang akan digunakan oleh orang yang
yang didasarkan pada teknologi RK netwo sarafjauh lebih
mengembangkan aplikasi (lingkup pribadi) dapat
kompleks dan memerlukan lebih canggih alat pelatihan.
dikembangkan dengan pendekatan siklus hidup
Aplikasi juga dapat sangat bervariasi pada sejauh
disederhanakan ("runtuh"). Namun, ketika aplikasi untuk
mana mereka bergantung pada aplikasi lain untuk input
penggunaan pribadi adalah ukuran yang lebih besar dan
data. Jika aplikasi memerlukan alat canggih dan akses ke
Requires logika lebih kompleks, pendekatan yang lebih
data yang didistribusikan melalui jaringan, maka solusi is-
disiplin perlu diambil untuk memastikan aplikasi
dikembangkan mungkin satu-satunya pendekatan yang
berkualitas.
tepat. Namun, hal ini tidak biasa bagi pengguna untuk
Jika aplikasi ini untuk pengguna lain (workgroup atau
terlebih dahulu mengembangkan aplikasi yang berdiri
Departemen), maka satu atau lebih pengguna
sendiri untuk mengatasi masalah bisnis dan kemudian
dimaksudkan lainnya harus terlibat dalam
untuk aplikasi ini untuk digunakan sebagai prototipe
aplikasipengembangan, bahkan jika tim proyek formal
untuk aplikasi yang lebih terintegrasi yang dikembangkan
untuk aplikasi tidak didirikan. Jika besar, aplikasi kompleks
oleh spesialis is.
sedang dikembangkan untuk beberapa pengguna, itu
harus dikembangkan dengan menggunakan metodologi
PENGEMBANG karakteristik keterampilan pengembang
SDLC (dengan diformalkan pengguna dan pengembang
aplikasi dan pengalaman dan ketersediaan sumber daya
peran). Pada kenyataannya, fase definisi harus
pengembang pengguna dalam kaitannya dengan jangka
menyertakan dinegara apakah proyek harus
waktu yang dialokasikan untuk opt develdari aplikasi baru
dikembangkan pengguna atau dikembangkan,
harus dipertimbangkan. Seperti yang telah dibahas
menggunakan faktor seperti yang diringkas sebelumnya
sebelumnya, kurangnya ketergantungan pada sumber
(Lihat gambar 9,15).
daya Departemen IS langka adalah katalis sering untuk
Prototyping dan metode iteratif lainnya sangat
UAD jika pengguna pengembang miliki, atau dapat dilatih
cocok untuk Anda aplikasi yangdikembangkan ser: desain
untuk memiliki, alat keterampilan dan aplikasi
layar dapat dicoba dengan beberapa pengguna, dan alat
Develokeahlian pment diperlukan. Salah satu tantangan
Uad saat ini memiliki antarmuka grafis yang mendukung
manajemen di sini adalah bahwa manajer bisnis yang ingin
Prototyping dengan baik. Namun, seperti yang dijelaskan
aplikasi mungkin tidak memiliki pengetahuan untuk secara
sebelumnya dalam bab ini, seperangkat dasar persyaratan
memadai menilai keterampilan pengembang pengguna
untuk aplikatipada awalnya harus didefinisikan untuk
dan keahlian sebelum proyek mulai berlangsung.
memandu pengembangan prototipe; pengguna yang
Konsultasi wITH adalah ahli di dalam atau di luar organisasi
dipilih kemudian mencoba prototipe dan menyarankan
mungkin diperlukan untuk menilai secara memadai
perubahan; dan prototipe kemudian dimodifikasi oleh
potensi faktor risiko ini.
pengembang sampai ada kesepakatan bahwa aplikasi
memenuhi kebutuhan pengguna bisnis .
390 Bagian III • memperoleh sistem informasi

Gambar 9,16 daftar sejumlah pertanyaan penting penelitian tentang tdia bekerja praktek is profesional telah
yang dapat berfungsi sebagai panduan bagi pengembang menemukan bahwa bercak kesalahan dengan inspeksi
pengguna selama fase definisi dan konstruksi. Pertanyaan sulit bagi programmer asli, pengembang pengguna harus
ini mirip dengan yang timbul selama SDLC atau secara teratur melibatkan orang lain dalam debugging

Definisi fase
Apa output harus sistem menghasilkan?
Proses apa yang diperlukan untuk menghasilkan output yang dibutuhkan?
Apa yang mubah sistem dapat lakukan?
Data input apa yang diperlukan?
Bagaimana data dapat diperoleh terbaik?
Bagaimana akurasi data, kelengkapan, dan ketepatan waktu dapat terjamin?

Tahap konstruksi
Data apa yang harus disimpan dalam sistem?
Bagaimana data harus diatur?
Bagaimana data dapat
Bagaimana sistem ini dapat diurai menjadi modul?
dipertahankan?
Bagaimana modul ini berhubungan satu sama lain?
Dalam urutan apa modul harus dieksekusi?
Bagaimana sistem dapat dipulihkan jika terjadi sesuatu?
Apakah audit Trail diperlukan?
Tingkat dokumentasi apa yang diperlukan?
Apa tes sistem perlu dijalankan?

Gambar 9,16pertanyaan untuk memandu pengguna pengembang

Prototyping proses pengembangan dijalankan oleh
profesional. Hal ini umum bagi pengembang pengguna
untuk meremehkan apa yang diperlukan untuk
mendefinisikan persyaratan sistem, terutama jika
pengguna lain juga akan menggunakan aplikasi. Sebuah
titik pembelajaran utama bagi kebanyakan pengembang
pengguna pertama tidak bergerak ke tahap konstruksi,
atau bangunan prototipe, terlalu cepat.
Dua Common UAD perangkap tidak melakukan
pengujian yang cukup dari aplikasi dan tidak memberikan
dokumentasi yang cukup. Kurangnya pengujian yang
memadai untuk aplikasi dukungan keputusan dapat
menyebabkan konsekuensi serius bagi bisnis. Kesalahan
dalam aplikasi spreadsheet, misalnya, diketahui telah
mengakibatkan kerugian bisnis mulai dari ratusan ribu
hingga jutaan dolar (Galletta et al., 1996), dan praktik
aplikasi mereka daripada mengandalkan sepenuhnya pada
pengujian diri.
Dokumentasi yang diperlukan untuk aplikasi
userdikembangkan tergantung pada karakteristik aplikasi.
Jika aplikasi ini digunakan oleh orang lain selain
pengembang pengguna, termasuk kemungkinan penerus
dalam peran organisasi tertentu, dokumentasi formal
harus disediakan dan tetap up-to-date; dokumentasi yang
tidak tertanam dalam aplikasi itu sendiri diperlukan dalam
hal sistem crash. Dokumentasi untuk sistem Multiuser,
atau aplikasi yang berdiri sendiri yang digunakan oleh
peop Le yang berbedadalam kelompok kerja yang
berbeda, biasanya memerlukan dokumentasi pengguna
yang relatif rinci, seperti yang dihasilkan untuk pengguna
oleh spesialis dokumentasi is. Tergantung pada konteks
organisasi, audit internal yang formal atau mekanisme

debugging yang tidak memadai dapat menjadi penyebab
utama (panko, 1996; Panko dan Halverson, 1996).
Penelitian telah menemukan bahwa banyak pengembang
spreadsheet rupanya tidak berusaha untuk mengurangi
kesalahan spreadsheet mereka secara sistematis dan tidak
memiliki pekerja lain memeriksa program mereka. Sejak
pengawasan lainnya dapatdigunakansebelum aplikasi
digunakan untuk memastikannya tidak mengekspos
organisasi untuk tingkat risiko yang tidak dapat diterima
atau untuk mematuhi hukum pelaporan keuangan.
Profesional TI juga telah belajar bahwa sistem
sederhana yang bekerja andal jauh lebih berguna daripada
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 391
kegagalan yang rumit. Ini sering merupakan ide yang baik
untuk memulai dengan versi terbatas dari sistem yang
dikembangkan pengguna dan kemudian
mengembangkannya setelah memiliki beberapa
Ringkasan
Pilihan di antara kehidupan pengembangan sistem
tradisional cycle (SDLC), prototyping, Rad, dan yang lebih
baru "tangkas" metodologi untuk mengembangkan
aplikasi yang disesuaikan pada dasarnya adalah keputusan
manajemen is. Dalam perusahaan yang memiliki mampu
mereka sendiri IS staf, pilihan metodologi mungkin
didasarkan pada faktor sepertis sejauh mana persyaratan
sistem dapat dengan mudah ditentukan dan aplikasi
fungsi, ukuran, dan kompleksitas. Pengembangan aplikasi
kustom menggunakan metodologi SDLC multilangkah,
dengan yang didefinisikan dengan baik sign-off, sekarang
cara tradisional untuk demengembangkan sistem
komputer baru dan untuk mempertahankan mereka;
masih merupakan pendekatan yang lebih disukai ketika
sistem besar, kompleks, dan melayani beberapa unit
organisasi. Sebuah Prototyping metodologi adalah
pendekatan yang lebih efektif untuk kecil, proyek
sederhana. Sebuah pendekatan prototyping juga
digunakan dalam metodologi SDLC untuk membantu
pengguna dan profesional is dimulai dengan seperangkat
persyaratan dasar dan kemudian mengembangkan satu
set lengkap persyaratan fungsional. Kombinasi
Prototyping/piloting pendekatan dalam metodologi SDLC
sangat berguna ketika sistem proyek ditandai dengan
risiko teknologi yang signifikan atau risiko organisasi, atau
keduanya, yang dapat diuji keluar awal proyek
menggunakan prototipe.
Apakah SDLC tradisional, prototyping, atau
beberapa kombinasi dari kedua digunakan, itu adalah
tanggung jawab dari kedua manajer bisnis dan spesialis is
untuk memastikan bahwa sistem yang diinstal memenuhi
kebutuhan bisnis pada saat instalasi. Spesialis IS biasanya
memegang tanggung jawab utama untuk sebagian besar
analisis sistem dan semua langkah pembangunan sistem.
Namun, proyek sistem dapat dikelola oleh Manajer IS,
manajer bisnis, atau keduanya.
Pengembangan aplikasi cepat (Rad) metodologi
telah menjadi lebih penting sebagai bisnis berusaha untuk
memberikan tinggi-qualaplikasi dalam jangka waktu yang
pengalaman dengan versi awal. Memang, sistem yang
dikembangkan pengguna juga terkadang mengarah pada
proyek sistem yang lebih kompleks yang membutuhkan
kerja pengembangan khusus oleh para profesional IS.
lebih singkat. Sebuah metodologi RAD menggabungkan
manfaat pengembangan iteratif dari Prototyping dengan
kontrol kualitas SDLC; pendekatan ini juga biasanya
bergantung pada sesi jad dan perangkat lunak otomatisasi
(kasus) alat untuk genmasyarakat kode. Dalam beberapa
tahun terakhir, ada juga sebuah gerakan untuk
mengembangkan lebih "tangkas" metode pembangunan
berdasarkan prinsip kesederhanaan dan umpan balik,
dengan tim proyek yang relatif kecil. Salah satu
karakteristik dari metode Agile yang disebut eXtreme
PRogramming adalah obsesi dengan kode pengujian awal
dan sering, dalam rangka untuk memiliki nol Cacat.
Metode lain yang disebut scrum menggunakan banyak tim
kerja dan pertemuan rutin untuk mengkoordinasikan dan
berbagi pengalaman kerja.
Bab ini mencakup beberapa panduan untuk
managing interaksi antara anggota tim proyek ketika ada
off-site (termasuk Offshore) pekerja kontrak pada sebuah
proyek. Pedoman ini Alamat mengelola harapan,
mengintegrasikan off-site staf dengan staf IS internal,
berkomunikasi sering, creating kantor manajemen proyek
terpusat, dimulai dengan proyek percontohan,
mempekerjakan ahli hukum lepas pantai, dan
mengamankan tautan komunikasi yang berlebihan.
Pengembangan aplikasi komputer oleh karyawan
bisnis yang tidak IS spesialis telah menjadi commonplace.
Meskipun ada dapat manfaat yang jelas untuk memiliki
pengguna bisnis mengembangkan aplikasi, baik bisnis dan
manajer IS harus berhati-hati mempertimbangkan
Karakteristik dari aplikasi yang akan dikembangkan,
teknologi yang akan digunakan, dan keterampilan dan
mantan perience pengguna yang tersedia pengembang
untuk memastikan bahwa manfaat tidak sebanding
dengan risiko kepada organisasi untuk aplikasi yang
dikembangkan dan dipelihara oleh spesialis non-IS.
Pengembang pengguna juga harus menggunakan
metodologi pengembangan yang sesuai untuk aplikasi
tertentu, dan konsultasi dengan profesional TI dan
personil audit harus didorong, yang sesuai.
392 Bagian III • memperoleh sistem informasi
Tinjau pertanyaan
1. Jelaskan secara singkat langkah khas dalam kehidupan
pengembangan sistem yang khas cyCle (SDLC) seperti yang
disajikan dalam bab ini.
2. Menjelaskan aktivitas utama yang dilakukan oleh
profesional IS di setiap langkah SDLC.
3. Pilih tiga Karakteristik sistem aplikasi berkualitas tinggi,
seperti yang ditunjukkan pada gambar 9,3, dan
memberikan alasan mengapa masing-masing penting.
4. Menjelaskan pentingnya dokumentasi di bawah
metodologi SDLC.
5. Jelaskan keuntungan yang berbeda dari masing-masing dari
empat strategi untuk mengimplementasikan sistem baru,
seperti yang ditunjukkan pada gambar 9,4.
6. Jelaskan secara singkat elemen kasus bisnis untukproyek
sistem formasi baru di bawah metodologi SDLC.
7. Mengapa definisi persyaratan yang akurat dan lengkap
sangat penting saat menggunakan pendekatan "Waterfall"
SDLC?
8. Jelaskan secara singkat langkah dari metodologi prototipe
murni sebagai alternatif untuk pendekatan SDLC.
Pertanyaan diskusi
1. Diskusikan mengapa menurut Anda metodologi SDLC untuk
mengembangkan sistem aplikasi diadopsi secara luas di
organisasi berbasis di AS pada awal 1990-an. Lebih lanjut,
apa yang telah berubah untuk mendorong pendekatan lain
untuk menjadi begitu populer?
2. IS manajer Departemen sering percaya bahwa mereka
bertanggung jawab untuk memastikan persyaratan sistem
didefinisikan dengan benar, tetapi dalam bab ini manajer
bisnis tanggung jawab untukpersyaratan d efining
ditekankan. Bagaimana Anda dapat mendamaikan kedua
sudut pandang ini?
3. Ada banyak kegagalan dalam pengembangan sistem
aplikasi menggunakan SDLC tradisional. Diskusikan
beberapa karakteristik dari metodologi yang dapat
berkontribusi pada tingkat kegagalan tinggi di bawah
situasi tertentu.
4. Bandingkan peran analis sistem dalam pengembangan
sistem aplikasi menggunakan SDLC dan menggunakan
pendekatan Prototyping.
5. Beberapa spesialis IS berpendapat bahwa prototipe akhir
yang biasanya miskin solusi teknis . Mengomentari
9. Kelemahan dari metodologi SDLC yang diatasi dengan
pendekatan Prototyping?
10. Jelaskan dua cara bahwa pendekatan Prototyping dapat
digunakan dalam fase definisi metodologi SDLC tradisional.
11. Mengapa teknik JAD merupakan karakteristik utama dari
metodologi RAD?
12. Jelaskan bagaimana sebuah metodologi RAD membangun
kekuatan dari kedua metodologi SDLC dan Prototyping.
13. Mengapa penggunaan kontraktor meningkatkan
kompleksitas proyek IT?
14. Menjelaskanprinsip-prinsip yang und erberbaring
Metodologi pengembangan sistem Agile.
15. Apa kondisi dan metode meningkatkan kemungkinan
bahwa lepas pantai Outsourcing dari pengembangan
sistem akan berhasil?
16. Jelaskan salah satu karakteristik aplikasi, alat, dan
pengembang yang harus dinilai saat mengevaluasi apakah
aplikasi tertentu harus dikembangkan oleh pengguna,
termasuk apa yang Anda lihat sebagai potensi risiko bisnis
yang terkait dengan masing-masing karakteristik.
17. Pilih tiga dari pertanyaan definisi pada gambar 9,16 bahwa
pengguna harus alamat pengembang dan menjelaskan
mengapa mereka bisa menjadi penting.
mengapa persepsi ini mungkin (atau mungkin tidak) akan
berlaku.
6. Diskusikan mengapa sebuah aplikasi mungkin dibangun
menggunakan Prototyping sebagai bagian dari metodologi
SDLC, bukan oleh metodologi murni prototipe saja.
7. Diskusikan peran proyek manager dalam pengembangan
in-House dari aplikasi yang disesuaikan, dan dalam situasi
apa baik is dan manajer bisnis mungkin berfungsi sebagai
coleader dari sebuah proyek.
8. dikatakan bahwa "sebuah sistem tanpa dokumentasi yang
baik tidak berharga." Memberikan dukungan untuk
Statement ini. Kemudian mengomentari bagaimana alat
canggih hari ini dapat meringankan beban dokumentasi.
9. Pada setiap tonggak dalam proyek pengembangan sistem
beberapa bentuk keputusan Go/No-Go dibuat tentang
melanjutkan proyek. Apa faktor yang harus
dipertimbangkan dalam keputusan ini?
10. Diskusikan bagaimana beberapa alat modern (misalnya,
CASE), teknik (mis., JAD), dan metodologi baru (mis.,
eXtreme Programming) membantu organisasi IS mengatasi
kerugian dari metodologi SDLC tradisional.
11. Diskusikan peran pengujian di masing-masing SDLC, Rad,
dan metodologi EXtreme Programming.
 Bab 9 • metodologi untuk pengembangan perangkat lunak kustom 393
12. Diskusikan dan kontras peran klien aplikasi dalam SDLC,
RAD, dan metodologi Agile.
13. Pemeliharaan sering merupakan fase terpanjang dari
pengembangan sistem, sebagai sistem ditingkatkan dan
tetap dengan rilis baru. Diskusikan tugas yang perlu
dilakukan sebagai versi baru dari perangkat lunak siap
untuk rilis.
Bibliografi
Beath, Cynthia M., dan Wanda J. Orlikowski. 1994. "struktur yang
kontradiksi dari Metodologi pengembangan sistem:
mendekonstruksi hubungan IS-user dalam rekayasa
informasi." Sistem informasi research 5 (Desember): 350 –
377.
Boehm, Barry. 1976. "rekayasa perangkat lunak." Transaksi IEEE
pada komputer C-25 (Desember): 1226-1241. Boehm, Barry.
1981. Software rekayasa ekonomi. Upper Saddle River, NJ:
Pearson Prentice Hall.
Bollinger, Terry B., dan Clement McGowan. 1991. "sebuah
pandangan kritis terhadap evaluasi kemampuan perangkat
lunak." Perangkat lunak IEEE (1 Juli): 25 – 46.
Cho, Juyun, YongSeog Kim, dan David Olsen. 2006. "sebuah studi
kasus pada penerapan dan efektivitas pengembangan
perangkat lunak scrum dalam misi-critiCal dan skala besar
proyek," dalam Prosiding Amerika 12 konferensi sistem
informasi (amcis-06), Acapulco, Meksiko.
Clark, Charles E., Nancy C. Cavanaugh, Carol V. Brown, dan V.
Sambamurthy. 1997. "perubahan bangunan-kemampuan
kesiapan dalam organisasi IS : wawasan dari pengalaman Bell
Atlantic." Mis kuartalan 21 (Desember): 425 – 455.
Colter, Mel A. 1984. "Pemeriksaan komparatif teknik analisis
sistem." Mis kuartalan 8 (Maret): 51 – 66.
Davis, Gordon B. 1982. "Strategi untukpenentuan persyaratan
menginformasikan." IBM Systems Journal 21:4 – 30.
Dan, Tom. 1982. mengendalikan proyek perangkat lunak. New
York: Yourdon tekan, Inc
Galletta, Dennis F., K. S. Hartzel, S. Johnson, J. Yusuf, dan S.
Rustagi. 1996. "sebuah studi eksperimental darieadsheet
presentasi dan deteksi kesalahan SPR." Proses 29 konferensi
internasional Hawaii tentang ilmu sistem: 336 – 345. Fowler,
M. 2003. "Metodologi baru." Desember. Tersedia di
http://martinfowler.com/articles/ newmetodologi. html,
diakses December 8, 2010. Gane, Chris, dan Trish Sarson.
1979. analisis sistem terstruktur: alat dan teknik. Upper
Saddle River, NJ: Pearson Prentice Hall.
Hartwick, Jon, dan Henri Barki. 1994. "mengukur partisipasi
pengguna, keterlibatan pengguna, dan sikap pengguna." Mis
kuartalan 18 (Maret): 59 – 79.
14. Diskusikan beberapa faktor yang akan mendorong sebuah
organisasi untuk melakukan outsourcing beberapa atau
semua dari pekerjaan pengembangan sistem informasi.
15. Diskusikan masalah yang unik yang timbul dengan lepas
pantai Outsourcing dari pengembangan sistem informasi.
16. Dari perspektif manajer organisasi, Diskusikan apa yang
Anda lihat sebagai beberapa trade-off utama antara
manfaat dan risiko pengembangan aplikasi pengguna .
Hoffer, Jeffrey A., Joey F. George, dan Joseph S. Valacich. 2011.
analisis dan desain sistemmodern, sungai pelana 6 Ed.
Upper, NJ: Prentice Hall.
Hoffman, Thomas. 2003. "perusahaan eksekutif mencoba cara
baru untuk menyelaraskan TI dengan unit bisnis."
Computerworld (Oktober 27): 13.
Holmström, Helena, Brian Fitzgerald, Pär J. Ågerfalk, dan EOIn O.
Conchúir. 2006. "praktik Agile mengurangi jarak dalam
pengembangan perangkat lunak global." Manajemen sistem
informasi 23, 3 (musim panas): 7 – 18.
Kannan, nari. 2007. "Agile outsourcing: persyaratan
mengumpulkan dan metodologi Agile." SourcingMag.com,
www. sourcingmag.com/content/c061002a.asp
Keen, Peter G. W. 1991. "Mengelola ekonomi informasi modal."
Membentuk future: desain bisnis melalui teknologi informasi.
Boston, MA: Harvard Business School Press.
Kendall, Kenneth E., dan Julie E. Kendall. 1999. analisis sistem dan
desain, 4th Ed. Upper Saddle River, NJ: Pearson Prentice Hall.
Klepper, Robert, dan Mary Sumner. 1990. "kontinuitas dan
perubahan dalam sistem yang dikembangkan pengguna," di
K. M. Kaiser dan J. J. Oppelland (eds.), desktop Information
Technology, Amsterdam: North-Holland, 209 – 222.
Lindstrom, Lowell, dan Ron Jeffries. 2003. "Extreme
PRogramming dan perangkat lunak yang lincah Metodologi
pengembangan." dalam Carol V. Brown dan Heikki topi (eds.),
adalah manajemen Handbook, 8th Ed. New York: Auerbach.
Oleh Martin, James. 1982. pengembangan aplikasi tanpa
pemrogram. Englewood Cliffs, NJ: Prentice Hall.
MCNurlin, Barbara C., dan Ralph H. Sprague, Jr. 2004.
Manajemen sistem informasi dalam prakteknya, sungai
Saddle 6Th Ed. Upper, NJ: Pearson Prentice Hall.
Mueller, Yohanes Paulus. 2007. "ABC: pengantar pemrograman
yang gesit." CIO, www.CIO.com/article/100501 (Maret 28).
Panko, Ralph R. 1988. Komputasi pengguna akhir: manajemen,
aplikasi, dan teknologi. New York: Wiley.
Panko, Ralph R. 1996. "Minitrack pada risiko dalam komputasi
pengguna akhir," Prosiding dari 29 haWaii konferensi
internasional tentang ilmu sistem.
Panko, Ralph R., dan R. P. Halverson, Jr. 1996. "Spreadsheet di
persidangan: sebuah survei terhadap penelitian tentang
risiko spreadsheet," Prosiding konferensi internasional
Hawaii ke-29 tentang ilmu sistem: 326 – 335.
394 Bagian III • memperoleh sistem informasi

Parker, Marilyn M., dan Robert J. Benson. 1987. "informasi

ekonomi: pengantar." Datamation 33 (Desember 1): 86 – 96.
Poria, Bharat C. 2004. "Strategis outsourcing." CIO
kebijaksanaan. Upper Saddle River, NJ: Pearson Prentice Hall.
Pyburn, Philip J. 1986 – 1987. "Mengelola penggunaan komputer
pribadi: peran sistem informasi manajemen perusahaan." Jurnal
sistem informasi manajemen 3, 3:49 – 70. Radding, Alan. 1992.
"ketika manajer non-IS mengambil kendali." Datamation 38 (Juli
1): 55 – 58.
Robey, Daniel. 1987. "implementation dan dampak organisasi
sistem informasi." Interfaces 17 (Mei – Juni): 72 – 84.
Rottman, Joseph W., dan Mary C. Lacity. 2004. "dua puluh praktik
untuk outsourcing lepas pantai." Mis triwulanan eksekutif
(September): 117 – 130.
Schultheis, Robert A., dan Mary Sumner. 1991. "hubungan risiko
aplikasi terhadap kontrol aplikasi: sebuah studi tentang
aplikasi database berbasis mikrokomputer." Komputer
personil 13, 3:50 – 59.
Perangkat lunak Serena. 2007. "Pengantar pengembangan
perangkat lunak yang gesit." Reslaporan earch (Juni).
Valacich, Joseph S., Joey F. George, dan Jeffrey A. Hoffer. 2009.
Essentials analisis sistem dan desain, 4th Ed. Upper Saddle
River, NJ: Pearson Prentice Hall.
Wailgum, Thomas. 2007. "dari sini sampai ketangkasan." CIO:
kepemimpinan teknologi bisnis (1 Juni): 43 – 50.
 Metodologi untuk paket
perangkat lunak yang dibeli
Pada kebanyakan perusahaan besar saat ini, perangkat lunak aplikasi adalah kebiasaan yang dikembangkan oleh
staf sistem informasi in-House (IS) dan Diperoleh dari sumber luar. Bahkan, tren selama lebih dari satu dekade
telah untuk organisasi menengah dan lebih besar untuk Purchase (atau sewa, sering dari penyedia layanan) paket
aplikasi daripada kustom mengembangkan solusi mereka sendiri dengan in-House is personil, setiap kali itu layak
dan biaya yang bermanfaat untuk melakukannya. Belanja modal untuk melaksanakan paket Soft ware yang dibeli
atau Disewaoleh karena itu sebagian besar dari total adalah anggaran. Tentu saja, banyak usaha kecil tidak
memiliki, atau sangat sedikit, IS profesional, jadi mereka pada dasarnya pengadaan semua perangkat lunak
mereka dari sumber luar. Dalam beberapa kasus, perangkat lunak ini bahkan tidak berjalan pada hardware in-
House tetapi lebih diakses dari layanan eksternal menggunakan telekomunikasi, sering internet. Contoh yang
sering dikutip dari jenis penyedia layanan aplikasi (ASP) — atau "perangkat lunak sebagai layanan" (SaaS) —
adalah Salesforce.com. Baru-baru ini, software disampaikan melalui internet telah dikelompokkan di bawah
istilah "komputasi awan."
Perusahaan dalam industri perangkat lunak telah tumbuh di seluruh dunia selama beberapa dekade terakhir,
sehingga perusahaan saat ini dapat memilih dari ribuan produk yang dapat dibeli atau disewakan sebagai "off-
the-Shelf" paket perangkat lunak yang akan dikerahkan di rumah atau diakses sebagai eLayanan xternal.
Perusahaan industri perangkat lunak yang bertahan menarik baru dan berpengalaman IS profesional untuk
menjadi karyawan mereka sehingga mereka dapat dengan cepat mengembangkan teknologi informasi (TI) solusi
untuk merespon kebutuhan pasar baru. Perusahaan yang membeli atau Lease paket perangkat lunak juga
biasanya perlu membeli layanan dari vendor perangkat lunak untuk membantu menginstal dan memelihara
perangkat lunak untuk bisnis mereka. Selain bekerja dengan perangkat lunak vendor atau penyedia layanan
perangkat lunak, perusahaan pembelian sistem sendirid analis bisnis bekerja pada tim proyek dengan manajer
bisnis untuk membeli dan menginstal sistem baru. Beberapa anggota tim juga biasanya merupakan bagian dari
tim dukungan yang berkelanjutan bagi pengguna bisnis setelah sistem yang dibeli atau Disewa baru telah
dikerahkan.
Paketaplikasi perangkat lunak umur sering dibangun hari ini dengan standar antarmuka Windows atau web
browser untuk pengguna akhir. Jenis antarmuka ini juga tersedia untuk besar klien/server sistem (misalnya,
perencanaan sumber daya perusahaan [ERP] dan pelanggan Relatmanajemen IONSHIP [CRM] paket
diperkenalkan di Bab 5). Beberapa sistem tingkat perusahaan ini memiliki versi khusus industri paket mereka
untuk memfasilitasi pelaksanaannya. Vendor perangkat lunak lain mengembangkan paket untuk industri tertentu
saja, such sebagai penjualan dan sistem manajemen persediaan untuk pengecer, sistem pinjaman komersial
untuk Bank, klaim-sistem pengolahan untuk perusahaan asuransi, atau penyedia layanan kesehatan. Namun,
vendor perangkat lunak tambahan menyediakan perangkat lunak, misalnya untukLisis dan peramalan anal
statistik, penulisan laporan, analisis bisnis, dan desain grafis. Dimanapun ada pasar yang cukup besar untuk paket
standar, sebuah perusahaan perangkat lunak kemungkinan akan mengembangkan aplikasi untuk menjual ke
pasar.
396 Bagian III • memperoleh informasi Sistem
Untuk perusahaan yang memilikisumber daya epartment is mereka sendiri, analisis make-atau-Buy dilakukan
dalam rangka untuk memutuskan apakah akan mendapatkan produk atau layanan dari sumber luar atau untuk
memproduksi perangkat lunak atau melakukan layanan
390
menggunakan sumber daya IS internal. Dalam bab ini, oleh
karena itu, kita mulai dengan pemahaman yang lebih baik
tentang keseluruhan bisnis dan manfaat TI yang harus
dipertimbangkan oleh organizatiketika memiliki pilihan
antara membeli aplikasi perangkat lunak dan
KEPUTUSAN MAKE-ATAU-BUY
Pilihan antara membangun aplikasi kustom dan
pembelian (atau Leasing) paket perangkat lunak-sebuah
keputusan membuat-orbuy-harus dibuat bersama oleh
manajer bisnis yang membutuhkan perangkat lunak dan is
profesional yang memiliki pengetahuan untuk menilai
manfaat dan risiko teknis. Untuk organisasi dengan
personel IS mereka sendiri terampil, tiga keuntungan yang
paling jelas dari paket perangkat lunak adalah (1) cOST
tabungan, (2) kecepatan lebih cepat dari pelaksanaan
perangkat lunak berkualitas, dan (3) staf internal yang
tersedia untuk bekerja pada aplikasi lain yang tidak dibeli.
Paket perangkat lunak biasanya biaya kurang dari solusi
kustom karena vendor perangkat lunak akan sepenugasan
paket untuk banyak organisasi. Yaitu, perusahaan yang
memperoleh perangkat lunak akan berbagi
pengembangan dan peningkatan biaya paket. Beberapa
biaya tambahan untuk kustomisasi oleh staf internal atau
konsultan biasanya diperlukan (misalnya, untuk membuat
judul laporan lokal, untuk menggunakan nama data
perusahaan khusus). Sebuah paket perangkat lunak juga
biasanya dapat diimplementasikan lebih cepat daripada
aplikasi kustom karena sudah ada; dalam lingkungan
bisnis yang cepat berubah saat ini, ini bisa menjadi
keuntungan yang sangat penting . Hal ini dapat menjadi
penting ketika staf TI dan bisnis tidak memiliki cukup
pengalaman dengan aplikasi, sehingga membuat proyek
pengembangan terutama berisiko. Sebuah paket mungkin
lebih disukai untuk mendukung inti, fungsi bisnis generik
yang organizat ion Andatidakbersaing dengan organisasi
lain yang juga bisa memperoleh teknologi yang sama.
Tentu saja, keuntungan nyata berasal dari cerdas
menggunakan paket dengan cara pesaing tidak bisa. Staf
internal kemudian dapat mengabdikan waktu mereka
untuk membuat semua aplikasiioninteroperasional dan
mengembangkan aplikasi yang memerlukan pengetahuan
lokal atau memiliki keunggulan kompetitif.
Namun, ada juga beberapa kelemahan. Salah satu
kelemahan utama dari membeli solusi aplikasi adalah
bahwa perangkat lunak paket jarang tepat sesuai dengan
kebutuhan perusahaan. Untuk organisasi yang
memperoleh paket untuk menggantikan yang lebih tua,
sistem yang dikembangkan kustom, This jenis perubahan
dapat memiliki beberapa konsekuensi penting bagi bisnis.
Paling umum, itu berarti bahwa pengguna bisnis mungkin
akan diminta untuk "menyerah" fitur perangkat lunak
kustom yang lebih tua bahwa paket tidak mendukung.
Paket mungkin dapat custodisesuaikan untuk
menambahkan fitur khas, mengembangkan aplikasi
disesuaikan. Selanjutnya kita akan menjelaskan secara
rinci proses langkah untuk memilih, mempersiapkan, dan
menerapkan paket aplikasi perangkat lunak, serta
beberapa peran tim proyek dan kunci untuk success.
tetapi kustomisasi dapat membuat upgrade paket jauh
lebih sulit sebagai rilis baru terjadi dan mungkin dibatasi
oleh apa lisensi perangkat lunak memungkinkan untuk
paket yang akan didukung oleh vendor. Pilihan lain adalah
untuk organisasi untuk mengubah proses untuk
mencocokkan mereka yang didukung oleh perangkat
lunak. Ini bisa diinginkan, meskipun menyakitkan, jika
proses organisasi yang tidak efisien atau tidak praktik
terbaik saat ini. Downside ini saja berarti bahwa organisasi
harus memiliki proses yang sangat baik di tempat thakan
membantu mereka membuat keputusan trade-off terbaik
tentang fitur perangkat lunak dan kemampuan untuk
organisasi. Seperti dijelaskan selanjutnya, hal ini
memerlukan metodologi yang akan memperhitungkan
pengetahuan tentang kemampuan paket serta informasi

busineSS dan penilaian teknis tentang seberapa baik paket
akan memenuhi kebutuhan organisasi.
Masalah lain yang berperan dalam membuat
keputusan makeor-Buy adalah kelayakan keuangan dari
vendor utama atau yang diinginkan, Apakah perangkat
lunak sesuai dengan perangkat lunak sistem yang dipilih
dari organisasi, Apakah vendor memiliki visi untuk
peningkatan paket yang kompatibel dengan masa depan
(bukan hanya saat ini) kebutuhan organisasi Anda,
keandalan vendor dalam memberikan rilis baru pada
waktu, dan total biaya kepemilikan (yaitu, mengingat
tidak hanya biaya pembelian tetapi juga jangka panjang
biaya untuk mempertahankan dan meng-upgrade
perangkat lunak-yang terutama faktor kritis untuk
mempertimbangkan dengan paket open-source, yang kita
bahas nanti dalam bab).
Pada akhirnya of bab ini kita juga sebentar
mendiskusikan pilihan pengadaan yang mencakup kontrak
dengan vendor untuk "host" (menjalankan) satu atau
lebih aplikasi (misalnya, Salesforce.com) untuk sebuah
perusahaan bisnis di bawah kontrak sewa (Lihat bagian
dari bab ini berjudul "New membeli Option: penyedia
layanan aplikasi"). Proses untuk memutuskan pada
penyedia layanan aplikasi serupa dengan proses untuk
memutuskan pada paket perangkat lunak yang dibeli,
dengan beberapa pertimbangan khusus karena koneksi
remote untuk dATA dan perangkat lunak.
METODOLOGI PEMBELIAN
Mari kita beralih sekarang ke langkah rinci dari proses
siklus hidup untuk memilih, memodifikasi, dan
menerapkan paket aplikasi perangkat lunak. Setelah
menjelaskan masing-masing langkah secara rinci, kami
kemudian secara singkat mendiskusikanperan tim Pro
Ject, cara efektif mengelola proyek sistem yang dibeli, dan
keuntungan utama dan kerugian dari pembelian sistem
paket.
Meskipun pada pandangan pertama tampaknya
relatif mudah untuk membeli perangkat lunak Kemasan,
banyak contoh dari masalah pelaksanaan sistem muncul
karena organisasi hanya tidak mengerti apa yang terlibat
dalam memperoleh dan menginstal perangkat lunak paket
yang dibeli. Deskripsi dari langkah pembelian
mengasumsikan bahwa persetujuan awal telah received
untuk sistem baru yang ukuran yang cukup untuk Merit
proses pembelian penuh. Seperti yang akan kita bahas,
pemilihan paket harus merupakan keputusan bersama
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 397
antara manajer bisnis yang dapat menilai manfaat dan
risiko organisasi dan profesional is yang dapat membantu
menilai manfaat dan risiko dari teknis dan juga
berkelanjutan mendukung perspektif.
Perhatikan bahwa fokus kami di sini adalah pada apa
yang telah disebut sebagai paket "khusus" yang
menawarkan solusi untuk masalah bisnis tertentu, bukan
sebuahSuite produktivitas PE rsonal (misalnya, Microsoft
Office). Diskusi kami juga mengasumsikan bahwa sebuah
organisasi memiliki spesialis IS sendiri. Organisasi yang
tidak memiliki spesialis is akan perlu bergantung pada
vendor atau konsultan luar, atau keduanya, untuk
menyediakan para yangSary adalah keahlian.
Langkah pembelian
Template untuk langkah proses pembelian ditunjukkan
pada gambar 10,1. Langkah untuk membeli paket aplikasi
sesuai dengan tiga fase siklus hidup diperkenalkan di Bab
8: definisi, konstruksi, dan implementation. Dalam
pengembangan sistem siklus hidup (SDLC) metodologi
yang dijelaskan dalam Bab 9, spesifikasi sistem rinci (apa
sistem yang harus dilakukan) didokumentasikan dalam
fase definisi; sistem dibangun dalam fase konstruksi; dan
sistem ini dalamterhenti, dioperasikan, dan dipelihara
dalam tahap pelaksanaan.
Karena pengembangan aplikasi yang disesuaikan
menggunakan proses SDLC secara historis datang
pertama, proses untuk pembelian paket ini disebut di sini
sebagai pendekatan SDLC dimodifikasi. Dalam fase definisi
, sebuah organisasi tidak hanya mendefinisikan kebutuhan
sistem tetapi juga kemudian menggunakan persyaratan
untuk mengidentifikasi potensi vendor dan solusi dan
kemudian mengumpulkan informasi yang cukup untuk
dapat mengevaluasi mereka. Dibandingkan dengan proses
SDLC untuk softwar kustome, fase definisi diperluas untuk
menyertakan lima langkah tambahan, dimulai dengan
membuat daftar pendek dari paket potensial.
398 Bagian III • memperoleh informasi Sistem

Karena solusi kemasan yang siap pakai telah

dirancang, dibangun, dan diuji oleh vendor, fase
konstruksi akan dikurangi secara radikal. Pengecualian di
sini

Definisi
Analisis kelayakan
Persyaratan definisi
Buat daftar pendek paket
Menetapkan kriteria evaluasi
Mengembangkan dan
Paket pilih
mendistribusikan RFP
Negosiasi kontrak

Konstruksi
Desain sistem (untuk modifikasi paket)
Sistem bangunan (untuk modifikasi paket)
Pengujian sistem

Implementasi
Instalasi
Operasi
Pemeliharaan

Gambar 10,1 fase dan tahapan pengembangan sistem siklus hidup ketika membeli sebuah paket

adalah ketika paket belum sepenuhnya dirilis dan
organisasi pembelian kontrak dengan vendor untuk
melayani sebagai situs Alpha atau situs Beta untuk
vendor perangkat lunak. Terlibat sebagai situs Alfa sering
berarti bahwa perusahaan dapat memainkan peran semut
significdalam menentukan fungsi akhir dan desain
antarmuka pengguna untuk paket baru; pada gilirannya,
ini merupakan komitmen utama untuk menyediakan
sumber daya bisnis dan is untuk bekerja sama dengan
vendor. Terlibat sebagai situs Beta biasanya berarti
signifikansit keterlibatan dalam peran tes penerimaan
pengguna untuk vendor perangkat lunak (misalnya,
dijelaskan dalam Bab 9): vendor melakukan pengujian
beta dengan organisasi yang tidak Alpha situs untuk
memonitor ketat sistem untuk potensi kesalahan dalam
pengaturan yang berbeda.
Fase implementasi mencakup langkah yang sama
seperti SDLC. Untuk sistem yang dibeli, namun, vendor
perangkat lunak mungkin sangat terlibat dalam
penginstalan. Selanjutnya, pemeliharaan paket biasanya
merupakan tugas yang dilakukan oleh vendor. Yang
negotdari ini bagian dari kontrak pembelian oleh karena
itu merupakan langkah penting.
MEMULAI proses pembelian serupa dengan keputusan untuk
investasi aplikasi disesuaikan, organisasi menggunakan
sejumlah pendekatan untuk memutuskan apakah akan
berinvestasi dalam sistem yang dibeli . Beberapa
organisasi tidak memerlukan permintaan formal rinci
untuk memulai penyelidikan kemungkinan pembelian
sistem karena ada asumsi bahwa lebih sedikit IS sumber
daya yang diperlukan. Minimal, pengelola bisnis
menyiapkan dokumen yang BrieFly menjelaskan
kebutuhan aplikasi yang diusulkan dan menguraikan
potensi manfaat yang akan diberikan aplikasi kepada
organisasi.
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 399
Sebuah perkiraan biaya tingkat tinggi untuk
pembelian yang diusulkan akan perlu dikembangkan
dengan manajer bisnis dan analis IS input. Memperkirakan
biaya sistem melibatkan lebih banyak daripada
mengidentifikasi biaya pembelian paket kandidat. Sebagai
contoh, gambar 10,2 menyediakan perbandingan
hipotetis dari biaya untuk $1.000.000 Custom-
dikembangkan sistem menggunakan sumber daya in-
House (MIdsized sistem) dengan biaya untuk memilih dan
membeli off-the-rak paket dengan keseluruhan yang sama
Fungsi. Total biaya untuk solusi yang dibeli ($650.000)
adalah sekitar dua pertiga dari total biaya membangun
sistem di rumah. Catatan, however, bahwa harga
pembelian perangkat lunak ($100.000 untuk membeli
lisensi untuk paket perangkat lunak) kurang dari
seperenam dari total biaya-karakteristik yang sering tidak
sepenuhnya diwujudkan oleh manajer bisnis yang tidak
memiliki luas pengalaman dengan PUrchasing dikemas
perangkat lunak. Lebih lanjut, dalam tahap konstruksi
biaya untuk contoh ini, ada asumsi bahwa tidak ada
modifikasi besar untuk paket yang diperlukan dan bahwa
hubungan dengan sistem lain bukan merupakan bagian
dari proyek ini.
Seperti ketika membangun sistem menggunakan
SDLC, sebuah tim proyek sistem harus dibentuk dan diberi
tanggung jawab untuk memperoleh perangkat lunak. Tim
harus menyertakan perwakilan dari unit bisnis yang akan
menerapkan sistem, analis IS, dan spesialisasi lainnya
adalahTS yang akan beroperasi dan mendukung sistem
paket dan sistem lain yang akan antarmuka dengan paket.
Beberapa peran tim tertentu akan dijelaskan kemudian
dalam bab ini.
DEFINISI fase fase definisi dimulai dengan dua langkah yang
sama seperti dalam proses SDLC. Namun, lima langkah
tambahan khusus untuk proses pembelian.
 400 Bagian III • memperoleh informasi Sistem

Biaya Biaya
Tahap Sistem bangunan Sistem pembelian
Fase definisi
Analisis kelayakan $50,000 $50,000
Persyaratan definisi 250,000 200,000
Tahap konstruksi
Desain sistem 150,000 —
Coding dan pengujian 150,000 —
Pengujian sistem 130,000 100,000
Dokumentasi dan prosedur 120,000 25,000
Tahap implementasi
Perencanaan instalasi, data
Pembersihan, dan konversi 150,000 175,000
Harga pembelian Software — 100,000
Total $1.000.000 $650,000

FIGURE 10.2 Comparison of Costs for Building Versus Purchasing a System

Analisis kelayakan serupa dengan SDLC, tujuan dari langkah ini adalah untuk
menentukan apakah sistem yang diusulkan secara ekonomi, teknis, dan operasional
layak. Ketika membeli sebuah sistem, kelayakan pembelian daripada membangun solusi
sistem juga sedang dipertimbangkan. Langkah ini akan mencakup penyelidikan
pendahuluan ketersediaan sistem kemasan yang mungkin cocok kandidat, termasuk
investigasi tingkat tinggi dari fitur perangkat lunak dan kemampuan yang disediakan
oleh vendor. Dalam langkah ini analisis biaya-manfaat yang lebih rinci dilakukan untuk
tujuan penganggaran proyek dan pemantauan.
Paket
Kemampuan fungsionalsistem kaged PAC
Persyaratan Teknis perangkat lunak harus
memenuhi
Jumlah dan kualitas dokumentasi yang diberikan

Vendor
Karakteristik bisnis vendor perusahaan
dukungan dari paket-awal
dan berkelanjutan

Gambar 10,3 kriteria kunci untuk pemilihan paket perangkat lunak

Persyaratan definisi definisi persyaratan adalah langkah
penting dalam pendekatan SDLC. The SDLC deliverable
adalah spesifikasi rinci dari apa yang harus dilakukan
sistem dalam hal input harus menerima, data itu harus
menyimpan, proses itu harus melakukan, keluaran MuSt
menghasilkan, dan persyaratan kinerja yang harus
dipenuhi. Ini harus akurat, lengkap, dan rinci karena
digunakan untuk merancang dan program sistem dan
karena menentukan kualitas sistem yang dihasilkan.
Ketika membeli sistem, langkah ini sama
pentingnya. Dalam rangka untuk memilih paket perangkat
lunak yang terbaik, satu harus terlebih dahulu memiliki
setidaknya tingkat tinggi pemahaman konseptual
persyaratan sistem. Di sini, namun, fokus adalah pada
menentukan persyaratan fungsional dari sistem untuk
gelar yang diperlukan untuk mengembangkan permintaan
proposal (RFP) dari daftar pendek vendor. Persyaratan
perlu lebih sepenuhnya dikembangkan daripada
persyaratan dasar yang digunakan untuk membangun
prototipe tetapi kurang rinci dari persyaratan yang
ditimbulkan di bawah proses SDLC ketika mereka
digunakan untuk merancang sistem yang sebenarnya.

Penelitian telah menunjukkan bahwa ketidakpastian
tentang kebutuhan organisasi adalah penghalang yang
signifikan untuk adopsi perangkat lunak yang dikemas.
Buat daftar pendek paket yang cocok dalam langkah ini
organisasi diperlukanirements digunakan untuk
menghilangkan semua kecuali beberapa yang paling
menjanjikan paket kandidat yang diidentifikasi dalam
langkah analisis kelayakan. Sebagai contoh, paket harus
dihilangkan jika mereka tidak memiliki fitur tertentu yang
diperlukan atau tidak akan bekerja denganperangkat
keras e xisting, sistem operasi dan perangkat lunak
manajemen database, atau jaringan. Penelitian lebih
lanjut tentang kemampuan vendor dapat dilakukan untuk
menghilangkan vendor karena masalah yang dialami
dengan pengguna lain dari paket, catatan yang tidak
memadai vendor atau ukuran perusahaan, atau
keprihatinan lain tentang kelangsungan hidup jangka
panjang. Konsultan independen dengan keahlian pada
jenis aplikasi tertentu atau mengkhususkan diri dalam
industri tertentu juga dapat menjadi sumber daya utama
di sini dan mungkin dapat membantu tim proyek
eliminaTe kandidat yang tidak pantas.
Menetapkan kriteria untuk seleksi dalam langkah ini baik
bisnis dan anggota tim is harus bekerja sama untuk
menentukan kriteria yang relevan tentang calon paket dan
vendor dalam rangka untuk memilih yang terbaik.
Beberapa kriteria dapat dikategorikan sebagai
persyaratan wajib, sedangkan yang lain dapat
dikategorikan sebagai fitur yang diinginkan.
Beberapa daerah di mana kriteria rinci (yaitu, di luar
biaya) harus dikembangkan ditunjukkan pada gambar
10,3. Misalnya, karakteristik bisnis vendor CoULD
termasuk item seperti berapa lama vendor telah berada di
bisnis perangkat lunak, jumlah karyawan, laporan
keuangan selama lima tahun terakhir, produk utama,
pendapatan penjualan perangkat lunak tahunan , dan
lokasi penjualan dan dukungan KAes. Kemampuan
fungsional sistem Kemasan harus mencakup tingkat di
mana paket memungkinkan untuk beberapa pilihan dan
kemudahan yang dapat disesuaikan agar sesuai dengan
kebutuhan perusahaan menggunakan parameter atau
pendekatan lain yang tidak memerlukan sistem CODing.
Persyaratan teknis yang akan dievaluasi termasuk
perangkat lunak perangkat keras dan sistem (platform
sistem) yang diperlukan untuk secara efisien menjalankan
aplikasi dan persyaratan database untuk paket, serta
kemudahan instalasidalam perusahaan tertentu
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 401
Lingkungan. Informasi ini memungkinkan seseorang untuk
mengevaluasi seberapa baik paket akan sesuai dengan
standar organisasi saat ini untuk perangkat keras,
perangkat lunak, dan jaringan. Jenis, jumlah, dan kualitas
dokumentasi yang disediakan juga harus dievaluasi,
karena kamisebagai kualitas dan jumlah dukungan vendor
yang tersedia, termasuk pelatihan, konsultasi, dan
pemeliharaan sistem.
Selain merinci kriteria evaluasi, pertimbangan harus
diberikan kepada tindakan-langkah yang akan digunakan
dalam proses evaluasi. It tidak biasa untuk mengevaluasi
paket menggunakan skala dengan angka (misalnya, 1
sampai 10) atau label kualitatif (mis., luar biasa, baik, rata,
adil, atau miskin). Jika skala dengan angka digunakan,
setiap kriteria dapat diberikan bobot yang penting,
danSkor hted weig dapat dihitung untuk setiap kategori
evaluasi untuk setiap paket. Meskipun nilai kuantitatif
mungkin bukan satu-satunya sarana untuk seleksi, mereka
membantu untuk mengukur perbedaan di antara paket
kandidat.
Mengembangkan dan mendistribusikan RFP permintaan
untuk proposal (RFP) (terkadang disebut permintaan
penawaran, atau PPw) adalah dokumen formal yang
dikirim ke vendor potensial mengundang mereka untuk
mengajukan proposal yang menjelaskan paket perangkat
lunak mereka dan bagaimana itu akan memenuhi
kebutuhan perusahaan. Dalam organisasi dengan
pengalaman selebihnyaCE pembelian perangkat lunak
sebelumnya, template untuk RFP sudah bisa
dikembangkan. Contoh daftar isi ditunjukkan pada
gambar 10,4. Namun, persyaratan spesifik yang dicari di
Bagian III dalam contoh ini akan sangat tergantung pada
jenis paket dankebutuhan bisnis tertentu.
Tim proyek menggunakan kriteria pemilihan untuk
mengembangkan RFP. RFP memberikan informasi kepada
vendor tentang tujuan dan persyaratan sistem, lingkungan
di mana sistem akan digunakan, kriteria umum That akan
digunakan untuk mengevaluasi proposal, dan kondisi
untuk mengirimkan proposal. Pertanyaan spesifik
mungkin perlu dikembangkan untuk menangkap
karakteristik kinerja sistem, apakah kode sumber
disediakan, dan apakah pembelian
organizatidiperbolehkan untuk memodifikasi paket tanpa
membatalkan garansi vendor. Selain informasi harga
untuk paket itu sendiri, biaya tambahan untuk pelatihan
dan konsultasi perlu dipastikan. RFP juga dapat digunakan
untuk menangkap informasi sejarahtentang paket, seperti
402 Bagian III • memperoleh informasi Sistem

tanggal rilis pertama, tanggal Revisi terakhir, dan daftar

perusahaan di mana paket telah diimplementasikan —
termasuk informasi kontak untuk mendapatkan data
referensi dari perusahaan tersebut.
Langkah ini berakhir ketika RFP dikirim ke daftar
pendek vendor yang memenuhi syarat.
Mengevaluasi vendor tanggapan RFP dan pilih paket pada
langkah ini, vendor RESPONS RFP dievaluasi dan tindakan
tambahan yang diambil untuk mengevaluasi calon paket
dan vendor mereka. Tujuan keseluruhan dari proses
evaluasi ini adalah untuk menentukan tingkat kejanggalan
apa pun antarakebutuhan perusahaan dan
perusahaan yangditentukan oleh persyaratan dan
sistem penimbangan serta kemampuan paket aplikasi
yang diusulkan. Evaluasi agregat (Skor) perlu dihitung
untuk setiap set kriteria dan untuk paket keseluruhan. Tim
kemudian menggunakans angka ini untuk mendiskusikan
kekuatan utama dan kelemahan dari paket kandidat. Ini
bisa berupa pengumpulan data dan analisa yang besar dan
mungkin melibatkan evaluasi independen oleh semua
anggota tim proyek. Baik IS dan anggota tim bisnis NeEd
untuk memberikan tidak hanya dengan anggota tim
proyek lain tetapi juga dengan anggota lain dari
Departemen mereka.

I. Pendahuluan Halaman
A. Struktur dan ruang lingkup RFP
B. Tujuan RFP
C. Latar belakang dan filosofi perusahaan
D. Lingkungan Hardware/Software
E. Lingkungan bisnis saat ini
Halaman
3 III. persyaratan
12
3 A. Informasi vendor
13
3 B. Dukungan/pelatihan vendor
15
4 C. Dokumentasi
5 D. Paket hardware dan sistem
17
Lingkungan perangkat lunak
21
E. Aplikasi dan database arsitektur
26
F. Penyetelan dan pengukuran
28
G. Persyaratan fungsional

II. pedoman respon vendor 6 IV. biaya

A. Pedoman 8 A. Ringkasan
33
B. Respons vendor 10 B. Nonrecurring
35
C. Proses evaluasi umum C. Berulang
37
D. Harga
39
E. Perjanjian pemeliharaan
40
F. Rilis baru
41

V. halaman tanda tangan

42

Gambar 10,4 contoh RFP tabel isi


Selain untuk mengevaluasi vendor ' tanggapan dari
proses RFP formal, dua jenis lain dari pengumpulan data
umumnya dikejar, setidaknya untuk paket kandidat
terkemuka. Pertama, demonstrasi paket terkemuka
biasanya dapat diatur. Terkadang dimungkinkan bagi
vendor untuk menyiapkan demo di tempat di organisasi
Anda; di lain waktu, lokasi lain diperlukan-baik di vendor
location atau di perusahaan lain yang telah menginstal
paket. Persyaratan rinci untuk demo perangkat lunak
harus diberikan kepada vendor untuk memastikan kondisi
yang adil untuk menunjukkan kinerja sistem, karena
waktu respon dan karakteristik lain darikinerja batang sy
dapat sangat bervariasi tergantung pada hardware dan
sistem perangkat lunak yang digunakan untuk
menjalankan paket. Contoh spesifikasi demo untuk paket
pemodelan keuangan, dan formulir untuk mengevaluasi
demo yang ditentukan, disediakan dalam angka 10.5 And
10.5 b. Selain itu, dimungkinkan untuk vendor untuk
menginstal perangkat lunak di komputer organisasi untuk
beberapa periode singkat untuk memungkinkan Test drive
aplikasi. Dengan cara ini Anda dapat menjelajahi secara
langsung beberapa fitur yang tidak ada waktu di demo
untuk menunjukkan dan yang dapat digunakan oleh staf
Anda untuk menyelidiki kemungkinan kebiasaan bahwa
staf vendor dengan cepat melewati selama demo.
Kedua, referensi dari pengguna paket perangkat
lunak di perusahaan lain biasanya diperoleh. Setiap
vendor mungkin akan diminta untuk memberikan daftar
referensi, sesuai dengan spesifikasi Anda, sebagai bagian
dari RFP. Anda mungkin meminta referensi dari organisasi
berukuran serupa, beberapa secara geografis dekat, yang
memiliki campuran pengalaman (misalnya, beberapa
hasers purc jangka panjang danbeberapa), atau dari
bisnis serupa. Anda bahkan mungkin ingin berbicara
dengan referensi yang memilih untuk tidak membeli
paket. Salah satu teknik yang sangat efektif adalah
meminta vendor untuk memberikan nama pengguna serta
IS spesialis untuk setiap organisasi pelanggan pada daftar
referensi mereka. Anggota gugus tugas kemudian dapat
membagi nama dengan, misalnya, spesialis IS
menghubungi rekan mereka di perusahaan yang sudah
menerapkan paket. Situs kunjungan ke salah satu atau
lebih dari perusahaan ini Klingont juga dimungkinkan.
dengan organisasi referensi untuk memahami bagaimana
untuk mengevaluasi pengalaman mereka. Misalnya,
referensi di mana paket itu didorong pada pengguna oleh
unit TI kemungkinan akan memberikankomentar yang
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 403
Evaluasi atas dukungan, konsultasi, dan layanan pelatihan
dari vendor juga dapat diperoleh dari sumber ini. Anda
perlu memahami situasi
Arah presentasi
Format harus mengikuti garis besar yang disediakan.
The mainfrasaya yang PC terhubung untuk
presentasi ini harus menjadi IBM berjalan di bawah
MVS. Jika MVS Anda tidak persis seperti kita (seperti
yang diuraikan dalam RFP), Anda harus memberikan
penjelasan tertulis tentang bagaimana perbedaan
(yaitu, waktu respon, warna, dll) mempengaruhi tdia
demonstrasi.
Presentasi dibatasi hingga 2 jam, termasuk 30
menit untuk pertanyaan di akhir. Anda akan
diberikan 30 menit untuk menyiapkan.
Dengan data dan formula yang disediakan,
Buatlah database relasional sehingga profit sebagai
berikutd loss (P&L) pernyataan dapat dimodelkan dan
dilaporkan.
Fiskal 2010 rencana:
Item P & L: per bulan dengan total tahun di sebelah
kanan.
Unit kontrol P & L: oleh item dengan total di sebelah
kanan. Unit bisnis P & L: oleh unit kontrol dengan
total di sebelah kanan.
Fiskal 2011 projection:
Unit bisnis P & L: oleh unit kontrol dengan total di
sebelah kanan.
Gabungan fiskal 2010 & fiskal 2011:
Kontrol perubahan unit analisis: oleh item untuk total
fiskal 2010 vs proj. 2011 fiskal.
Analisis perubahan unit bisnis: oleh unit kontrol
untuk total fiskal 2010 vs. proj. 2011 fiskal.
Menyediakan daftar hubungan database diisi
dan/atau tabel.
Memberikan contoh daftar program/model dan file
format laporan untuk setiap jenis P & L dan analisis
perubahan di atas.
Gambar 10,5 formulir untuk mengelola demonstrasi vendor.
(A) contoh persyaratan untuk demonstrasi vendor
sangat kuat daripada referensi dari organisasi di mana
paket dipilih dengan proses yang cermat, seperti yang
diuraikan dalam bagian ini.
404 Bagian III • memperoleh informasi Sistem

Berdasarkan semua sumber informasi yang

disebutkan sebelumnya, tim proyek perlu menilai
seberapa baik perusahaaninisesuai dengan kemampuan
paket yang tersedia (Lihat gambar 10,6). Ini adalah
langkah penting yang membutuhkan baik bisnis dan
keahlian teknis. Hasil langkah proses ini juga akan memiliki
konsekuensi yang luas untuk keberhasilan proyek.
Setelahperbedaan antara kemampuan paket dan
kebutuhan perusahaan diidentifikasi, tim perlu memilih
cara terbaik untuk mengatasi perbedaan ini untuk paket
kandidat teratas. Dengan asumsi bahwa perusahaan
memutuskan bahwa masih ingin untuk menyerangt di
salah satu
4. memperbarui:
1. P & LS: Kemudahan menggunakan WHat-if untuk
Penampilan membuat proyeksi baru
Kemudahan pengambilan/akses Fungsionalitas
ke pembaruan pembaruan
keamanan pengguna
2. Pemodelan: ramah?
Kemudahan penggunaan Layar presentasi
Apa-IFS Gerakan di sekitar layar
Mencari tujuan Menyimpan pembaruan
Kualitas pemodelan Bahasa
Apa-IFS tujuan-mencari Platform
pengguna yang ramah? Kompleksitas
Layar presentasi
Gerakan di sekitar layar 5. memformat ulang:
Menyimpan model/What-IFS Kemudahan memformat (dan
Bahasa waktu) pengguna yang ramah?
Platform Layar presentasi
Kompleksitas Gerakan di sekitar layar
Menyimpan model/What-IFS
3. analisa perubahan: Bahasa
Akurasi Platform
Laporkan presentasi Kompleksitas
Akurasi konsolidasi

Gambar 10,5 lanjutan (B) contoh lembar evaluasi untuk vendor demonstrasi
paket, ada tiga alternatif utama untuk memilih dari.
Seperti yang ditunjukkan di bagian bawah gambar 10,6,
perusahaan dapat mengubah prosedur sendiri agar sesuai
dengan paket, menyelidiki feasibility dan biaya
memodifikasi paket, atau menerapkan paket
"sebagaimana adanya" dan bekerja di sekitar perbedaan.

Kebutuhan Kemampuan
Perusahaan Paket
Mengiden
Perbedaan
tifikasi
Memilih
Alternatif
Memodifikasi Perubaha Hidup
Paket Prosedur
n Perbedaan
bersama
Gambar 10,6 pencocokan kebutuhan perusahaan dengan
kemampuan paket
Faktor penting ketika memilih antara alternatif ini
adalah sepenuhnya memahami pengembangan tambahan
usaha dan biaya yang akan diperlukan untuk memodifikasi
paket dalam rangka untuk menyesuaikan dengan
kebutuhan perusahaan dan mengintegrasikan ke dalam
ENVI perusahaan dengan ronment. Oleh karena itu,
alternatif ini perlu dilakukan bekerjasama dengan spesialis
IS internal dan para vendor dari paket kandidat teratas
untuk memastikan bahwa tingkat ketidaksesuaian telah
diidentifikasi secara penuh dan kelayakand saran dari
memodifikasi paket yang diberikan telah sepenuhnya
dipertimbangkan.
Jika modifikasi sistem adalah alternatif yang layak,
rencana untuk organisasi mana yang akan bertanggung
jawab untuk memprogram perubahan dan total biaya
perubahan ini akan perlu dipertimbangkan . Selanjutnya,
dampak dari memodifikasi paket perlu dievaluasi untuk
tidak hanya proyek sistem awal tetapi juga untuk
pemeliharaan dan proyek upgrade paket berikutnya.
Misalnya, banyak perusahaan yang membeli paket sistem
perusahaan omplex c yang besar saat ini, seperti sistem
ERP, disarankan untuk menghindari pemrograman ulang
bagian dari paket untuk menghindari biaya terus-menerus
memodifikasi rilis baru dari paket di masa mendatang
(Lihat bagian selanjutnya berjudul "e CAS khusus: paket
sistem Perusahaan").
Sebaliknya, banyak perusahaan pembelian telah
memutuskan untuk mengambil alternatif tengah dalam
gambar 10,6: perubahan prosedur. Artinya, mereka
memutuskan bahwa lebih baik bagi perusahaan untuk
mengubah prosedur sendiri untuk mencocokkan
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 405
carapaket Soft ware beroperasi daripada memodifikasi
paket. Sebuah perusahaan bahkan mungkin sebenarnya
menemukan bahwa asumsi prosedural dimasukkan ke
dalam paket adalah cara yang lebih baik untuk melakukan
sesuatu daripada yang ditentukan oleh perusahaan
selama langkah persyaratan definisi proses. Hal ini dapat
terjadi jika vendor perangkat lunak telah bekerja dengan
satu atau lebih organisasi terkemuka di industri yang sama
untuk mengembangkan paket perangkat lunak. Sebagai
contoh, vendor paket ERP besar saat ini mungkin telah
bekerja dengan industri Consortia untuk mengembangkan
modul di sekitar proses industryspecific, dan kemudian
vendor dapat memasarkan paket mereka sebagai memiliki
"praktik terbaik" untuk industri tertanam dalam paket
perangkat lunak mereka.
Keputusan untuk membeli sebuah sistem oleh
karena itu tidak hanya seorang commitment untuk
membeli yang terbaik dari sistem yang tersedia tetapi juga
komitmen untuk apa pun perubahan organisasi (kadang
kompromi) perlu dibuat dalam rangka untuk
melaksanakan sistem. Paket perangkat lunak adalah solusi
vendor untuk masalah yang dianggap exIST dalam
sejumlah besar perusahaan. Dalam banyak kasus, solusi
menerapkan praktik terbaik — paling tidak terbaik untuk
banyak organisasi. Dengan demikian, kemungkinan bahwa
perbedaan antara kebutuhan organisasi dan kemampuan
paket akan ada. Sebelummenyelesaikankeputusan
pembelian, tim proyek harus memastikan bahwa manajer
bisnis yang relevan mendukung keputusan untuk
membeli paket yang dipilih dan setuju bahwa mereka
akan melakukan apa pun yang diperlukan untuk
menerapkannya dengan sukses. Demikian pula, tim
proyek ShoULD memastikan bahwa para spesialis adalah
setuju bahwa sistem dapat beroperasi di lingkungan saat
ini dan bahwa mereka dapat memuaskan mendukungnya
di-rumah seperti yang diperlukan.
Negosiasi kontrak kiriman dari tahap ini adalah kontrak
hukum dengan vendor the paket perangkat lunak yang
dipilih dan rencana rinci untuk sisa hidup-langkah siklus.
Kontrak dengan vendor perangkat lunak tidak hanya
menentukan harga perangkat lunak, jumlah lisensi, dan
jadwal pembayaran tetapi juga spesifikasi
fungsional,prosedur pengujian penerimaan, jadwal proses
pengiriman, perlindungan rahasia dagang , tanggung
jawab perbaikan dan pemeliharaan, kewajiban karena
kegagalan, dokumentasi yang diperlukan, dan pilihan
untuk mengakhiri perjanjian (Gurbaxani dan Whang,
406 Bagian III • memperoleh informasi Sistem
1991). Unsur penting lain dari kontrak adalah hak
pelanggan untuk upgrade paket masa depan-termasuk
biaya, dan apakah upgrade dapat dilewati namun rilis
sebelumnya masih akan didukung oleh vendor.
Negosiasi kontrak harus merupakan bagian integral
dari proses pembelian. Ketika bekerja dengan vendor
untuk menentukan bagaimana untuk mengurangi
perbedaan antara kebutuhan perusahaan dan paket '
kemampuan, salah satu yang sebenarnya prenegotiating
kontrak dengan vendor yang dipilih.
Banyak organisasi telah begituftware membeli
spesialis yang bekerja dengan manajer proyek sistem
dalam penulisan kontrak dan negosiasi langkah. Karena
kontrak akan menjadi satu-satunya jalan jika sistem atau
vendor tidak melakukan seperti yang ditentukan,
penggunaan pengacara juga mengurangi kemungkinan
perselisihan hukum di masa depan atau hilangnya klaim
yang sah. Setelah proyek ini sedang berjalan, manajer
proyek perlu cukup akrab dengan perjanjian kontrak
untuk mengetahui apakah kebutuhan yang tak terduga
untuk layanan vendor akan kembaliquire resmi perubahan
ke vendor kontrak.
Jenis kontrak juga memiliki implikasi untuk tingkat
risiko perusahaan pembelian. Misalnya, di bawah kontrak
harga tetap, pembeli mengetahui terlebih dahulu harga
total yang akan dikeluarkan untuk produk dan layanan
vendor tertentu. Di bawah jenis biaya-reimbursement
kontrak, di mana pembeli setuju untuk membayar vendor
langsung dan biaya tidak langsung, perusahaan pembelian
mengasumsikan risiko yang jauh lebih besar.
Tahap konstruksidalam proses SDLC,
Fase konstruksi mencakup tiga langkah: desain sistem,
pembangunan sistem, dan pengujian sistem. Dengan
pembelian, sejauh mana dua langkah pertama yang
diperlukan tergantung pada Apakah paket yang dibeli
dimodifikasi, serta kompleksitas paket itu sendiri.
Penghematan yang signifikan dalam waktu dan uang
dapat terwujud jika tidak ada modifikasi besar yang
dilakukan pada kode paket. Beberapa paket, terutama
yang dijual ke pasar massal, dianggap sebagai "turnkey,"
dan mereka tidak dapat dimodifikasi. Melihat kembali
biaya Masyararisons di gambar 10,2, biaya fase konstruksi
adalah sumber utama dari total penghematan biaya dari
pembelian paket versus membangun aplikasi kustom:
bahkan ketika menambahkan dalam harga pembelian
perangkat lunak itu sendiri (ditunjukkan di bawah Tahap
implementasi),biaya untuk tahap konstruksi dari paket
pembelian kurang dari setengah sama besar dengan biaya
konstruksi untuk solusi disesuaikan. Namun, seperti yang
dinyatakan sebelumnya, contoh pada gambar 10,2
mengasumsikan bahwa tidak ada modifikasi besar untuk
paket yang requirdan bahwa hubungan dengan sistem lain
bukan merupakan bagian dari proyek ini. Perbedaan
$350.000 dalam biaya total antara biaya bangunan dan
biaya pembelian sistem tertentu ini dapat dengan cepat
lenyap jika asumsi tidak ada sistem Modifikasi tidak
berlaku.
Jika tidak ada modifikasi pada sistem yang akan
dibuat, perusahaan dapat pindah ke langkah pengujian
sistem setelah kontrak pembelian ditandatangani. Banyak
off-the-rak paket untuk fungsi tunggal, seperti aplikasi
akuntansi, sering tidak dimodifikasi karena praktek bisnis
yang mereka dukung cukup standar dan vendor tidak
mengembangkan paket dengan modifikasi dalam pikiran
(rockart dan Hofman, 1992). Sistem kemasan biasanya
telah diuji beta di perusahaan di industri target sebelum
dijual di pasar terbuka. Terlepas dari kenyataan bahwa
paket tersebut mungkin telah diuji secara menyeluruh dan
sudah digunakan di organisasi lain, pengujian penerimaan
pengguna masih perlu dilakukan untuk memastikan
bahwa sistem bekerja dengan benar dengan baikterhadap
data perusahaan dan pada yang sudah ada sebelumnya
atau yang baru perangkat keras yang terinstal. Ini bisa
membutuhkan waktu dan usaha yang signifikan karena
organisasi pembelian tidak terbiasa dengan desain rinci
sistem. Vendor menyediakan dokumentasi pengguna bagi
mereka yang akan menggunakan sistem dan dokumentasi
sistem teknis bagi mereka yang menginstal sistem dan
mengoperasikannya. Namun, prosedur baru untuk
pengguna bisnis sistem mungkin perlu dikembangkan agar
sesuai dengan organisasi pembelian.
Jika paket dimodifikasi, adae mungkin beberapa
pilihan untuk mempertimbangkan bagaimana untuk
mencapai perubahan: kontrak dengan vendor, kontrak
dengan pihak ketiga, atau memodifikasi perangkat lunak
dengan in-House Resources. Banyak vendor secara rutin
melakukan kontrak untuk melakukan modifikasi yang
diinginkan. Jika vendor akan memberikan hanya kode
bahasa mesin untuk aplikasi-bukan kode sumber di mana
program ini ditulis-satu-satunya alternatif mungkin
kontrak dengan vendor untuk membuat modifikasi.
Jika vendor atau pemasok lain di luar membuat
modifikasi, pembeli juga perlu untuk menguji mereka.
Pengujian penerimaan pengguna sangat penting dan
biasanya memerlukan waktu dan upaya yang signifikan

oleh pengguna bisnis. Revisi pengguna dan dokumentasi
sistem juga perlu ditinjau ulang. JikaChaser pur
memodifikasi paket, sistem desain dan membangun
kegiatan dalam metodologi SDLC kemungkinan akan
diikuti, mirip dengan cara langkah-langkah ini akan untuk
pembangunan kustom tradisional. Karena staf IS harus
mencurahkan upaya substansial untuk understanDing
rincian desain paket perangkat lunak dan struktur untuk
memodifikasinya, hal ini tidak biasa untuk perkiraan awal
waktu dan biaya untuk langkah ini tidak mencukupi.
Lingkup proyek mungkin juga termasuk modifikasi
yang adasistem perusahaan ing untuk antarmuka mereka
dengan paket baru. Membuat program antarmuka ini bisa
sulit dan mahal, dan pengujian integrasi biasanya
memakan waktu. Menurut Keen (1991), total biaya
modifikasi sistem dapat be sulit untuk memprediksi dan
total biaya siklus hidup untuk sistem yang dibeli dapat
sampai tujuh kali lebih besar dari perkiraan asli.
Diskusi sebelumnya difokuskan pada modifikasi aktual
terhadap fungsi atau arsitektur dari paket yang dibeli
(misalnya, mengubah cara inventaris dihargai dalam
paket akuntansi atau mengubah perangkat lunak untuk
bekerja dengan manajemen database tertentu sistem
ini). Sebaliknya, beberapa modifikasi dan perangkat
tambahan tidak begitu signifikan. Sebagian besar paket
yang dibeli memiliki rutinitas That memungkinkan
penyesuaian tertentu (misalnya, termasuk nama
perusahaan Anda dan logo pada laporan dan faktur, atau
menyesuaikan tata letak laporan standar). Selain itu,
paket mungkin termasuk alat untuk memungkinkan
organisasi pembelian untuk membangun laporan
tambahan, layar screens, atau ekstrak data (yang terakhir
untuk membantu dalam berinteraksi sistem yang dibeli
dengan yang lain "hilir" sistem). Perubahan ini tidak
mempengaruhi arsitektur yang mendasari atau kode dari
perangkat lunak yang dibeli dan cenderung lebih mudah
untuk mempertahankan sebagai Ver barudari sistem
yang dibeli dilepaskan.
PELAKSANAAN fase tahap pelaksanaan SDLC melibatkan
instalasi, operasi, dan pemeliharaan. Seperti yang terlihat
pada gambar 10,1, ini semua adalah kegiatan utama
dalam siklus hidup pembelian.
Instalasi tahap instalasi SDLC melibatkan perencanaan
instalasi, TRaining, data cleanup, dan konversi. Instalasi
sistem paket juga mencakup semua kegiatan ini. Faktor
kunci dalam instalasi sukses sistem paket adalah kualitas
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 407
dukungan vendor selama langkah ini (Lucas et al., 1988).
Ukuran dan kompleksitas packa GE juga dapat sangat
mempengaruhi rencana instalasi. Misalnya, paket sistem
ERP yang besar dapat memerlukan beberapa tahun kerja
oleh spesialis in-House IS serta konsultan luar untuk
mempersiapkan instalasi awal dari sistem inte parut ini.
Hal ini karena tidak hanya melakukan sistem ini termasuk
banyak pilihan opsional yang untuk mengkonfigurasi
sistem agar sesuai dengan organisasi tetapi juga karena
sistem ERP biasanya memerlukan perubahan yang
signifikan dalam sehari-hari proses bisnis. Sebagai resULT,
biaya untuk perencanaan instalasi, pembersihan data, dan
upaya konversi untuk menginstal paket tersebut melebihi
mereka untuk usaha aplikasi kustom (lihat gambar 10,2).
Dalam organisasi besar, terutama mereka yang memiliki
berbagai jenis unit usaha didaerahsewa geografis, juga
sering diperlukan untuk melaksanakan paket secara
bertahap, yang juga dapat meningkatkan biaya proyek.
Perhatian khusus juga perlu diberikan pada
kebutuhan pelatihan untuk sistem yang dibeli sebagai
bagian dari kegiatan pelaksanaannya. Tergantung pada
sejauh mana sistem baru akan memerlukan perubahan
signifikan dalam bagaimana karyawan saat ini melakukan
pekerjaan mereka, proyek mungkin memerlukan investasi
besar dalam mempersiapkan pengguna untuk sistem
baru, termasuk in-House atau pelatihan yang dipimpin
Penjual PR ograms. Manajer bisnis dan pengguna
perwakilan harus aktif terlibat dalam kegiatan ini dan
berkomitmen untuk mencurahkan waktu yang diperlukan
untuk mengantisipasi dan menyelesaikan masalah yang
timbul.
Untuk membantu organisasi yang akan membuat
perubahan yang signifikan dalamhal e cara orang
melakukan pekerjaan mereka, banyak perusahaan
konsultan telah mengembangkan keahlian dalam apa
yang disebut sebagai "perubahan manajemen." Beberapa
kegiatan manajemen perubahan secara khusus dirancang
untuk membantu mengatasi perlawanan oleh pengguna
bisnis untuk sistem baru yang diimplementasikan. Untuk
proyek yang menerapkan sistem perusahaan yang
kompleks, misalnya, anggaran sistem untuk aktivitas
manajemen perubahan dapat lebih besar daripada biaya
yang diangguakan untuk pembelian perangkat lunak awal.
(Lihat bagian berjudul "mengelola bisnis Perubahan
"dalam bab 11.)
Operasi yang sedang berjalan tugas untuk aplikasi baru
yang sama apakah perusahaan membeli sistem atau
408 Bagian III • memperoleh informasi Sistem
membangun menggunakan SDLC. Namun, kunci
keberhasilan di masa awal operasi untuk sistem Kemasan
baru adalah jalur komunikasi yang baik dengan vendor
agar dapat dengan cepat menyelesaikan masalah.
Kesuksesan jangka panjang tergantung pada tingkatan
dimana organisasi telah berhasil mengintegrasikan sistem
ke dalam operasi perusahaan yang sedang berlangsung.
Pemeliharaan seperti dijelaskan otoritasously, itu adalah
umum bagi vendor untuk melakukan pemeliharaan paket,
dan ini perlu ditentukan dalam kontrak pembelian
perangkat lunak. Sebuah kontrak welldesigned dapat
menyebabkan penghindaran biaya yang cukup besar
untuk sebuah perusahaan selama kehidupan sistem.
Potensi downside, bagaimanapernah, adalah bahwa
perusahaan pembelian menjadi sepenuhnya tergantung
pada vendor untuk perubahan sistem masa depan. (Hal ini
terutama berlaku untuk apa yang disebut perangkat lunak
proprietary-tapi, seperti yang kita bahas di bagian
berikutnya, perangkat lunak open-source dibangun pada
p yang berbeda urchasingmaintenance model bisnis).
Karena vendor harus menyeimbangkan keinginan dan
kebutuhan semua organisasi yang menggunakan sistem,
perusahaan pembelian mungkin tidak mendapatkan
semua perubahan yang diinginkannya, dan bahkan
mungkin harus menerima beberapa perubahan yang tidak
diinginkan. Skenario terburuk di sini adalah sebagai
berikut: (1) sistem yang dibeli memiliki masa manfaat yang
lebih pendek secara signifikan daripada yang dimaksudkan
sebelumnya, sehingga biaya sistem dapat melebihi
manfaat yang diharapkan untuk perusahaan yang
membeli perangkat lunak, atau (2) VenDor keluar dari
bisnis sebelum perusahaan mencapai pengembalian yang
diharapkan pada paket investasi perangkat lunak.
Jika paket asli telah dimodifikasi, penginstalan versi
baru vendor paket mungkin bukan solusi optimal untuk
organisasi purchasing. Dengan bantuan vendor,
perusahaan perlu membandingkan fungsi versi baru dari
paket dengan versi modifikasi saat ini dan kemudian
memutuskan cara terbaik untuk mengatasi perbedaan ini.
Pilihannya miripdengan yangdihown pada gambar 10,6,
kecuali pilihan "tidak melakukan apa-apa", yang berarti
bahwa organisasi mungkin dibiarkan mengoperasikan
versi paket yang vendor mungkin atau mungkin tidak terus
mendukung. Jika organisasi memodifikasi paket asli di
rumah atau BuILT antarmuka yang luas untuk versi paket
sebelumnya, pelaksanaan versi baru dari paket ini juga
dapat mengakibatkan biaya pemeliharaan yang cukup
untuk organisasi.
Dalam kasus paket sistem ERP besar, organisasi
pembelian perlus untuk mengantisipasi bahwa rilis baru
dari perangkat lunak mungkin relatif sering, dan vendor
mungkin terus mendukung rilis paket sebelumnya hanya
untuk jangka waktu tertentu. Ketika menerapkan
peningkatan sistem yang mencakup fungsi baru yang
signifikan, perusahaan harus memutuskan apakah akan
terlebih dahulu mengimplementasikan versi baru dari
sistem dan kemudian memulai proyek untuk membuat
lebih baik penggunaan kemampuan bisnis yang didukung
oleh rilis baru atau apakah untuk mengimplementasikan
kemampuan bisnis baru sebagai bagian osistem
peningkatan proyek.
Tim proyek pembelian paket
Dengan berhasil menerapkan aplikasi kemasan biasanya
memerlukan komitmen besar pada bagian dari manajer
bisnis dan pengguna karena perubahan yang luas dalam
proses bisnis dan prosedur yang diperlukan untuk
menerapkan secara efektif yang dibeli Perangkat lunak.
Akibatnya, tidak jarang bagi manajer bisnis untuk diminta
untuk mengambil peran manajer proyek untuk proyek
sistem aplikasi Kemasan. Namun, karena keahlian IS masih
diperlukan dalam rangka untuk mengelola aspek teknis
pelaksanaan paket, manajer IS juga perlu memainkan
peran kepemimpinan proyek. Seperti disebutkan
sebelumnya, isasi organ kecilyang tidak ada adalah
spesialis harus bergantung pada vendor perangkat lunak
atau konsultan luar, atau keduanya, untuk menyediakan
keahlian is yang diperlukan.
Vendor perangkat lunak awalnya menyediakan
informasi tentang kemampuan paket dalam menanggapi
RFP. Venddari paket terkemuka mungkin kemudian
diminta untuk memberikan demonstrasi dan
berkonsultasi dengan pembeli tentang sistem potensial
modifikasi atau antarmuka baru untuk sistem yang lebih
tua. Perusahaan vendor mungkin juga dikontrak untuk
melakukan modifikasi ke PAckage sebelum pelaksanaan
untuk mengurangi mismatches antara sistem paket
kemampuan dan kebutuhan organisasi setelah penilaian
yang cermat dari manfaat dan risiko untuk melakukannya.
Vendor juga dapat memainkan peran utama dalam sistem
installation, serta memberikan dukungan pemeliharaan
berkelanjutan untuk organisasi pembelian. Dalam kasus
paket sistem perusahaan besar, juga umum bagi

perusahaan untuk kontrak dengan perusahaan konsultan
(yang mungkin telah disertifikasi oleh perangkat lunak
vendor) sebagai mitra implementasi pihak ketiga pada
proyek.
Karena ketergantungan awal dan berkelanjutan
pada vendor perangkat lunak, pembelian spesialis
(spesialis kontrak) dalam perusahaan pembelian juga
dapat menjadi penting untuk keberhasilanimplementasi
sistem d paket, apakah mereka adalah anggota resmi tim
proyek. Misalnya, jika RFP dikirim ke vendor, spesialis
pembelian akan membantu mempersiapkan atau
setidaknya meninjau dokumen RFP sebelum
didistribusikan ke vendor. Perusahaan dengan PRIOR
pengalaman pembelian perangkat lunak mungkin telah
mengembangkan bagian boilerplate untuk disesuaikan
dengan jenis pembelian. Spesialis pembelian juga terampil
dalam menegosiasikan kontrak yang menyediakan
tindakan kontinjensi yang dapat mengurangi risiko
finansial dan lainnyauntuk perusahaan pembelian.
Misalnya, banyak kontrak saat ini termasuk perjanjian
khusus tentang tingkat layanan selama periode instalasi
(Lihat bagian yang berjudul "perjanjian tingkat layanan"
dalam Bab 13).
Seperti dijelaskan NDE sebelumnyaadalah negosiasi-
langkah kontrak, pengacara (yang mungkin juga membeli
spesialis) harus mengawasi penulisan dan persetujuan
dari kontrak eksternal dengan vendor perangkat lunak.
Semua perjanjian lisensi yang terkait juga harus ditinjau
dalam rangka untuk meminimalkanbiaya ssociated dan
risiko untuk bisnis.
Mengelola proyek sistem yang dibeli
Proyek sistem yang dibeli berhasil bila organisasi telah
memilih produk, dan vendor, yang mampu memenuhi
perusahaan saat ini dan kebutuhan sistem masa depan. Ini
kembaliquires tim proyek yang efektif dengan anggota
yang memiliki bisnis dan keterampilan teknis dan
pengetahuan yang dibutuhkan, termasuk keterampilan
dan pengetahuan yang dibutuhkan untuk peran tim
proyek yang dijelaskan sebelumnya. Tidak seperti proses
SDLC tradisional di mana fase panjang Construction buffer
fase definisi dari fase implementasi, pembelian paket
perangkat lunak mungkin memerlukan pengeluaran
modal besar oleh perusahaan hanya dalam beberapa
bulan (kecuali persyaratan lain yang dinegosiasikan
dengan vendor). Manajer yang tepat bdarmawisata,
pengguna akhir, dan spesialis perlu menjadi bagian dari
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 409
tim proyek untuk memastikan bahwa paket terbaik dibeli
dari vendor terbaik dan bahwa baik risiko teknis dan bisnis
telah dipertimbangkan secara memadai.
Masalah khas dengan managing siklus hidup dari
proyek sistem yang dibeli adalah memastikan bahwa
perhatian yang memadai diberikan kepada langkah dalam
tahap definisi awal. Kesalahan umum adalah bahwa
manajer bisnis belajar tentang solusi dikemas tertentu
dari perusahaan lain atau penjualansperson di konferensi
industri dan mereka mulai bernegosiasi dengan vendor
tanpa perhatian yang memadai terhadap persyaratan
fungsional langkah definisi. Tim proyek yang tidak
melakukan pekerjaan dengan baik yang mengidentifikasi
kebutuhan mereka tidak akan dapat melakukan pekerjaan
dengan baik menilai perbedaan antara kebutuhan
perusahaan dan kemampuan paket kandidat. Hal ini
meningkatkan risiko investasi jangka pendek dan jangka
panjang, karena kontrak dengan vendor eksternal tidak
semudah berubah sebagai sebuah perjanjian proyek
menjadipengguna tween dan internal is pengembang.
Oleh karena itu penting bahwa fase definisi dapat
dilakukan dengan baik.
Untuk anggota tim proyek dari sisi bisnis yang juga
memiliki tanggung jawab pelaksanaan, juga penting
bahwa mereka menjadi representative manajer bisnis dan
pengguna. Langkah harus diambil untuk memastikan
bahwa mereka berkomitmen untuk tujuan proyek di awal,
termasuk jadwal waktu dan anggaran.
Keberhasilan fase implementasi juga tergantung
pada seberapa baik fase definisi adalah PErformed,
karena ini adalah di mana anggota tim dinilai perubahan
organisasi yang diperlukan untuk berhasil menerapkan
sistem yang dibeli. Seperti yang telah dibahas
sebelumnya, pengguna sistem paket mungkin diminta
untuk membuat perubahan signifikan dalam cara mereka
melakukan JoBS untuk menyesuaikan dengan fitur paket.
Hal ini membutuhkan langkah instalasi yang direncanakan
dengan baik di bawah kepemimpinan manajer bisnis yang
berkomitmen yang sangat berpengetahuan tentang
perubahan yang diperlukan.
Selain itu, proyek sistem yang dibeli
memperkenalkan beberapa jenis risiko baru. Pertama,
keberhasilan proyek sangat tergantung pada kinerja pihak
ketiga. Kualitas sistem yang diimplementasikan akan
bergantung tidak hanya pada kemampuan perangkat
lunak vendor yangbinaan tetapi juga pada seberapa baik
organisasi pelaksana memahami kemampuan paket dan
pada pelatihan dan instalasi vendor Kemampuan. Seperti
410 Bagian III • memperoleh informasi Sistem
yang dibahas sebelumnya, aspek kunci dari proses seleksi
vendor adalah akurat sebagaisessment dari kemampuan
vendor, bukan hanya evaluasi dari paket perangkat lunak
saat ini.
Keberhasilan proyek awal, serta efektivitas jangka
panjang dari sistem yang diinstal, juga sangat tergantung
pada proses negosiasi kontrak. Dalam kebanyakan sistem
situasi, pelaksanaan tidak hanya melibatkan "memutar
kunci." Vendor keahlian mungkin diperlukan untuk
menginstal paket, membangun antarmuka untuk sistem
yang ada, dan mungkin memodifikasi paket sendiri untuk
lebih cocok pembelian orgkebutuhan anization.
Ekspektasi layanan antara pembeli dan vendor perlu
menjadi bagian dari kontrak yang dikembangkan pada
akhir fase definisi. Kontrak akan menjadi satu-satunya
jalan bagi pembeli jika modifikasi sistem, pelatihan
vendor, atau pelaksanaan paket tidak berjalan dengan
baik.
PEMBELIAN sistem kecil diskusi dalam bab ini telah
difokuskan pada proses pembelian untuk besar, sistem
yang kompleks. Jika yang lebih kecil, sistem sederhana
sedang dipertimbangkan, waktu dan upaya dimasukkan
ke dalam proses the dapat, tentu saja, akan diskalakan
kembali. Namun, sebuah sistem kecil masih dapat menjadi
investasi besar untuk bisnis kecil. Sayangnya, banyak
usaha kecil memiliki pengalaman terbatas dengan dan
pengetahuan tentang mengevaluasi dan menginstal
sistem tersebut. Layanan dari vendor perangkat keras,
pemasok perangkat lunak lokal, serta konsultan eksternal
karena itu mungkin diperlukan.
Pembelian keuntungan
• Mengurangi waktu untuk
mengimplementasikan
• Biaya akuisisi keseluruhan yang
lebih rendah
• Berkurangnya kebutuhan untuk
sumber daya IS internal
• Kualitas aplikasi tinggi (Debugged
dan praktik terbaik)
• Infus keahlian eksternal (IS, bisnis)
Pembelian kerugian
• Risiko karena kurangnya
pengetahuan paket • risiko karena luasnya
perubahan organisasi yang diperlukan
• Awal dan berkelanjutan
Dependance pada vendor
Gambar 10,7 keuntungan dan kerugian paket pembelian
perangkat lunak
Pembelian keuntungan dan kerugian
Gambar 10,7 meringkas keuntungan dan kerugian dari
sistem pembelian Kemasan, serta beberapa potensi
jangka panjang keuntungan dan kerugian untuk membeli
solusi perangkat lunak dikemas.
KEUNTUNGAN proyek utama keuntungan adalah bahwa,
dibandingkan denganpengembangan aplikasi c
ustomized, lebih sedikit waktu yang diperlukan untuk
mengimplementasikan sistem. Namun demikian, untuk
sistem menengah, seluruh proses akan tetap memerlukan
beberapa bulan, dan untuk skala besar implementasi
perangkat lunak perusahaan (dengan paket seperti ERP
sysTems), proses dapat memakan waktu beberapa tahun
untuk menerapkan cukup modul perangkat lunak untuk
mencapai keuntungan bersih.
Keuntungan utama kedua adalah bahwa
implementasi perangkat lunak dikemas dapat sangat
menarik dari sudut pandang ekonomi. Misalnya, bisnis
kecildapat memperoleh sistem akuntansi yang lengkap
kurang dari $25.000, yang sangat rendah dibandingkan
dengan biaya pengembangan aplikasi disesuaikan yang
sebanding. Dengan asumsi bahwa vendor memiliki lebih
dari 10.000 instalasi paket kecil ini ($250.000.000
pendapatan), vendor akan memiliki insentif untuk
menghabiskan jutaan dolar untuk meningkatkan paket
dalam rangka untuk mengeluarkan rilis baru. Setiap orang
keluar pemenang karena setiap pembeli memiliki biaya
penghindaran dari membeli paket, dan vendor membuat
large-cukup keuntungan untuk tinggal di bisnis dan
memberikan upgrade dan layanan dukungan lainnya
secara berkelanjutan. Seperti yang ditunjukkan pada
gambar 10,2, harga pembelian awal paket perangkat
lunak mungkin sebagian kecil dari total biaya perolehan
dan Instapenugasan paket perangkat lunak.
Keuntungan sementara ketiga adalah sumber daya
in-House IS dapat dibebaskan untuk mengembangkan
aplikasi Mission-Critical yang dapat memberikan
keunggulan kompetitif bagi perusahaan jika paket
perangkat lunak dapat diimplementasikan untuk proses
yang relatif umum yang tidak memberikan keuntungan
strategis tertentu.
Dua keuntungan jangka panjang potensial adalah
kualitas aplikasi dan infus keahlian eksternal. Kualitas

paket perangkat lunak mungkin jauh lebih baik daripada
sistem kustom, karenae vendor mampu untuk
menghabiskan lebih banyak waktu dan usaha
mengembangkan sistem daripada perusahaan individu.
Selain itu, paket dapat mencakup praktik terbaik atau
pilihan praktik terbaik untuk situasi yang berbeda.
Dokumentasi bisa jauh lebih baik daripadadokumentasi
in-House yang bersifat typ iCal, dan rilis baru paket
mungkin menggabungkan perbaikan yang
direkomendasikan oleh perusahaan yang menggunakan
sistem. Selanjutnya, setiap rilis biasanya secara
menyeluruh diuji, termasuk tes beta dalam organisasi
klien.
Akhirnya, solusi kemasan adalah cara cepat untuk
menanamkan keahlian baru — baik keahlian TI maupun
keahlian bisnis — ke dalam organisasi. Mengingat
kecepatan perubahan teknologi, kebanyakan organisasi
saat ini merasa sulit untuk melatih dan mempertahankan
IS personil dengan expertise di baru, teknologi baru.
Vendor perangkat lunak sering memiliki dana dan motivasi
untuk mengembangkan sistem menggunakan teknologi
yang lebih baru. Solusi kemasan untuk industri tertentu,
atau sistem ERP besar, juga sering memiliki proses terbaik
di kelasnya danlain yang tertanam dalam perangkat lunak.
Dengan membeli perangkat lunak, perusahaan juga dapat
mengadopsi proses bisnis yang lebih baik.
KEKURANGAN dua risiko proyek utama juga terkait dengan
pelaksanaan paket yang dibeli. Salah satu risiko adalah
kurangnya paket pengetahuan. Pelaksanaan package
dapat memerlukan pelatihan yang signifikan untuk is serta
personil Bisnis, yang meningkatkan biaya pelaksanaan.
Karena organisasi relatif pahaman dengan paket
perangkat lunak, organisasi mungkin juga tidak akan
sebagai quick untuk meningkatkan kemampuan paket
seperti itu akan memanfaatkan kemampuan sistem yang
anggota organisasi telah dirancang dan kustom
dikembangkan. Beberapa organisasi juga membuat
kesalahan pada awalnya memodifikasi paket, atau
menambahkan fungsi lain, hanya untuk mempelajari
kemudian bahwa paket bisa menyediakan fungsi yang
sama jika telah diimplementasikan secara berbeda.
Risiko proyek lain yang terkait adalah bahwa karena
menerapkan sistem paket sering memerlukan perubahan
bisnis yang signifikan procESS, ada risiko proyek yang lebih
besar. Berpengetahuan manajer bisnis dan TERAMPIL is
spesialis perlu secara signifikan terlibat dalam fase definisi
untuk memahami apa perubahan organisasi perlu dibuat.
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 411
Selain itu, sering ada resistensi yang lebih user karena
tingkat perubahan yang diperlukan dalam rangka untuk
melaksanakan solusi dikemas.
Kerugian jangka panjang adalah bahwa organisasi
menjadi tergantung pada penyedia TI eksternal tidak
hanya untuk instalasi awal dan mungkin beberapa e
modifikasi kadotetapi juga untuk pemeliharaan yang
berkelanjutan dari paket. Meskipun dalam banyak kasus
hal ini dapat mengakibatkan aliansi strategis nilai untuk
kedua vendor dan pembeli, pembeli mungkin tidak
sepenuhnya mengantisipasi biaya koordinasi terkait
dengan managing hubungan vendor. Selain itu, tentu saja,
ada risiko bahwa vendor akan pergi keluar dari bisnis atau
menjadi tidak responsif terhadap kebutuhan perusahaan
pembelian. Ada juga dapat harga bahaya jika vendor
membuat sulit bagi pihak ketiga untuk bersaing untuk
layanan dukungan.
KASUS KHUSUS: PAKET SISTEM ENTERPRISE
Pada akhir 1990-an, mayoritas perusahaan Fortune
berbasis 500 dan lebih dari seperempat dari organisasi
menengah berbasis Eropa telah berinvestasi dalam
gelombang pertama paket sistem perusahaan:
Perencanaan sumber daya perusahaan (ERP) Sistem.
Sebagian besar perusahaan membeli sistem ini untuk
mencapai keuntungan bisnis (misalnya, pengurangan
biaya, proses bisnis yang lebih efisien, dan kepatuhan yang
lebih cepat dengan persyaratan hukum), tetapi ERP
INVestments juga merupakan investasi platform TI (Lihat
diskusi dari vendor utama dan manfaat ERP dalam Bab 5).
Salah satu manfaat bisnis utama yang terkait dengan
sistem ERP adalah untuk memungkinkan akses ke
repositori tunggal data yang terintegrasi, kadang data
real-TIme, untuk pengambilan keputusan manajemen
yang lebih baik. Hal ini dicapai dengan mendapatkan
sebagian besar aplikasi bisnis pada platform yang umum,
sistem ERP. Karena sebagian besar sistem ERP dibangun
untuk mendukung proses bisnis lintas-fungsional, akan
ada sistem yang lebih sedikit interfaces untuk
mempertahankan. Selanjutnya, modul ERP yang dapat
"dikonfigurasi" untuk digunakan oleh berbagai jenis
perusahaan di industri yang berbeda memungkinkan
perusahaan yang telah melakukan proyek untuk
reengineer proses bisnis mereka untuk sekarang
menerapkannya; silvereneng sistem kustom untuk
mendukung proses Cross-fungsional baru akan
412 Bagian III • memperoleh informasi Sistem
membutuhkan investasi sistem yang jauh lebih besar
selama waktu yang lebih lama. Namun, sistem ERP bukan
merupakan sistem informasi total untuk sebuah
organisasi; Sebaliknya, sebuah sistem ERP itu sendiri
hanya akan bertemu ROU70 persen dari kebutuhan
organisasi (Markus, 2000). Dengan demikian, penting
dalam memilih sistem ERP untuk mempertimbangkan
bagaimana sistem akan antarmuka dengan sistem
operasional yang ada dengan yang harus berbagi data.
Antarmuka tersebut mungkin tidak sepele karena
platform perangkat lunak Legacy aplikasi dapat sangat
berbeda dari platform untuk sistem ERP lebih modern.
Mengadopsi sistem ERP adalah usaha besar untuk
setiap organisasi, dan ada potensi risiko dan biaya (Lihat
fub et al., 2007). Sistem ERP sangat mahal untuk membeli,
ditambah kemungkinan akan biaya konsultasi yang
signifikan untuk membantu dalam konfigurasi dan
instalasi. Seperti paket apapun, tetapi lebih karena sifat
komprehensif ERP, paket membatasi sebuah organisasi
untuk kemampuan paket tertentu. Paket ERP dapat
menetapkan standar untuk platform untuk semua sistem
yang akan antarmuka dengan itu. Juga, sebuah organisasi
menjadi sangat tergantung pada satu vendor untuk porsi
yang cukup besar dari aplikasi bisnis intilications. Tugas
menyebarkan paket ERP, yang mencakup mematikan
aplikasi Legacy dalam organisasi, adalah kompleks dan
dapat berbahaya untuk melanjutkan operasi. Ini semua
adalah risiko dan biaya penting, maka, keputusan untuk
memperoleh sebuah ERP PAckage dan bagaimana
mengelola penyebaran yang kritis.
Untuk Departemen is dalam perusahaan yang
membeli paket ERP, ini juga bisa menjadi pertama kalinya
bahwa personil tim proyek mereka akan diminta untuk
mengkonfigurasi paket dengan cara terbaik mungkin,
penyakr daripada kustom mengembangkan aplikasi
berdasarkan persyaratan pengguna bisnis mereka. IS dan
personil tim proyek lainnya, serta pengguna bisnis, harus
dikirim ke kelas pelatihan, biasanya dilakukan oleh vendor
perangkat lunak, sehingga mereka dapat mempelajari
perangkat lunak yang dikemas serta mempelajari bahasa
khusus vendor baru untuk menulis antarmuka dan
pertanyaan. Karena, di luar kotak, sebuah sistem ERP
adalah generik, produk semifinished, IS dan personil
lainnya harus belajar bagaimana mengkonfigurasi
perangkat lunak untuk Options yang terbaik untuk
organisasi Anda. Set keterampilan "bisnis analis" baru juga
mungkin diperlukan untuk secara efektif mengelola
langkah proses untuk proyek perangkat lunak paket,
daripada metodologi siklus hidup yang disesuaikan.
Karakteristik utama lain dari Early proyek ERP telah
menjadi ketergantungan berat pada pihak ketiga
konsultan yang bukan karyawan dari vendor perangkat
lunak, seperti konsultan di Big Four atau perusahaan
konsultan yang lebih kecil. "Implementasi mitra" ini
biasanya sangat berharga untuk membantu sebuah
organization cepat belajar bagaimana paket perangkat
lunak beroperasi, serta bagaimana pilihan proses bisnis
yang kompleks tertanam dalam setiap modul akan
bekerja. Karena cakupan yang besar dan kompleksitas dari
beberapa implementasi paket ERP ini, salah satu
tantangan yang manajemen NT Keytelah sejauh mana
untuk mengandalkan konsultan eksternal untuk
memimpin sebuah proyek ERP dan bagaimana untuk
memastikan pembelian perusahaan menangkap
pengetahuan yang dibutuhkan untuk terus beroperasi dan
"menyempurnakan" konfigurasi setelah konsultan pergi.
Baru-baru ini, perusahaan yang host instalasi ERP untuk
beberapa klien (Lihat bagian berikutnya pada ASPs) dapat
diandalkan untuk menjaga aplikasi ERP berjalan dan
dipelihara untuk rilis terbaru dari perangkat lunak, serta
untuk menyediakan beberapa up-fron t dan jasa
konsultasi yang sedang berlangsung. Namun demikian,
bahkan dengan bantuan konsultan pihak ketiga, banyak
proyek implementasi ERP awal belum berhasil.
Menurut Brown dan Vessey (2003), lima faktor perlu
dikelola dengan baik untuk sebuah proyek ERP untuk
menjadi sukses. Faktor ini dijelaskan dalam beberapa
detail berikutnya.
• Top manajemen terlibat dalam proyek, tidak hanya
terlibat. Karena sistem perusahaan menuntut
perubahan mendasar dalam cara perusahaan
melakukan proses bisnisnya, eksekutif bisnisnya
harus dapat terlihat aktif dalam pendanaan dan
pengawasan proyek. Manajer tingkat rendah tidak
akan memiliki pengaruh yang diperlukan untuk
memastikan bahwa tidak hanya akan modul ERP
dikonfigurasi untuk menyelaraskan dengan solusi
proses bisnis terbaik bagi perusahaan tetapi juga
bahwa semua manajer bisnis yang relevan membeli
dalam untuk perubahan organisasi yang akan
diperlukan untuk mengambil keuntungan dari
kemampuan paket perangkat lunak. Omset antara
sponsor proyek (mengingat lamanya sebagian besar
proyek ERP) dapat berarti bahwa manajemen
 Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 413
puncak baru kurang terlibat dalam proyek, sehingga
pekerjaan pemimpin proyek untuk menjaga
manajemen atas terlibat membutuhkan effoRT
konstan. Juga, adalah umum bahwa manfaat dari
implementasi ERP akan memakan waktu untuk
terjadi, baik setelah biaya awal yang signifikan.
Reaksi awal dari beberapa pemangku kepentingan
(misalnya, karyawan, pelanggan, dan pemasok)
mungkin negatif karena start-up difficulties dan arus
kas bersih awal (Markus et al., 2003). Sekali lagi, atas
keterlibatan manajemen diperlukan untuk tetap
berkomitmen untuk tujuan akhir yang diharapkan
melalui setiap fase proyek.
• Pemimpin proyek adalah veteran, dan anggota tim
adalah pengambil keputusan. Karenaimplementasi
sistem er P sangat kompleks, para pemimpin proyek
harus sangat terampil dan memiliki rekam jejak yang
terbukti dengan memimpin sebuah proyek yang
berdampak besar pada bisnis. Anggota tim yang
mewakili bisnis yang berbeda units dan fungsi bisnis
yang berbeda (misalnya, keuangan, pemasaran,
manufaktur) perlu juga diberdayakan untuk
membuat keputusan atas nama unit atau fungsi
yang mereka wakili. Jika anggota tim tidak memiliki
hak pengambilan keputusan, para pemimpin proyek
akansangat tidak mampu memenuhi tenggat waktu
proyek yang disepakati. Hal ini juga penting untuk
mencoba untuk menjaga anggota tim proyek tetap
utuh selama mungkin karena kebutuhan untuk
orang yang tepat dalam tim dan karena waktu
Ramp-up yang dibutuhkan untuk menjadianggota
tim yang efektif n.
• Pihak ketiga mengisi kesenjangan dalam keahlian
dan mentransfer pengetahuan mereka. Seperti yang
dijelaskan sebelumnya, sistem ERP biasanya
diimplementasikan dengan bantuan mitra
implementasi pihak ketiga (konsultan), serta vendor
perangkat lunak. Set Skill dari konsultan yang
dibutuhkan akan tergantung pada keahlian dan
pengalaman dari perusahaan pembelian sendiri
bisnis dan manajer it. Jika tidak ada pemimpin
proyek internal dengan keterampilan manajemen
proyek yang diperlukan, konsultan juga harus
digunakan untuk membantu mengelola proyek.
Namun, sebelum para konsultan pergi, staf internal
perlu mendapatkan pengetahuan yang dibutuhkan
untuk terus mengoperasikan sistem baru. Banyak
organisasi mengembangkan perjanjian dengan
konsultan yang secara eksplisit mengacu pada
Transfer pengetahuan kepada staf internal sebagai
bagian dari kontrak konsultan.
• Manajemen perubahan bergandengan tangan
dengan perencanaan proyek. Banyak pengadopsi
awal sistem ERP meremehkan perlunya sumber
daya proyek untuk membantu mempersiapkan
bisnis untuk implementing sistem baru. Sistem ERP
biasanya memerlukan pelatihan tidak hanya dalam
cara menggunakan sistem baru tetapi juga dalam
cara melakukan proses bisnis dengan cara baru
untuk memanfaatkan kemampuan paket. Karena
integrasi yang ketat dari modul ERP , pekerja juga
biasanya perlu belajar lebih banyak tentang apa
yang terjadi sebelum dan sesudah interaksi mereka
sendiri dengan sistem. Perusahaan dengan masalah
paling sedikit pada saat pelaksanaan mulai
merencanakan untuk jenis perubahan sebagai
bagian darikegiatan perencanaan proyek OVE rall.
Perubahan mendasar adalah proses bisnis. Telah
ditemukan bahwa lebih baik untuk mengubah
proses bisnis untuk beradaptasi dengan praktik
terbaik tertanam dalam sistem ERP daripada
mencoba untuk memodifikasi perangkat lunak yang
dibeli; tidak modifying proses bisnis agar sesuai
dengan perangkat lunak ERP adalah alasan utama
untuk kegagalan proyek ERP. Ingat, alasan sebuah
solusi ERP sedang diadopsi adalah untuk reengineer
proses bisnis untuk praktik terbaik dan integrasi
yang lebih baik di seluruh unit bisnis. Tidak semua
sistem ERP diciptakan sama. Masing-masing
memiliki akar di beberapa industri (misalnya,
manufaktur, perbankan), sektor (yaitu, publik atau
swasta), atau negara (misalnya, AS atau Eropa).
Dengan demikian, penting untuk memilih paket ERP
yang didasarkan pada serangkaian practi CES
terbaikdan proses bisnis yang ingin Anda adopsi
(Lihat Kien dan Soh untuk lebih lanjut tentang topik
ini).
• Sebuah set pikiran memuaskan berlaku. Karena sifat
terpadu dari modul paket ERP, perusahaan biasanya
menerapkan paket sebagai "vanili" bentuk
mungkin. Ini biasanya berarti bahwa personil bisnis
akan diminta untuk "menyerah" beberapa fungsi
yang mereka miliki dalam sistem yang ERP adalah
menggantikan. Dengan kata lain, perusahaan harus
berada di
414 Bagian III • memperoleh informasi Sistem
sebuah "memuaskan" Mind-set, sebagai lawan
untuk mengharapkan sebuah "OptimAl" solusi
untuk setiap aspek dari sistem. Bagi perusahaan
dengan banyak unit bisnis di seluruh dunia, manajer
bisnis juga akan diminta untuk menerima beberapa
cara yang kurang optimal dalam melakukan sesuatu
dalam unit mereka untuk memiliki configurati
standardi seluruh perusahaan. Aturan tipikal dari
jempol di sini adalah mencoba dan menyimpan
solusi standar untuk sekitar 80 persen dari
konfigurasi paket, mengakui bahwa beberapa
kustomisasi lokal bahkan akan diperlukan karena
peraturan negara atau Regional tertentu. Terkait
adalah kebutuhan untuk berhati-hati memilih
ukuran keberhasilan proyek ERP dalam fase yang
berbeda dari proyek. Secara umum, ukuran gambar
yang besar dari keberhasilan perlu digunakan
(misalnya, "mencapai kesamaan sistem dan praktik
bisnis dalam anisasi organisasi desentralisasi") agar
organisasi untuk mempertahankan dukungan untuk
proyek.
Brown dan Vessey juga menunjukkan bahwa
kemudian pengadopsi dari jenis baru dari sistem
perusahaan selalu memiliki keuntungan dari belajar dari
kesalahan pengadopsi awal. Sebagai contoh,
comperusahaan yang membeli paket ERP di paruh kedua
tahun 1990-an bisa berbicara dengan perusahaan lain
dalam industri mereka yang telah menerapkan ERP, dan
kemudian mereka bisa patokan rencana implementasi
mereka sendiri untuk menghindari membuat mahal
kesalahan. Penulis ini juga menyarankan bahwa banyak
dari apa yang dipelajari dari proyek ERP akan membantu
pengadopsi awal dari gelombang berikutnya sistem
perusahaan (misalnya, manajemen hubungan pelanggan
dan sistem manajemen rantai suplai).
Peneliti lain (mis., Ross, 1998) telah menekankan
pentingnya mengakui bahwa besar, inisiatif sistem
perusahaan yang sangat kompleks sebenarnya tidak
berakhir dengan awal "Go Live" tanggal. Sebaliknya,
manajer harus mengantisipasi bahwa akan ada periode
waktu untuklubang pelaksanaan awal di mana sistem dan
proses baru menjadi lebih stabil ("Shakedown" periode).
Setelah cara-cara baru melakukan bisnis telah menjadi
lebih routinized dan operasi teknis dari sistem baru
berjalan lancar, the perusahaan dapat mulai membuat
perubahan yang lebih kecil (perbaikan terus-menerus)
untuk membantu mencapai manfaat bisnis yang dijanjikan
dari menerapkan jenis baru paket perangkat lunak.
Misalnya, banyak perusahaan melaporkan telah mencapai
efisiensi biaya dalam bahan PRocuatan dalam tahun
kalender pertama setelah implementasi ERP, tetapi
peningkatan nilai-rantai lain mungkin tidak akan terwujud
selama beberapa tahun lagi.
PERANGKAT LUNAK SUMBER TERBUKA
Meskipun gerakan Open Source dimulai dengan
perangkat lunak sistem seperti Linux operating sistem,
Firefox web browser, dan sistem manajemen database
MySQL, open source sekarang layak untuk aplikasi
perangkat lunak dan lainnya memungkinkan paket
(misalnya, untuk data Pergudangan dan intelijen bisnis).
Open Source Software melampaui freeware, which
dapat didownload dari berbagai papan buletin. Dengan
sumber terbuka, Anda mendapatkan kode sumber dan
hak untuk memodifikasinya. Tergantung pada lisensi
untuk mendapatkan perangkat lunak, jika Anda
mengubahnya, Anda mungkin diwajibkan untuk berbagi
perubahan Anda dengan organisasi berkomunikasiTy yang
menggunakan perangkat lunak.
Meskipun sebuah aplikasi open source bebas untuk
memperoleh, penyedia perangkat lunak serta pihak ketiga
sering menyediakan biaya berbasis produk dan layanan
untuk memperpanjang produk dengan fitur canggih,
Maintenance dan pelatihan, dan dokumentasi dan buku
tentang penggunaan perangkat lunak. Dengan demikian,
bagi sebagian orang, keuntungan nyata dari perangkat
lunak open source bukanlah biaya yang lebih rendah
melainkan independensi dari satu penyedia perangkat
lunak yang mungkin tidak memiliki prioritas yang samas
yang Anda lakukan untuk perangkat tambahan dan yang
dapat mengunci pengadopsi ke layanan mereka dan
komponen tambahan dengan tidak mengizinkan pihak
ketiga untuk terlibat. Apa yang membuat open source
jenis yang menarik dari perangkat lunak yang dibeli? Tentu
saja biaya akuisisi di atas adalah melewatkat, tetapi total
biaya kepemilikan (untuk pemeliharaan, upgrade,
dukungan, pelatihan, dokumentasi menyeluruh, dll) dapat
membuat paket proprietary tidak jauh lebih mahal.
Namun, sebuah aplikasi open source juga memiliki
keuntungan lain, termasuk berikut (see Hoffer et al.,
2011):
• Kolam besar penguji sukarelawan dan
developersmemfasilitasi pembangunan perangkat

lunak yang andal dan berbiaya rendah dalam waktu
yang relatif singkat; dengan kata lain, kelangsungan
hidup masa depan perangkat lunak aplikasi tidak
tergantung padae vendor.
• Kemampuan untuk memodifikasi kode sumber
untuk menambahkan kabinanda baru inginkan,
bukan mereka pada daftar prioritas yang
dikembangkan oleh Departemen Pemasaran dari
vendor perangkat lunak; kode baru Anda dapat
dengan mudah Diperiksa oleh orang lain; bahkan
kemampuan untuk meninjau kode sumber asli
(daripada harus memperlakukannya sebagai "kotak
hitam") berarti bahwa Anda dapat memeriksa
secara menyeluruh sebelum penyebaran.
• Anda tidak akan tergantung pada satu vendor atau
kode Pro-priet, yang mungkin tidak memungkinkan
Anda untuk meningkatkan perangkat lunak sesuai
kebutuhan Anda berubah.
• Biaya acquisition adalah sama untuk satu salinan
orribu, sehingga dapat jauh lebih murah untuk
membuat perangkat lunak yang tersedia untuk
sejumlah besar pengguna di seluruh (mungkin
global) organisasi Anda daripada akan memperoleh
lisensi multi-pengguna untuk kepemilikan aplikasis.
• Anda dapat menggunakan perangkat lunak untuk
tujuan apa pun (misalnya, penggunaan foryour
sendiri, untuk mendistribusikan dengan perangkat
lunak yang Anda tulis, untuk kegiatan pengambilan
keuntungan).
• Karena kode sumber terbuka, mungkin lebih mudah
tointerface paket open source yang berbeda dengan
satu sama lain, dan Anda tidak harus tergantung
pada vendor perangkat lunak untuk menyediakan
layanan ini.
Namun, ada beberapa risiko dengan perangkat
lunak aplikasi open source, termasuk:
• Tidak adanya withoutpaying dokumentasi lengkap
untuk itu dari beberapa penyedia layanan.
• Hanya Commodity-jenis aplikasi (yaitu,
applicationsyang generik dan umum untuk banyak
organisasi-e. g., sebuah Katalog-jenis e-commerce
situs web) yang layak; jika tidak, tidak ada motivasi
di antara komunitas yang cukup besar pengguna
bagi Anda untuk mengharapkan bahwa aplikasiion
akan ditingkatkan dengan kebutuhan maju atau
khusus dari pengguna seperti Anda.
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 415
• Kecuali ada beberapa kelompok koperasi pengguna,
pengadopsi DIF-ferent mungkin tidak tahu apa yang
orang lain lakukan, sehingga dapat duplikasi upaya;
setidaknya dengan milik software, vendor biasanya
mengumumkan apa yang masa depan perangkat
tambahan yang datang dan ketika; Namun, adalah
mungkin melalui kerjasama untuk menggabungkan
kekuatan pada pengembangan fitur yang diinginkan
oleh beberapa open source adopters.
• Ada berbagai jenisnsingperjanjian kutu sumber
terbuka, sehingga Anda harus berhati-hati untuk
memilih perangkat lunak dengan lisensi yang sesuai
dengan kebutuhan Anda (misalnya, Apakah Anda
harus berbagi kode perubahan atau Apakah Anda
dapat menjual aplikasi baru Anda mungkin
membangun dari terbuka kode sumber yang Anda
peroleh).
PEMBELIAN baru OPTION: penyedia layanan
aplikasi (ASPs)
Sebuah tren baru (atau pembaharuan dari praktek lama)
terkait dengan penerapan solusi kemasan mulai muncul di
industri TI selama dekade pertama milenium baru:
penyedia layanan aplikasi (ASPs). Catatan thpada kita
tidak membedakan di sini antara ASP dan istilah yang lebih
baru- perangkat lunak sebagai layanan (SaaS)-atau istilah
alternatif, on-demand perangkat lunak. Juga, kami tidak
membedakan di sini antara ASP dan istilah yang saat ini
populer-Cloud Computing-yang merupakan istilah yang
lebih luas yang mencakup layanan ASP disampaikan
melalui internet, sering melalui web browser.
Di bawah opsi pembelian ASP, pembeli memilih
untuk menggunakan "host" aplikasi daripada untuk
membeli aplikasi perangkat lunak dan tuan rumah di
peralatan sendiri. Oleh karena itu ASP i s penyedia layanan
yang sedang berlangsung, dan pilihan ASP adalah jenis
yang berbeda make-versus-membeli keputusan. Daripada
memiliki perjanjian lisensi perangkat lunak dengan
perusahaan yang mengembangkan perangkat lunak,
sebuah perusahaan membayar pihak ketiga (ASP) untuk
menyampaikan fungsi Software melalui Internet kepada
karyawan perusahaan dan kadang perusahaan mitra
bisnis. Host ASP memiliki lisensi untuk perangkat lunak.
Hampir semua perangkat lunak dapat dikirim melalui ASP,
dari otomatisasi kantor dasar (misalnya, Microsoft Office)
untuk perangkat lunak aplikasi khusus (misalnya,
Salesforce.com) dan sistem ERP besar (misalnya, Oracle
416 Bagian III • memperoleh informasi Sistem

ERP suite). Layanan ASP yang paling umum adalah untuk investasi infrastruktur tambahan untuk host paket. Anda
situs web hosting, e-mail, keuangan/akuntansi aplikasi, dapat menghentikan layanan setiap saat tanpa besar
dan e-commerce. Klien ASP membayar untuk sebagai "Sunk biaya" yang terkait dengan pembelian. Untuk
much atau sebagai sedikit layanan perangkat lunak yang PEdengan karyawan yang tersebar luas yang
mereka butuhkan (berdasarkan jumlah pengguna dan membutuhkan akses remote, solusi ASP juga dapat
modul yang paket klien menggunakan), daripada harus mengurangi akses jaringan dan biaya pengiriman layanan
membeli jumlah minimal lisensi dari vendor asli. lainnya. Karena paket ini juga biasanya sudah berdiri dan
Penyedia ASP mungkin spesialis dalam perangkat berjalan pada komputer host ASP, proyek efisiensi
lunak host tertentu atau di beberapa industri vertikal Suite pelaksanaant juga harus kurang memakan waktu. Juga,
perangkat lunak (misalnya, perangkat lunak untuk Layanan Hosting menyediakan semua pemeliharaan
perusahaan dalam industri perawatan kesehatan). Vendor perangkat lunak dan dukungan operasional,
teknologi utama, seperti Microsoft dan Oracle, juga membebaskan staf TI Anda untuk bekerja pada aplikasi
menyediakan berbagai penyimpanan data dan perangkat lain. Seringkali, organisasi Anda dapat menggunakan
lunak aplikasi melalui ASP-pilihan hosting. Banyak host paket dengan lebih banyak fungsi (bisa dibilang perangkat
ASP berorientasi untuk mendukung usaha kecil dan lunak standar terbaik atau industri) daripada yang Anda
menengah di wilayah geografis tertentu (ketika mereka mungkin mampu membeli secara langsung perangkat
dapat bertemu langsung dengan klien). Beberapa ASPs lunak.
menyediakan layanan tambahan, seperti mengatur untuk Namun, ada juga beberapa potensi kerugian,
jaringan lokal dan layanan ISP untuk menyediakan akses termasuk ketergantungan pada vendor eksternal tidak
internet, dan membeli dan memelihara thin-client hanya untuk paket perangkat lunak tetapi juga untuk
workstation untuk pelanggan mereka (ketika klien tipis operasi yang sedang berlangsung. Proses yang baik untuk
cukup karena semua perangkat lunak dan penyimpanan membuat keputusan pembelian terbaik dan kontraktor
data dipertahankan di situs host ASP). untuk tingkat layanan yang diperlukan bahkan lebih
kritis
ketika
sebuah
Sebuah mimpi versus sebuah mimpi buruk
Itu adalah manajer TI mimpi buruk terburuk. The OshKosh B'Gosh perusahaan toko online terbuka, tapi
perintah pergi ke mana-mana: komunikasi link antara pengecer pakaian dan perusahaan yang host aplikasi
web-nya telah turun. Menyelesaikan nightmadalah lebih rumit karena ASP dengan yang OshKosh telah
dikontrak telah subkontrak dengan perusahaan lain untuk meng-host aplikasi mereka. Dan operator
telekomunikasi OshKosh perlu masuk ke situs hosting untuk memperbaiki peralatan. Menurut CIO Jon Dell-
Antonia di OshKosh, "itu seperti tiga Stooges dan Keystone Cops dikombinasikan. Jika saya pergi melalui
seluruh litany, Anda akan bergulir di lantai tertawa. Tapi kami tidak tertawa pada saat itu. "
Salah satu kesalahan umum perusahaan membuat saat choosing vendor ASP adalah bahwa mereka
melibatkan spesialis aplikasi mereka dalam pertemuan dengan calon ASPs, tetapi tidak mereka spesialis
operasi komputer. Menurut seorang analis dengan Gartner Group, pelanggan harus berkonsentrasi tidak
hanya pada A di ASP-aplikasi yang akan disediakan-tetapi juga S-layanan. Anda perlu dengan cermat
mendokumentasikan kebutuhan Anda terlebih dahulu, sebelum Anda mulai berbicara dengan ASP.

[Berdasarkan Anthes, 2000]

Dua keuntungan utama AssoVenus dengan
membeli sebuah paket, yang dibahas pada awal bab ini,
juga keuntungan untuk memilih ASP: (1) penghematan
biaya dan (2) kecepatan lebih cepat pelaksanaan. Layanan
berbasis langganan dengan ASP biasanya melibatkan f Ees
bulanan(bayar karena Anda pergi) daripada investasi TI
besar di muka baik dalam paket perangkat lunak dan
organisasi masuk ke dalam Perjanjian ASP. Sebuah proses
pembelian yang dengan cermat menilai kemampuan ASP
untuk memberikan kinerja yang dapat diandalkan,
keamanan untuk data organisasi, dan kemungkinan ASP
bertahan dalam marketplaCE sangat penting bagi kontrak
ASP, karena pasar ini masih dalam tahap awal. Beberapa
risiko ini tampaknya berkurang ketika host ASP juga

vendor perangkat lunak besar — seperti SAP atau
PeopleSoft untuk modul ERP atau sistem Siebel untuk
CRM moDules. Host ASP mungkin tidak dalam bisnis
mengintegrasikan perangkat lunak host mereka dengan
perangkat lunak yang dihosting klien; dengan demikian,
model ASP bekerja terbaik untuk aplikasi yang berdiri
sendiri. Juga, host tidak akan menyesuaikan perangkat
lunak untuk klien (di luar fitur customiz
apapunyangdibangun ke dalam perangkat lunak seperti
termasuk logo organisasi Anda dalam dokumen yang
dihasilkan komputer). Keamanan (memastikan data Anda
akan terlindungi
dari akses oleh orang lain, terutama di organisasi pesaing
menggunakan layanan hosting yang sama) dapat menjadi
perhatian, tetapi kebanyakan ASPs memberikan layanan
Ringkasan
Pembelian perangkat lunak Kemasan adalah alternatif
untuk pengembangan perangkat lunak kustom yang telah
semakin dikejar olehpengesahan organ dari semua ukuran
sejak awal 1990-an. Fakta bahwa solusi kemasan dapat
diimplementasikan lebih cepat daripada solusi yang
dikembangkan secara khusus dengan fungsi yang sama,
atau serupa, merupakan keuntungan besar dalam
lingkungan bisnis fastchanging saat ini. Mayoratau
kerugian dapat meningkatkan ketergantungan pada
vendor yang dapat keluar dari bisnis.
Proses untuk membeli aplikasi didasarkan pada fase
siklus hidup yang sama sebagai pendekatan kustom:
Definisi, konstruksi, dan implementasi. Bahkan jika
aplikatiyang akan dibeli, sebuah organisasi pertama harus
menentukan kebutuhan dasar sistem sebelum mencoba
untuk memilih yang terbaik aplikasi off-the-rak solusi.
Fase definisi juga mencakup pengembangan RFP untuk
dikirim ke vendor perangkat lunak dan evaldi respons
vendor. Jika berhasil, fase definisi berakhir dengan
kontrak vendor, yang harus dinegosiasikan dengan
bantuan spesialis kontrak.
Waktu yang dihabiskan untuk kegiatan tahap
konstruksi sangat bervariasi tergantung pada apakahdia
memiliki kode sumber paket yang dimodifikasi, yang dapat
dilakukan oleh vendor, pemasok lain di luar, atau
perusahaan pembelian. Dalam kasus sistem Kemasan
Tinjau pertanyaan
1. Apa yang menjadi Trade-offs besar dalam keputusan make-
or-Buy?
Bab 10 • metodologi untuk paket perangkat lunak yang dibeli 417
keamanan High-End. Akhirnya, Layanan Hosting mungkin
mengharuskan Anda untuk mengkonversi ke versi baru
dari perangkat lunak yang dikemas, yang mungkin tidak
ketika Anda ingin mengkonversi.
Metrik untuk kinerja vendor dan penalti untuk
ketidakpatuhan harus menjadi bagian penting dari
kontrak. Sebuah perjanjian tingkat layanan harus
menjadi bagian dari kontrak, di mana kinerja tertentu
harapanRe set untuk berbagai metrik operasional-seperti
sistem uptime, waktu pemulihan, menunggu waktu pada
panggilan ke meja bantuan, pemberitahuan tentang
peningkatan perangkat lunak, dan faktor lain yang penting
bagi pelanggan. Seperti yang dijelaskan dalam kotak
berjudul "A Dream versus NightmaRe," jika Anda tidak
melakukan pekerjaan yang baik dengan proses seleksi ASP
di depan, Anda berisiko membayar harga nanti.
besar yang diharapkan ada rilis masa depan yang sering
(misalnya, modul ERP), modificabiasanya disimpan ke
minimal. Sebaliknya, tahap implementasi untuk paket
perangkat lunak dapat lebih menantang daripada untuk
aplikasi kustom karena perusahaan pembelian kurangnya
keakraban dengan rincian bagaimana paket Operates
serta kebutuhan untuk skala besar perubahan dalam cara
perusahaan akan beroperasi setelah paket baru telah
diimplementasikan. Vendor perangkat lunak mungkin
sangat terlibat dalam langkah instalasi dan juga biasanya
diandalkan untuk pemeliharaan yang berkelanjutan. Large
perusahaan vendor sistem (misalnya, SAP) biasanya rilis
versi baru secara sering dan mendukung versi lama dari
paket hanya untuk jangka waktu yang ditetapkan.
Keahlian dalam penerapan sistem Kemasan telah
menjadi kemampuan TI yang penting. Di beberapa
perusahaan, posisi manajer baru telah dibuat dalam
rangka untuk mengelola hubungan dengan vendor IT.
Organisasi semakin mempertimbangkan paket open
source selain paket aplikasi proprietary. Paket open
source dapat diperoleh dengan investasi di muka yang
rendah; dukungan dapat diperoleh dengan biaya dari
berbagai penyedia layanan. Sebuah pilihan pengadaan
baru adalah untuk membayar penyedia layanan aplikasi
untuk meng-host aplikasi perangkat lunak untuk akses
remote oleh karyawan perusahaan melalui internet.
2. Ringkaslah lima langkah tambahan untuk membeli sistem
yang bukan merupakan bagian dari fase definisi proses
SDLC tradisional.
418 Bagian III • memperoleh informasi Sistem

3. Apa itu RFP, dan tugas CRItical apa itu memfasilitasi dalam 9. Apa saja kriteria yang harus diterapkan saat memilih di
proses pembelian? antara paket perangkat lunak kandidat aplikasi?
4. Mengapa membuat banyak modifikasi pada sistem paket 10. Apa yang Anda pikirkan adalah keuntungan yang paling
terkadang merupakan pendekatan yang berisiko, dan apa penting dan kerugian dari membeli paket?
alternatifnya? 11. Apa jenis modifikasi cenderung mudah dilakukan dan apa
5. Secara singkat ringkaslah bagaimana fase SDLC tradisional yang orang lain cenderung sulit untuk dilakukan dengan
serupa dengan atau berbedadari fase dari pendekatan paket perangkat lunak?
siklus hidup yang dimodifikasi untuk mendukung 12. Apa adalah beberapa perbedaan utama antara proses
perbandingan biaya dalam gambar 10,2. untuk mengimplementasikan paket ERP dan proses untuk
6. Menjelaskan peran vendor untuk masing-masing dari tiga mengimplementasikan paket yang kurang kompleks?
tahapan siklus hidup pembelian. 13. Apa faktor keberhasilan penting untuk menjalankan proyek
7. Menjelaskan mengapa metodologi untuk membeli System ERP?
kecil bisa berbeda dari membeli sistem yang besar. 14. Apa saja keuntungan dan kerugian relatif of perangkat
8. Jelaskan apa yang perusahaan pembelian mungkin ingin lunak open source versus paket aplikasi proprietary?
belajar dari demonstrasi vendor sistem paket. 15. Apa yang dimaksud dengan ASP dan mengapa ini
merupakan alternatif pembelian yang menarik?
Pertanyaan diskusi 8. Revisi gambar 10,3 untuk membuat daftar kriteria untuk
menilai penyedia layanan aplikasi (ASP).
1. Kritik pernyataan berikut: ini akan biaya kita $800.000 untuk
membangun sistem ini, tetapi kita dapat membeli paket
yang setara untuk $125.000. Oleh karena itu, kita dapat
menyimpan organisasi $675.000 dengan membeli paket
perangkat lunak.
2. Diskusikan pilihan yang organisasi perlu memilih dari ketika
yang terbaik dikemas-sistem solusi yang tidak sempurna
cocok wITH kebutuhan organisasi.
3. Anda menjalankan bisnis kecil. Anda tidak memiliki spesialis
IS pada staf Anda dan berencana untuk membeli semua
perangkat lunak Anda. Apa yang mungkin menjadi tiga
kekhawatiran terpenting Anda?
4. Anda adalah seorang manajer di sebuah perusahaan yang
memiliki banyak in-House IS keahlian. Apa yang mungkin
Anda aturan keputusan utama untuk kapan harus membeli
sistem versus Kapan harus mengembangkannya di-rumah?
5. Diskusikan mengapa penilaian stabilitas keuangan vendor
dapat menjadi pertimbangan critiCal ketika mengevaluasi
tanggapan terhadap RFP.
6. Pilih salah satu dari lima faktor yang terkait dengan
implementasi ERP sukses (disajikan dalam bagian yang
berjudul "kasus khusus: paket sistem Enterprise") dan
mengomentari bagaimana yang berbeda ini sebenarnya
adalah (atau tidak) dari sistem paket lain implementasi.
7. Banyak perusahaan menengah yang berinvestasi dalam
paket sistem ERP, seperti SAP dan Oracle/PeopleSoft.
Mengomentari apa yang Anda pikir mungkin sangat penting
bagian dari proses dimainkannya ketika purmengejar
organisasi hanya Departemen is kecil.