Acquiring Information Systems and Applications

RESUME
Disusun untuk Memenuhi Tugas Kelompok
pada Mata Kuliah Sistem Informasi
yang Diampu oleh Satriyo Adhy, S.Si, M.T.

Disusun Oleh :
Wildan Viado Elvana Putra 24010313120005
Randy Ichsan Adlis 24010313120006
Dhimas Nandista 24010313120015
Sinta Linda Astria 24010314120005
Indriana BR Sembiring 24010314120048

JURUSAN ILMU KOMPUTER/INFORMATIKA

FAKULTAS SAINS DAN MATEMATIKA
UNIVERSITAS DIPONEGORO
SEMARANG
2016
Planning for and Justifying IT
Applications
Organisasi harus menganalisis kebutuhan untuk aplikasi dan kemudian membenarkan
setiap aplikasi dalam dari segi biaya dan manfaat. Kebutuhan untuk sistem informasi
biasanya terkait dengan organisasi perencanaan dan analisis kinerja vis-à-vis pesaingnya.
Manfaat biaya yang benar harus melihat kebijaksanaan investasi dalam aplikasi IT spesifik
terhadap menghabiskan dana pada proyek-proyek alternatif.

Perencanaan IT
Proses perencanaan untuk aplikasi TI baru dimulai dengan analisis organisasi rencana
strategis, seperti yang ditunjukkan pada Gambar 10.1. Rencana strategis organisasi
menyatakan perusahaan keseluruhan misi, tujuan yang mengikuti dari misi itu, dan langkah-
langkah yang luas yang diperlukan untuk mencapai tujuan tersebut. Proses perencanaan
strategis memodifikasi tujuan organisasi dan sumber daya untuk memenuhi pasar dan
peluang yang berubah.

Rencana strategis organisasi dan arsitektur TI yang ada memberikan masukan dalam
mengembangkan rencana strategis TI. Sebagaimana kita bahas pada Bab 1, arsitektur TI
melukiskan jalan sumber daya organisasi informasi harus digunakan untuk menyelesaikan
misinya. Ini meliputi aspek teknis dan manajerial sumber daya informasi. Aspek teknis
meliputi
hardware dan sistem operasi, jaringan, sistem manajemen data, dan aplikasi perangkat lunak.
Aspek manajerial menentukan bagaimana mengelola departemen IT akan dicapai, bagaimana
manajer area fungsional akan terlibat, dan bagaimana keputusan TI akan dibuat.
Rencana strategis IT adalah seperangkat tujuan jangka panjang yang menggambarkan
infrastruktur TI dan mengidentifikasi inisiatif TI utama yang diperlukan untuk mencapai
tujuan organisasi. TI rencana strategis harus memenuhi tiga tujuan:
1 Harus selaras dengan rencana strategis organisasi.
2 Ini harus menyediakan sebuah arsitektur TI yang memungkinkan pengguna,
aplikasi, dan database untuk menjadi mulus jaringan dan terintegrasi.
3 Harus efisien mengalokasikan IS sumber daya pembangunan antara proyek-
proyek yang bersaing sehingga proyek dapat diselesaikan tepat waktu dan sesuai
anggaran dan memiliki fungsi yang diperlukan.
Setelah sebuah perusahaan telah menyepakati sebuah rencana strategis IT, di samping
mengembangkan IS operasional rencana. Rencana ini terdiri dari satu set yang jelas proyek
yang IS departemen dan fungsional pengelola kawasan akan mengeksekusi mendukung
rencana strategis TI. Sebuah khas IS rencana operasional mengandung unsur-unsur berikut:
 Misi Misi dari fungsi IS (berasal dari strategi IT).
 IS lingkungan Ringkasan informasi kebutuhan dari bidang fungsional dan dari
organisasi secara keseluruhan.
 Tujuan dari IS berfungsi Perkiraan terbaik saat ini tujuan dari fungsi IS.
 Kendala pada fungsi IS teknologi, keuangan, personil, dan sumber daya lainnya
keterbatasan pada fungsi IS.
 Portofolio aplikasi A persediaan diprioritaskan aplikasi ini dan rinci rencana proyek
yang akan dikembangkan atau berlanjut selama tahun berjalan.
 Alokasi sumber daya dan manajemen proyek Sebuah daftar yang akan melakukan
apa, bagaimana, dan kapan.

Mengevaluasi dan Membenarkan Investasi TI: Manfaat, Biaya, dan Isu

Seperti yang sudah kita bahas, mengembangkan rencana IT adalah langkah pertama
dalam proses akuisisi. Semua perusahaan memiliki jumlah terbatas sumber daya yang
tersedia untuk mereka.

Menilai Biaya
 Menempatkan nilai dolar pada biaya investasi IT mungkin tidak sesederhana
kedengarannya. Salah satu tantangan utama yang dihadapi perusahaan adalah untuk
mengalokasikan tetap biaya antara proyek-proyek TI yang berbeda. Biaya tetap adalah biaya-
biaya yang tetap sama terlepas dari setiap perubahan dalam tingkat aktivitas. Untuk IT, biaya
tetap meliputi biaya infrastruktur, biaya TI layanan, dan biaya manajemen TI. Misalnya, gaji
direktur TI adalah tetap, dan menambahkan satu aplikasi yang lebih tidak akan mengubahnya.

Menilai Manfaat
Biasanya, mengevaluasi manfaat dari proyek TI bahkan lebih
kompleks daripada menghitung biaya mereka. Manfaat mungkin lebih sulit untuk dihitung,
terutama karena banyak dari mereka yang tidak berwujud (misalnya, meningkatkan hubungan
pelanggan atau mitra atau ditingkatkan pengambilan keputusan).

Melakukan Analisa Cost-Benefit

Setelah sebuah perusahaan telah menilai biaya dan manfaat dari investasi TI, harus
membandingkan dua. Tidak ada strategi yang seragam untuk melakukan analisis ini.
Sebaliknya, hal itu dapat dilakukan dengan beberapa cara. Di sini kita membahas empat
umum pendekatan: (1) net present value, (2) pengembalian investasi, (3) analisis kerusakan,
dan (4) kasus bisnis pendekatan.
Organisasi sering menggunakan nilai sekarang (NPV) perhitungan bersih untuk
analisis biaya-manfaat. Menggunakan metode NPV, analis mengkonversi nilai-nilai masa
depan manfaat untuk mereka saat ini-nilai setara dengan "mendiskon" mereka di biaya
organisasi dana. Mereka kemudian dapat membandingkan nilai sekarang dari manfaat masa
depan untuk biaya yang diperlukan untuk mencapai manfaat tersebut dan menentukan apakah
manfaat melebihi biaya.
Alat tradisional lain untuk mengevaluasi investasi modal laba atas investasi (ROI).
ROI mengukur efektivitas manajemen dalam menghasilkan laba dengan aset yang tersedia.
ROI mengukur persentase, dan semakin tinggi persentase pengembalian, semakin baik. ROI
dihitung dengan membagi laba bersih untuk proyek oleh rata-rata aset yang diinvestasikan
dalam proyek.
Strategies for Acquiring IT Applications
Jika sebuah perusahaan telah berhasil dibenarkan investasi TI, maka harus
memutuskan bagaimana untuk mengejar itu. Perusahaan memiliki beberapa pilihan untuk
mendapatkan aplikasi TI, termasuk membeli aplikasi, sewa mereka, menggunakan perangkat
lunak open source, dengan menggunakan software-as-a-service, mengembangkan mereka di
rumah, atau melakukan outsourcing mereka. Pada bagian ini kita membahas 5 pilihan
pertama dan satu tertentu jenis layanan penyewaan-aplikasi penyedia-bersama dengan
outsourcing dalam Pasal 10.5.

Beli Aplikasi (Off-the-Shelf Approach)

Fitur standar yang dibutuhkan oleh aplikasi IT dapat ditemukan di banyak perangkat
lunak komersial paket. Membeli paket yang ada dapat menjadi strategi biaya-efektif dan
menghemat waktu dibandingkan dengan mengembangkan aplikasi di rumah. Opsi beli
terutama menarik jika vendor software memungkinkan perusahaan untuk memodifikasi
teknologi untuk memenuhi kebutuhannya. Namun, pilihan ini mungkin tidak menarik dalam
kasus di mana kustomisasi adalah satu-satunya metode menyediakan fleksibilitas yang
diperlukan untuk mengatasi perusahaan kebutuhan. Keuntungan dan keterbatasan opsi beli
dirangkum sebagai berikut:

Keuntungan dan Keterbatasan Pilihan "Beli"

Keuntungan
 Banyak jenis software off-the-rak yang tersedia.
 Software dapat dicoba.
 Banyak waktu dapat disimpan dengan membeli daripada membangun.
 Perusahaan dapat mengetahui apa itu semakin sebelum berinvestasi di produk.
 Perusahaan ini bukan pengguna pertama dan hanya.
 Software Dibeli dapat menghindari kebutuhan untuk mempekerjakan tenaga
khusus didedikasikan untuk proyek.
Kekurangan
 Software mungkin tidak tepat memenuhi kebutuhan perusahaan.
 Software mungkin sulit atau tidak mungkin untuk memodifikasi, atau mungkin
memerlukan usaha besar perubahan proses untuk melaksanakan.
 Perusahaan tidak akan memiliki kontrol atas perbaikan software dan versi
baru.
  Software Dibeli bisa sulit untuk mengintegrasikan dengan sistem yang ada.
 Vendor mungkin drop produk atau pergi keluar dari bisnis.
 Software dikendalikan oleh perusahaan lain dengan prioritas dan bisnis sendiri
pertimbangan.
 Perusahaan pembelian tidak memiliki pengetahuan yang mendalam tentang
cara kerja software dan mengapa ia bekerja seperti itu.

Menyewakan Aplikasi
Dibandingkan dengan opsi beli dan pilihan untuk mengembangkan aplikasi di-rumah,
yang "sewa" pilihan dapat menyimpan sebuah perusahaan waktu dan uang. Tentu saja, paket
disewakan (seperti dibeli paket) mungkin tidak selalu tepat sesuai kebutuhan aplikasi
perusahaan. Namun, vendor perangkat lunak umumnya termasuk fitur yang paling sering
dibutuhkan oleh organisasi dalam suatu industri tertentu.

Menggunakan Software Open-Source

Seperti yang kita lihat dalam kasus pembukaan bab ini, Zappos disesuaikan perangkat
lunak open-source (yang kita bahas dalam Panduan Teknologi 2) untuk mengembangkan
aplikasi di-rumah. Sebuah organisasi dapat mendapatkan lisensi untuk menggunakan produk
perangkat lunak open-source dan baik menggunakannya sebagaimana adanya, atau
menyesuaikan itu, untuk mengembangkan aplikasi.

Memanfaatkan Software-as-a-Service
Software-as-a-Service (SaaS) mengacu pada metode software memberikan yang
vendor host aplikasi. Pelanggan mengakses aplikasi ini melalui jaringan, biasanya Internet,
dan tidak memiliki kontrol atas aplikasi. Pelanggan tidak memiliki perangkat lunak tetapi
membayar untuk menggunakannya.

Mengembangkan Aplikasi In-House

Meskipun membangun aplikasi di-rumah biasanya lebih memakan waktu dan
mungkin lebih mahal daripada membeli atau leasing, sering mengarah ke lebih cocok dengan
organisasi tertentu persyaratan. Dalam pembangunannya dapat memanfaatkan berbagai
metodologi. Dasar, backbone metodologi adalah siklus hidup pengembangan sistem (SDLC),
yang kita bahas di depan bagian.
The Traditional Systems Development
Life Cycle
The Traditional Systems Development Life Cycle (SDLC) adalah pengembangan
sistem tradisional. Metode yang digunakan organisasi untuk proyek-proyek IT berskala besar.
SDLC adalah kerangka kerja terstruktur yang terdiri dari proses sekuensial dimana sistem
informasi yang dikembangkan. Proses ini adalah sistem investigasi, analisis sistem, sistem
desain, pemrograman, pengujian, implementasi, operasi, dan pemeliharaan. Setiap Proses
pada gilirannya terdiri dari tugas-tugas yang jelas. Ada total delapan proses yang akan
dilakukan di bagian ini.
Model-model lain untuk SDLC mungkin berisi lebih atau kurang dari delapan tahap
yang akan disajikan sini. Aliran tugas, bagaimanapun, sebagian besar masih sama. Di masa
lalu, pengembang menggunakan pendekatan waterfall SDLC, yaitu, tugas yang diselesaikan
dengan cara bertahap, sebelum dilanjutkan ke tahap pekerjaan berikutnya.
SDLC memiliki tiga keunggulan utama yaitu: kontrol, akuntabilitas, dan deteksi
kesalahan. Sebuah isu penting dalam pengembangan sistem adalah bahwa kemudian dalam
proses development terdapat kesalahan yang terdeteksi oleh sistem, maka akan menyebabkan
semakin mahalnya biaya yang dikeluarkan untuk memperbaiki hal tersebut. Dengan
demikian, urutan terstruktur tugas dan tonggak dalam SDLC membuat pencegahan dan
deteksi kesalahan lebih mudah dan menghemat uang dalam jangka panjang.

Gambar 3.1 Sistem Delapan Tahap Siklus Hidup Pengembangan (SDLC)

SDLC memang memiliki beberapa kelemahan, namun. Karena sifatnya terstruktur,
maka hal itu menjadi masalah yang relatif. Selain itu SLDC tidak fleksibel. Hal ini juga
memakan waktu dan biaya yang mahal, dan melarang para pengguna untuk melakukan
perubahan persyaratan setelah hal itu telah mereka tetapkan. Manajer pengembangan yang
harus melakukan pengembangan besar, aplikasi enterprisewide harus mempertimbangkan
kelemahan ini dengan hati-hati.

Sistem Investigasi
Merupakan tahap awal dalam SDLC tradisional penyelidikan sistem. Profesional
pengembangan sistem setuju bahwa semakin banyak waktu mereka berinvestasi dalam,
a Memahami masalah bisnis menjadi dipecahkan
b Opsi teknis untuk sistem, dan
c Masalah yang mungkin terjadi selama pembangunan jika semakin besarnya peluang
keberhasilan.
Untuk alasan ini, penyelidikan sistem dimulai dengan masalah bisnis (atau peluang bisnis),
diikuti oleh analisis kelayakan.

Sistem Analisis
Setelah proyek pembangunan memiliki persetujuan yang diperlukan dari semua
peserta, sistem tahap analisis dimulai. Analisis sistem adalah pemeriksaan masalah bisnis
yang ter-organisasi dan berencana untuk menyelesaikan masalah dengan menggunakan
sistem informasi. Tahap ini mendefinisikan masalah bisnis secara lebih rinci,
mengidentifikasi penyebabnya, menentukan solusi, dan mengidentifikasi informasi
persyaratan bahwa solusi harus memenuhi.
Memahami masalah bisnis memerlukan pemahaman dari berbagai proses yang
terlibat. Proses ini seringkali rumit dan saling bergantung satu dengan yang lainnya. Tujuan
utama dari tahap analisis sistem adalah untuk mengumpulkan informasi tentang ada sistem
untuk menentukan persyaratan untuk sistem ditingkatkan atau baru. Tahap akhir dari produk
pada tahap ini, yang dikenal sebagai "deliverable," adalah satu set dari system requirements.
Tahap analisis sistem menghasilkan informasi sebagai berikut:
a Kekuatan dan kelemahan dari sistem yang ada
b Sistem baru harus memiliki fungsi untuk dapat memecahkan masalah bisnis, dan
c Kebutuhan informasi pengguna untuk sistem yang baru.
Dibekali oleh informasi ini, sistem pengembang dapat melanjutkan prosesnya ke tahap sistem
desain.
Sistem Desain
Sistem desain menggambarkan bagaimana sistem akan menyelesaikan tugas ini.
Deliverable dari tahap desain sistem adalah desain teknis, yang menentukan hal – hal berikut:
• Sistem output, input, dan user interface
• Hardware, software, database, telekomunikasi, personel, dan prosedur
• Sebuah cetak biru tentang bagaimana komponen ini diintegrasikan.
Output ini merupakan set spesifikasi sistem. Sistem desain mencakup dua aspek
utama dari sistem baru yaitu: desain sistem logis dan desain fisik. Desain sistem logis
menyatakan sistem apa yang akan dipakai, dengan menggunakan spesifikasi abstrak,
sedangkan bagian desain sistem fisik akan bertugas untuk bagaimana sistem akan melakukan
fungsinya, dengan aktualisasi spesifikasi fisik. Spesifikasi desain logis meliputi desain
output, input, pengolahan, database, telekomunikasi, kontrol, keamanan, dan pekerjaan IS.
Spesifikasi desain fisik termasuk desain hardware, software, database, telekomunikasi, dan
prosedur.

Programming
Sistem pengembang memanfaatkan spesifikasi desain untuk memperoleh perangkat
lunak yang diperlukan oleh sistem untuk memenuhi tujuan fungsional dan memecahkan
masalah bisnis. Meskipun banyak organisasi cenderung membeli paket perangkat lunak,
banyak perusahaan lainnya yang terus mengembangkan kustom software di-rumah. Jika
organisasi memutuskan untuk membangun perangkat lunak di rumah, maka tugas dari
pemrograman akan dimulai. Pemrograman melibatkan penerjemahan spesifikasi desain ke
dalam kode komputer. Proses ini bisa memakan waktu yang panjang dan lama, karena
menulis kode komputer adalah termasuk suatu seni yang dikelompokkan sebagai ilmu.
Sistem proyek pembangunan besar dapat memerlukan ratusan ribu baris kode
komputer dan ratusan pemrogram komputer. Proyek-proyek skala besar mempekerjakan tim
pemrograman, yang sering termasuk pengguna area fungsional, yang membantu programmer
fokus pada masalah bisnis.

Testing
Pengujian dirancang untuk mendeteksi kesalahan, atau bug, dalam kode komputer.
Kesalahan ini terdiri dari dua jenis, yaitu: sintaks dan logika. Kesalahan sintaks (misalnya,
kata yang salah eja atau salah tempat koma) adalah hal yang lebih mudah untuk ditemukan
dan tidak akan mengizinkan program untuk dijalankan. Kesalahan logika mengizinkan
program untuk dijalankan, tetapi akan menyebabkan program menghasilkan output yang
salah. Kesalahan logika merupakan kesalahan yang lebih sulit untuk dideteksi, karena
penyebabnya tidak jelas. Programmer harus mengikuti aliran logika dalam program untuk
menentukan sumber kesalahan dalam outputnya.
Ketika perangkat lunak menjadi lebih kompleks, jumlah kesalahan akan meningkat,
sampai hampir tidak mungkin untuk menemukan semua kesalahannya. Situasi ini telah
menyebabkan istilah pada software yaitu software "yang cukup baik", yang didefinisikan
sebagai perangkat lunak yang pengembang percaya akan memenuhi tujuan fungsional,
meskipun mengandung kesalahan dalam penulisan kodenya. Artinya, pengembang yakin
mereka telah menemukan semua "show-stopper" bug. Bug ini adalah kesalahan serius yang
akan menyebabkan bencana hilangnya atau korupsi data dan mungkin akan mematikan
sistem sepenuhnya. Sebaliknya, kesalahan yang tetap tertanam di perangkat lunak yang
cukup-baik itu tidak akan mempengaruhi kinerja sistem dengan cara yang signifikan.

Implementasi
Implementasi (atau deployment) adalah proses konversi dari sistem lama ke sistem
baru. Organisasi menggunakan tiga strategi konversi utama yaitu: langsung, pilot, dan
bertahap. Dalam konversi langsung, sistem lama terputus dan sistem baru akan diaktifkan
pada titik waktu tertentu. Jenis konversi ini adalah jenis konversi yang paling mahal. Dan ini
juga merupakan konversi yang paling berisiko, jika sistem baru tidak bekerja seperti yang
direncanakan. Karena risiko ini, beberapa sistem diimplementasikan menggunakan konversi
langsung.
Sebuah konversi percontohan memperkenalkan sistem baru di salah satu bagian dari
organisasi, seperti di satu pabrik atau di salah satu area fungsional. Sistem baru berjalan
untuk jangka waktu dan kemudian dinilai. Jika penilaian menegaskan bahwa sistem itu
bekerja dengan baik, maka diperkenalkan di lain bagian organisasi. Pada skhirnya, konversi
bertahap memperkenalkan komponen dari sistem baru, seperti modul individu. secara
bertahap, Setiap modul akan dinilai. Jika bekerja dengan baik, maka modul lain akan
diperkenalkan sampai sistem baru digunakan di seluruh sistem operasional. Strategi keempat
yaitu, konversi paralel, dimana sistem lama dan baru beroperasi secara bersamaan untuk
sementara waktu, namun hampir tidak digunakan untuk saat ini.

Operasi dan Pemeliharaan

 Setelah sistem baru diimplementasikan, maka akan beroperasi untuk jangka waktu
tertentu sampai (seperti periode sistem yang lama diganti) tidak lagi memenuhi tujuannya.
Setelah operasi sistem yang baru telah dirasa stabil, perusahaan akan melakukan audit untuk
menilai kemampuan sistem dan untuk menentukan apakah sistem itu telah digunakan dengan
benar.
Suatu Sistem memerlukan beberapa jenis perawatan. Tipe pertama adalah
debugging program, proses yang berlanjut secara terus menerus sepanjang perjalanan dari
sistem. Tipe kedua adalah memperbarui sistem untuk mengakomodasi perubahan kondisi
bisnis. Contohnya adalah menyesuaikan diri dengan peraturan pemerintah yang baru, seperti
perubahan tarif pajak. Mengkoreksi hal ini dan mengupgrade biasanya tidak menambahkan
fungsi baru pada sistem. Sebaliknya, mereka hanya membantu sistem untuk melanjutkan
tujuannya. Sebaliknya, pemeliharaan tipe ketiga melakukan pemeliharaan dengan
menambahkan fungsi baru ke dalam sistem yang ada tanpa mengganggu proses operasi.

Alternative Methods and Tools for

Systems Development
Sejumlah alat digunakan dalam hubungannya dengan traditional systems development
life cycle (SDLC). Bagian ini dirancang untuk melengkapi SDLC dan membuat berbagai
fungsi dari SDLC menjadi lebih mudah dan lebih cepat dalam pelaksanaannya. Alat ini
berupa prototyping, desain aplikasi bersama, dibantu komputer rekayasa perangkat lunak, dan
pengembangan aplikasi yang cepat.
Metode alternatif untuk mengembangkan sistem digunakan sebagai pengganti SDLC. Metode
ini mencakup pengembangan tangkas, pengembangan pengguna akhir, dan pengembangan
berbasis komponen.

Prototyping
Pendekatan prototipe mendefinisikan daftar awal dari kebutuhan pengguna,
membangun sistem prototipe, dan kemudian meningkatkan sistem di beberapa iterasi
berdasarkan masukan pengguna. Pengembang tidak mencoba untuk mendapatkan satu set
lengkap pengguna spesifikasi-spesifikasi untuk sistem di awal, dan mereka tidak berencana
untuk mengembangkan sistem sekaligus. Sebaliknya, mereka dengan cepat mengembangkan
versi yang lebih kecil dari sistem yang dikenal sebagai prototipe. Sebuah prototipe dapat
mengambil dua bentuk. Dalam beberapa kasus hanya berisi komponen dari sistem baru yang
paling menarik bagi pengguna. Dalam kasus lain itu adalah model kerja skala kecil dari
seluruh sistem.
Pengguna membuat saran untuk meningkatkan prototipe, berdasarkan pengalaman
mereka dengan itu. Para pengembang kemudian meninjau prototipe dengan pengguna dan
menggunakan saran mereka untuk kembali mendefinisikan prototipe. Proses ini berlanjut
melalui beberapa iterasi sampai pengguna menyetujui sistem atau menjadi jelas bahwa sistem
tidak dapat memenuhi kebutuhan pengguna. Jika sistem ini layak, maka pengembang dapat
menggunakan prototipe untuk membangun sistem penuh. Mengembangkan layar bahwa
pengguna akan melihat dan berinteraksi adalah penggunaan khas prototyping.
Keuntungan utama dari prototyping adalah bahwa hal itu mempercepat proses
pembangunan. Selain itu, prototyping memberikan pengguna kesempatan untuk
mengklarifikasi kebutuhan informasi mereka karena mereka meninjau iterasi dari sistem
baru.
Prototyping juga memiliki kelemahan. Kelemahan yang pertama adalah pengguna, melihat
layar yang muncul untuk berperilaku seperti sistem yang sudah jadi tidak akan menyadari
jumlah pekerjaan yang masih harus dilakukan di belakang layar untuk menyediakan sistem
operasional dengan database, pengecekan error, tindakan pencegahan keamanan, dan semua
fungsi lain yang prototipe tidak dimiliki. Situasi ini dapat mengakibatkan pengguna memiliki
harapan yang tidak realistis tentang kapan aplikasi yang belum selesai akan dikirimkan.
Selain itu, karena sebagian besar dapat menggantikan analisis dan desain tahapan
SDLC dalam beberapa proyek, analis sistem tidak dapat menghasilkan dokumentasi yang
memadai untuk programmer. Kurangnya dokumentasi dapat menyebabkan masalah setelah
sistem beroperasi dan kebutuhan akan pemeliharaan. Prototyping juga dapat menghasilkan
kelebihan jumlah iterasi. Iterasi ini benar-benar dapat mengkonsumsi waktu prototyping.
Kelemahan lain adalah risiko desain istimewa. Artinya, prototipe dapat direvisi berdasarkan
umpan balik dari hanya sekelompok kecil pengguna yang tidak selalu mewakili seluruh
populasi pengguna.

Joint Application Design

Joint application design (JAD) adalah alat berbasis kelompok untuk mengumpulkan
kebutuhan pengguna dan menciptakan desain sistem. JAD paling sering digunakan dalam
analisis sistem dan sistem tahap desain SDLC. JAD melibatkan pertemuan kelompok di mana
memenuhi semua pengguna bersamaan dengan analis. Pada dasarnya adalah kelompok proses
pengambilan keputusan yang dapat dilakukan secara manual atau komputer. Selama
pertemuan ini, semua pengguna bersama-sama mendefinisikan dan menyepakati persyaratan
sistem. Proses ini menghemat sejumlah besar waktu.
Pendekatan JAD ke pengembangan sistem memiliki beberapa keunggulan. Pertama,
proses kelompok melibatkan banyak pengguna dalam proses pembangunan sementara masih
menghemat waktu. Keterlibatan ini menyebabkan dukungan yang lebih besar untuk sistem
baru. Selain itu, dapat meningkatkan kualitas sistem baru dan membuatnya lebih mudah
untuk menerapkan. Pada gilirannya, ini akan mengurangi biaya pelatihan.
Pendekatan JAD juga memiliki kelemahan. Pertama, sangat sulit untuk membuat
semua pengguna untuk menghadiri pertemuan JAD. Misalnya, dalam organisasi besar
pengguna mungkin secara harfiah akan tersebar di seluruh dunia. Kedua, pendekatan JAD
memiliki semua masalah yang terkait dengan proses kelompok (misalnya, satu orang dapat
mendominasi pertemuan tersebut, beberapa peserta tidak dapat berkontribusi dalam grup, dan
sebagainya). Untuk mengatasi masalah ini, sesi JAD biasanya memiliki fasilitator yang
terampil dalam analisis sistem dan desain serta dalam mengelola pertemuan dan proses
kelompok. Dan juga, penggunaan groupware (seperti GDSS) dapat membantu memfasilitasi
pertemuan.

Integrated Computer-Assisted Software Engineering Tools

Computer-aided software engineering (CASE) adalah pendekatan pembangunan yang
menggunakan alat khusus untuk mengotomatisasi banyak tugas di SDLC. Alat yang
digunakan untuk mengotomatisasi tahap awal dari SDLC (sistem investigasi, analisis, dan
desain) disebut alat CASE atas. Alat yang digunakan untuk mengotomatisasi tahap
selanjutnya dalam SDLC (pemrograman, pengujian, operasi, dan pemeliharaan) disebut
CASE tools yang lebih rendah. CASE tools yang menyediakan link antara CASE atas dan
alat CASE yang lebih rendah disebut CASE terintegrasi (ICASE).
CASE tools memberikan keuntungan bagi pengembang sistem. Alat-alat ini dapat
menghasilkan sistem dengan kehidupan operasional yang efektif serta lebih erat memenuhi
kebutuhan pengguna. Mereka juga dapat mempercepat proses pembangunan. Selain itu,
mereka membantu sistem menghasilkan yang lebih fleksibel dan mudah beradaptasi dengan
perubahan kondisi bisnis. Akhirnya, sistem diproduksi menggunakan CASE tools yang pada
biasanya memiliki dokumentasi yang sangat baik.
 Pada saat yang sama, sistem awal yang dihasilkan oleh CASE tools sering lebih mahal
untuk membangun dan memelihara. Selain itu CASE tools memerlukan definisi lebih luas
dan akurat dari kebutuhan pengguna dan persyaratan. Akhirnya, CASE tools sulit untuk
menyesuaikan. Untuk alasan ini, mereka kadang-kadang sulit untuk digunakan dengan sistem
yang ada.

Rapid Application Development

Rapid application development (RAD) adalah metode pengembangan sistem yang
dapat menggabungkan JAD, prototyping, dan alat-alat CASE terintegrasi untuk menghasilkan
sistem berkualitas tinggi dengan cepat. Pada tahap RAD pertama, sesi JAD digunakan untuk
mengumpulkan persyaratan sistem, sehingga pengguna secara intensif terlibat sejak awal.
Proses pembangunan di RAD adalah berulang, mirip dengan prototyping. Artinya,
persyaratan, desain, dan sistem itu sendiri dikembangkan dan kemudian menjalani
serangkaian, atau urutan, dari perbaikan. RAD menggunakan alat ICASE dengan cepat
struktur persyaratan dan mengembangkan prototipe. Sebagai prototipe yang dikembangkan
dan kembali didefinisikan, pengguna meninjau mereka di sesi JAD tambahan. RAD
memproduksi komponen fungsional dari sistem final, bukan versi terbatas skala. Untuk
memahami bagaimana fungsi RAD dan perbedaannya dari SDLC, lihat Figure 10.3.

Metodologi RAD dan alat memungkinkan untuk mengembangkan sistem yang lebih
cepat, terutama sistem di mana user interface merupakan komponen penting. RAD juga dapat
meningkatkan proses menulis ulang aplikasi warisan.

Agile Development
 Agile development adalah metodologi pengembangan software yang memberikan
fungsi dalam iterasi yang diukur cepat dan memerlukan seringnya komunikasi,
pengembangan, pengujian, dan pengiriman. Agile berfokus pada pengembangan cepat dan
sering dalam hal melakukan kontak ke pengguna untuk membuat perangkat lunak yang
sangat relevan dengan pengguna bisnis. Perangkat lunak ini tidak harus menyertakan setiap
fitur yang mungkin pengguna akan membutuhkan. Sebaliknya, itu harus memenuhi
kebutuhan yang lebih penting dan mendesak. Perangkat lunak ini dapat diperbarui kemudian
memperkenalkan fungsionalitas yang lebih lanjut.
Prinsip inti Agile adalah hanya melakukan apa yang harus Anda lakukan untuk
menjadi sukses. Pembangunan Agile menggunakan tim kecil (5-9 orang), yang terletak pada
pengguna dan lintas-fungsional. Tim memberikan proyek sekitar dua sampai empat minggu.
Mereka menjadwalkan demonstrasi dengan pengguna untuk menerima umpan balik. Setelah
demo, tim pengembang bertemu untuk memutuskan aspek proyek yang berjalan dengan baik
dan aspek-aspek yang perlu dilakukan perbaikan. Tim kemudian memilih tiga prioritas utama
dan menyesuaikan jadwal akan datang yang sesuai.
Sebuah "kehadiran" user sangat penting untuk keberhasilan pembangunan tangkas.
Sebagai contoh, pertimbangkan sebuah sistem dengan persyaratan awal untuk menangani
pembayaran elektronik. Tim pengembangan menemukan bahwa menggunakan PayPal akan
jauh lebih mudah daripada mencoba untuk menulis kode komputer baru untuk
mengintegrasikan dengan prosesor kartu kredit. Jika pengguna setuju bahwa PayPal adalah
mencukupi, maka tim pengembangan cepat dapat mengimplementasikan solusi.

End-User Development
Selama bertahun-tahun, komputer telah menjadi lebih murah, lebih kecil, dan lebih
tersebar luas di seluruh organisasi. Hari ini, hampir semua orang yang bekerja di meja atau di
lapangan memiliki komputer. Salah satu hasil dari perkembangan ini adalah bahwa banyak
kegiatan yang berkaitan dengan komputer telah bergeser keluar ke area kerja. Misalnya,
pengguna akhir saat menangani sebagian entri data mereka sendiri. Mereka menciptakan
banyak laporan mereka sendiri dan mencetaknya secara lokal. Pengguna juga memberikan
pelatihan dan dukungan kepada pekerja lain di daerah mereka. Akhirnya, mereka merancang
dan mengembangkan peningkatan jumlah aplikasi mereka sendiri, kadang-kadang bahkan
sistem yang relatif besar dan kompleks.
Manfaat resmi sebagai pengembangan pengguna akhir adalah untuk pekerja dan
organisasi secara keseluruhan, memiliki beberapa keterbatasan. Kurangnya keterampilan
dapat membahayakan kualitas dan biaya kecuali organisasi menginstal kontrol yang tepat.
Selain itu, banyak pengguna akhir tidak mengambil cukup waktu untuk mendokumentasikan
karya mereka. Selain itu, mereka kadang-kadang gagal untuk mengambil langkah-langkah
keamanan yang tepat. Akhirnya, pengguna sering mengembangkan database yang tidak dapat
secara efisien mengelola semua data produksi mereka.

Component-Based Development
Pembangunan berbasis komponen menggunakan komponen standar untuk
membangun aplikasi. Komponen aplikasi dapat digunakan kembali di kanan mereka sendiri,
umumnya dengan satu fungsi yang spesifik, seperti komponen keranjang belanja, komponen
user-otentikasi, atau komponen katalog.
Banyak perusahaan startup mengejar ide pembangunan berbasis komponen aplikasi.
Contoh perusahaan ini adalah sebagai berikut.
 Ning (www.ning.com) memungkinkan Anda untuk membuat, menyesuaikan, dan
berbagi jaringan sosial Anda sendiri.
 Coghead (www.coghead.com) memungkinkan Anda untuk dengan cepat
mengembangkan aplikasi kustom dan membaginya dengan rekan kerja secara real
time. Anda dapat menggunakan aplikasi pre-built dari Coghead atau membangun
sendiri.
 Teqlo (www.teqlo.com) memungkinkan Anda menggunakan antarmuka drag-and-
drop sederhana untuk menenun layanan Web bersama-sama dan membangun aplikasi.
Misalnya, Anda bisa mengambil data dari perusahaan pelayaran Anda,
menggabungkannya dengan real-time data manufaktur dari pemasok Anda, dan
kemudian mengintegrasikan kedua set data ke dalam laporan penjualan dari toko
eBay.

Outsourcing and Applications Service

Providers
Perusahaan kecil atau menengah dengan beberapa staf TI dan anggaran yang terbatas
yang terbaik disajikan oleh kontraktor luar. Mendapatkan aplikasi IT dari kontraktor luar atau
organisasi eksternal disebut outsourcing. Perusahaan-perusahaan besar juga dapat memilih
strategi ini dalam keadaan tertentu. Misalnya, mereka mungkin ingin bereksperimen dengan
teknologi IT baru tanpa membuat investasi di muka yang besar. Mereka juga mungkin
menggunakan outsourcing untuk melindungi jaringan internal mereka dan untuk
mendapatkan akses ke ahli luar. Agen outsourcing dapat melakukan salah satu atau semua
tugas-tugas yang terlibat dalam pengembangan IT.

Beberapa jenis vendor menawarkan jasa untuk menciptakan dan mengoperasikan

sistem TI termasuk aplikasi e-commerce. Banyak perusahaan perangkat lunak, dari IBM
untuk Oracle, menawarkan berbagai jasa outsourcing untuk mengembangkan, operasi, dan
pemeliharaan aplikasi IT. IT agen outsourcing, seperti EDS, menawarkan berbagai layanan.
Juga, perusahaan besar BPA dan konsultan manajemen (misalnya, Accenture) menawarkan
beberapa layanan outsourcing. Sebagai tren outsourcing meningkat, sehingga adalah tren
untuk pindah operasi ini lepas pantai, khususnya di India dan China. Offshoring dapat
menghemat uang, tetapi mencakup risiko juga, seperti mengirim data perusahaan yang
sensitif di luar negeri.

Di masa lalu, perusahaan juga bisa menggunakan penyedia layanan aplikasi. Penyedia
layanan aplikasi (ASP) adalah agen atau vendor yang merakit perangkat lunak yang
diperlukan oleh perusahaan dan paket perangkat lunak dengan layanan seperti
pengembangan, operasi, dan pemeliharaan. Pelanggan kemudian mengakses aplikasi ini via
internet atau VAN melalui antarmuka Web browser standar.

Hari ini, bagaimanapun, perusahaan menggunakan vendor yang menyediakan layanan

hosting untuk memperoleh aplikasi (lihat, misalnya, Google dan Amazon, pembukaan dan
penutupan kasus pada Bab 1). Untuk sumber daya hardware, vendor ini menyediakan
komputasi utilitas (dibahas dalam Panduan Teknologi 1). Untuk sumber daya perangkat
lunak, vendor ini menyediakan software-as-a-service (dibahas dalam Panduan Teknologi 2).
Vendor ini juga menyediakan komunikasi kecepatan tinggi untuk terhubung dengan klien.

Menggunakan vendor hosting merupakan pilihan yang sangat diinginkan untuk bisnis
UKM. Sederhananya, mengembangkan dan mengoperasikan aplikasi TI di-rumah bisa
memakan waktu dan mahal untuk entitas ini. Leasing dari ASP menawarkan perusahaan
seperti beberapa keuntungan. Pertama, menghemat berbagai biaya (seperti biaya tenaga kerja)
dalam tahap pengembangan awal. Hal ini juga membantu mengurangi biaya pemeliharaan
perangkat lunak dan upgrade dan pelatihan pengguna dalam jangka panjang. Selain itu,
perusahaan dapat memilih produk perangkat lunak lain dari vendor untuk memenuhi
kebutuhan yang berubah. Opsi ini akan menyimpan biaya perusahaan untuk melakukan
upgrade perangkat lunak yang ada. Hal ini juga membuat perusahaan lebih kompetitif dengan
meningkatkan kemampuan perusahaan untuk beradaptasi dengan perubahan kondisi pasar.
Vendor and Software Selection
Beberapa organisasi, terutama UKM, memiliki waktu, sumber daya keuangan, atau
keahlian teknis yang diperlukan untuk mengembangkan kompleks IT atau e-bisnis sistem.
Akibatnya, bisnis rms semakin mengandalkan vendor luar untuk menyediakan perangkat
lunak, perangkat keras, dan keahlian teknis.
Akibatnya, memilih dan mengelola vendor dan persembahan perangkat lunak telah menjadi
aspek utama dari mengembangkan aplikasi IT. Berikut enam langkah dalam memilih vendor
perangkat lunak dan paket aplikasi yang berguna.

Langkah 1
Identifikasi Potensi Vendor. Perusahaan dapat mengidentifikasi vendor perangkat
lunak aplikasi potensial melalui berbagai sumber:
• katalog Software
• Daftar disediakan oleh vendor hardware
• jurnal Teknis dan perdagangan
• Konsultan dan analis industri berpengalaman di bidang aplikasi
• Peers di perusahaan lain
• pencarian Web
 Sumber-sumber ini sering menghasilkan begitu banyak vendor dan paket bahwa
perusahaan harus menggunakan beberapa kriteria evaluasi untuk menghilangkan semua tapi
yang paling menjanjikan dari pertimbangan lebih lanjut. Sebagai contoh, dapat
menghilangkan vendor yang terlalu kecil atau memiliki reputasi dipertanyakan. Selain itu,
dapat menghilangkan paket yang tidak memiliki fitur yang diperlukan atau tidak kompatibel
dengan hardware perusahaan yang ada dan / atau perangkat lunak.

Langkah 2
Tentukan Kriteria Evaluasi. Yang paling sulit dan tugas penting dalam mengevaluasi
vendor dan paket perangkat lunak adalah untuk memilih satu set rinci kriteria evaluasi.
Beberapa daerah di mana pelanggan harus mengembangkan kriteria rinci adalah:
• Karakteristik vendor
• Kebutuhan fungsional dari sistem
• Persyaratan teknis bahwa perangkat lunak harus memenuhi
• Jumlah dan kualitas dokumentasi yang
• dukungan Vendor paket
Kriteria ini harus diatur dalam request for proposal (RFP). RFP adalah dokumen yang
dikirimkan ke vendor potensial mengundang mereka untuk mengajukan proposal yang
menggambarkan paket perangkat lunak mereka dan menjelaskan bagaimana hal itu akan
memenuhi kebutuhan perusahaan. RFP menyediakan vendor dengan informasi tentang tujuan
dan persyaratan dari sistem. Secara khusus, itu menggambarkan lingkungan di mana sistem
akan digunakan, kriteria umum bahwa perusahaan akan digunakan untuk mengevaluasi
proposal, dan kondisi untuk mengirimkan proposal. RFP juga dapat meminta daftar pengguna
saat ini dari paket yang perusahaan dapat menghubungi. Akhirnya, dapat meminta vendor
untuk menunjukkan paket di fasilitas perusahaan menggunakan input ed spesifik dan data.

Langkah 3
Evaluasi Vendor dan Paket. Tanggapan untuk RFP menghasilkan volume besar
informasi bahwa perusahaan harus mengevaluasi. Tujuan dari evaluasi ini adalah untuk
menentukan kesenjangan antara kebutuhan perusahaan (seperti spesifisitas oleh persyaratan)
dan kemampuan vendor dan paket aplikasi mereka. Seringkali, perusahaan memberikan
vendor dan paket skor keseluruhan oleh (1) menetapkan berat pentingnya masing-masing
kriteria, (2) Peringkat vendor pada masing-masing kriteria tertimbang (katakanlah 1 sampai
10), dan kemudian (3) mengalikan jajaran oleh bobot yang terkait. Perusahaan kemudian
dapat memperpendek daftar calon pemasok untuk menyertakan vendor yang mencapai
keseluruhan nilai tertinggi.

Langkah 4
Pilih Vendor dan Paket. Setelah perusahaan telah memperpendek daftar calon
pemasok, maka dapat memulai negosiasi dengan vendor ini untuk menentukan bagaimana
paket mereka mungkin dimodifikasi untuk menghilangkan perbedaan apapun dengan
perusahaan kebutuhan IT. Dengan demikian, salah satu faktor paling penting dalam
keputusan adalah upaya pengembangan tambahan

yang mungkin diperlukan untuk menyesuaikan sistem untuk kebutuhan perusahaan atau
untuk mengintegrasikannya ke dalam lingkungan komputasi perusahaan. Perusahaan juga
harus mempertimbangkan pendapat dari kedua pengguna dan personil IT yang harus
mendukung sistem. Beberapa metode pemilihan perangkat lunak yang ada. Untuk daftar
kriteria umum, lihat Tabel 10.3.

Langkah 5
Negosiasi Kontrak. Kontrak dengan vendor perangkat lunak sangat penting. Hal
spesifik baik harga software dan jenis dan jumlah dukungan yang vendor setuju untuk
memberikan. Kontrak tersebut akan menjadi satu-satunya jalan jika salah satu sistem atau
vendor tidak melakukan seperti yang diharapkan. Hal ini penting, maka, bahwa kontrak
langsung referensi proposal, karena ini adalah kendaraan yang vendor yang digunakan untuk
mendokumentasikan fungsi yang didukung dalam sistem mereka. Selanjutnya, jika vendor
memodifikasi perangkat lunak untuk menyesuaikan dengan kebutuhan perusahaan, kontrak
harus mencakup rinci spesifikasi-spesifikasi (dasarnya persyaratan). Akhirnya, kontrak harus
menjelaskan secara rinci tes penerimaan bahwa paket perangkat lunak harus lulus. Kontrak
adalah dokumen hukum, dan mereka bisa sangat rumit. Untuk alasan ini, perusahaan
mungkin perlu jasa negosiator kontrak berpengalaman dan pengacara. Banyak organisasi
mempekerjakan spesialis software yang membantu dalam negosiasi dan menulis atau
menyetujui kontrak. Spesialis ini harus terlibat dalam proses seleksi dari awal.

Langkah 6
Membangun Service Level Agreement. perjanjian tingkat layanan (SLA) merupakan
perjanjian formal yang menentukan bagaimana pekerjaan harus dibagi antara perusahaan dan
vendor. divisi ini didasarkan pada satu set, pemeriksaan kualitas, dan apa-jika situasi. Mereka
menjelaskan bagaimana pemeriksaan kualitas akan dibuat dan apa yang harus dilakukan
dalam kasus sengketa. SLA mencapai tujuan ini dengan (1) mendefinisikan tanggung jawab
kedua pasangan, (2) menyediakan kerangka kerja untuk merancang layanan dukungan, dan
(3) memungkinkan perusahaan untuk mempertahankan kendali sebanyak mungkin atas
sistem sendiri. SLA termasuk isu-isu seperti kinerja, ketersediaan, backup dan recovery,
upgrade, dan perangkat keras dan kepemilikan software. Sebagai contoh, SLA mungkin
menentukan bahwa ASP memiliki sistem yang tersedia untuk pelanggan 99,9 persen dari
waktu.