Bab 11

Membuat Sistem Informasi

Apa yang Akan Anda Pelajari dalam Bab ini

Bab ini mencakup topik yang sangat penting: proses dimana sistem informasi organisasi datang
untuk menjadi. Sementara sebagai manajer umum atau fungsional Anda mungkin tidak perhatian
diri dengan keputusan hardware, Anda harus mengambil bagian dalam proses desain perangkat
lunak, akuisisi, dan implementasi. keterlibatan Anda adalah penting karena profesional teknologi
jarang dapat mengevaluasi biaya / manfaat trade-off dan dampak dari sistem informasi baru
tentang Organisasi dan driver keberhasilan usahanya.
Secara khusus, bab ini akan

1. Membantu Anda menghargai bagaimana kompleks itu adalah untuk merancang dan
mengimplementasikan sistem informasi (IS) dan stabil, kuat, teknologi aman di
mereka inti.
2. Mengartikulasikan keuntungan dan kerugian dari desain perangkat lunak kustom dan
pengembangan dibandingkan perolehan suatu produk off-the-rak.
3. Jelaskan dan mengajarkan Anda untuk menggunakan metodologi utama untuk desain
perangkat lunak kustom dan pengembangan. Secara khusus, Anda akan dapat
mengidentifikasi fase utama dari siklus hidup pengembangan sistem (SDLC) dan
mendiskusikan kelebihan dan kekurangan. Anda juga akan menjadi akrab dengan
prototyping, gesit, dan pengembangan dan operasi (DevOps) pendekatan dan akan
dapat mengidentifikasi keunggulan utama mereka dan kekurangan.
4. Mendefinisikan perangkat lunak open source jangka panjang dan dapat
mengidentifikasi model komersial utama dibuat sekitar gerakan open source. Anda
juga akan dapat mengartikulasikan keuntungan pokok dan risiko yang terkait dengan
implementasi solusi open source dalam organisasi modern.
5. Mengidentifikasi metodologi sistem seleksi sehingga Anda dapat memilih program
perangkat lunak dikemas untuk spesifik organisasi.
6. Jelaskan alasan untuk meningkatkan keunggulan end-user
 pembangunan di organisasi modern dan mengartikulasikan manfaat dan risiko dari
pendekatan ini untuk pengembangan perangkat lunak.

KASUS MINI KASUS MINI: Blues Manajemen Proyek

“Apa yang akan saya lakukan sekarang?” Anda menemukan diri Anda bertanya keras-
keras sambil menatap langit-langit di kantor Anda. “Haruskah aku de-meningkat proyek
ini atau tekan pada?” Rasanya seperti Anda berada di salah satu kasus manajemen studi-
kecuali bahwa itu nyata dan itu Anda!
Anda diputar peristiwa yang mengarah ke dilema ini. Semuanya berawal ketika Anda
ditunjuk memimpin tim-tim proyek HRBPS bertugas menciptakan manfaat sumber daya
manusia sistem manajemen paket baru. Anda telah membuat presentasi kasus bisnis
yang sangat sukses dan mendapat pujian publik dari tim eksekutif. "Akhirnya! Seseorang
yang tidak berbicara techno-omong kosong tapi dapat menyajikan sebuah proyek IT
dalam istilah bisnis!”LJ Lalli, kepala executive officer (CEO), telah berseru. Sudah
kemampuan Anda untuk antarmuka dengan kedua pengembang dan pemangku
kepentingan bisnis yang mendarat Anda posisi manajer proyek. Anda adalah manajer
proyek pertama di perusahaan Anda datang dari area fungsional (sumber daya manusia)
bukan fungsi sistem informasi.
Proyek ini telah berjalan sangat baik, dengan dukungan besar dari masyarakat-Anda
mantan rekan pengguna, tentu saja. Hal ini disebabkan sebagian besar untuk
pengetahuan Anda tentang SDM dan pendekatan ramah-pemangku kepentingan Anda.
Anda telah membuat pilihan sadar untuk mencari umpan balik pengguna dan untuk
menghormati sebagai banyak permintaan untuk perangkat tambahan mungkin. “Anda
harus membekukan persyaratan,” Erik Khan, analis sistem memimpin, keberatan. “Jika
tidak akan menjadi anarki.” Tapi Anda telah diberhentikan keluhan sebagai “grumblings
tim pengembangan.” Orang-orang tidak pernah bahagia dengan tetap ketidakpastian
sedikit. Setelah berada di “sisi lain” sebagai stakeholder dalam sejumlah proyek
pengembangan sistem, Anda tahu betul bahwa pengguna tidak bahagia adalah rute
tercepat untuk kegagalan sistem.
Sekarang Anda mulai menebak kedua keputusan Anda. Jadwal semula disebut untuk
merilis versi beta dari aplikasi untuk pengujian pengguna akhir pekan ini. Sebaliknya
Anda hanya memiliki 40%
 dari fungsi disetujui kode. Selain itu, tim Anda sedang melihat daftar 22 perangkat
tambahan, 2 di antaranya akan memerlukan perubahan dalam struktur database.
Diproyeksikan selesai, tanpa tambahan yang diusulkan, mensyaratkan tujuh bulan lebih
(peningkatan 45% pada aslinya).
Sekarang sudah jelas bahwa proyek asli juga telah kekurangan dana. Perkiraan saat
ini untuk menyelesaikan proyek dengan set disetujui persyaratan meminta kenaikan
anggaran 62% (lebih asli). Tidak jelas berapa banyak biaya untuk melampaui
persyaratan sejak 22 perangkat tambahan yang diusulkan belum dievaluasi oleh sistem
arsitek.
Anda adalah karena untuk menyajikan laporan kemajuan Ms Lalli besok sore, tapi
Anda masih tidak yakin tentang apa yang tentu saja untuk mengambil. Satu-satunya
kepastian pada titik ini adalah bahwa Anda harus membuat lapangan untuk perpanjangan
proyek dan meminta dana lebih lanjut pada pertemuan tersebut. Rencana Anda adalah
untuk melaporkan keadaan saat ini urusan, melukiskan gambaran dari produk akhir, dan
mencari dukungan. Tapi apa produk akhir akan menjadi?

Pertanyaan Diskusi

1. Apa yang harus agenda Anda untuk pertemuan besok menjadi? Jika
Anda menekan dengan strategi Anda, atau perubahan tentu saja dalam
rangka?
2. Apa yang akan Anda lakukan secara berbeda, jika ada, diberikan
kesempatan untuk memulai proyek ini lagi?

11.1 pengantar
Setelah sebuah perusahaan telah mengembangkan rencana strategis untuk penggunaan sistem
informasi (IS) sumber (Bab 6) Dan telah melalui proses penganggaran dan prioritas (Bab 10)
Untuk mengidentifikasi sistem apa informasi spesifik yang dibutuhkan, siap untuk bertindak.
Apakah sistem informasi bergantung pada teknologi kustom-dikembangkan atau komersial off-
the-shelf (COTS) perangkat lunak,
sangat penting bahwa Anda sebagai manajer umum atau fungsional memahami bagaimana sistem
informasi datang untuk menjadi. Berbekal pengetahuan ini, Anda dapat secara proaktif
berpartisipasi dalam proses tersebut.
Sementara manajer tidak perlu khawatir dengan keputusan hardware, mereka harus mengambil
bagian dalam proses desain perangkat lunak, akuisisi, dan implementasi. Selain dari porsi yang
signifikan dari anggaran Anda dikhususkan untuk manajemen sistem informasi dan
pengembangan, keterlibatan manajer dalam pendanaan sistem informasi dan desain sangat penting
karena sebelumnya telah sukses sebuah perusahaan tergantung begitu banyak pada penggunaan
aplikasi perangkat lunak yang tepat. Memutuskan apa karakteristik dari aplikasi “benar” adalah
adalah keputusan bisnis. Ini adalah keputusan lebih didasarkan pada kasus bisnis dan pemahaman
tentang proses bisnis perangkat lunak akan memungkinkan (atau kendala!) Dari pada
pertimbangan teknis.

Bagaimana Hard Bisa IT Jadilah?

Pertimbangkan hal berikut tiga contoh baru-baru ini, masing-masing memainkan dalam beberapa
tahun terakhir. Pada lembar terpisah, menjawab pertanyaan sebelum membaca untuk mengetahui
apa yang sebenarnya terjadi:

• Anak perusahaan AS salah satu produsen makanan utama di dunia menandatangani

kesepakatan untuk menerapkan SAP (terkemuka sistem aplikasi enterprise) dalam
upaya untuk memusatkan dan operasi merasionalisasi di sembilan divisi. Proyek ini
diperlukan perampingan proses, standarisasi aplikasi perangkat lunak, dan
menerapkan struktur organisasi yang sama di seluruh unit. Berapa banyak waktu dan
berapa banyak uang kan anggaran untuk proyek ini?
• Sebuah perusahaan perhotelan besar dengan lebih dari 2.000 hotel bermerek
mengembangkan sistem informasi pelanggan untuk memungkinkan strategi
manajemen hubungan pelanggan (CRM). Fungsionalitas kustom-dikembangkan dari
aplikasi perangkat lunak di jantung dari sistem informasi termasuk sistem properti
manajemen, loyalitas dan aplikasi CRM, dan modul pelaporan. Berapa banyak waktu
dan berapa banyak uang kan anggaran untuk proyek ini?
• Sebuah operator telekomunikasi besar dijadwalkan upgrade nya
 sistem layanan pelanggan dari versi 6 ke versi 7 dari aplikasi off-the-rak terkemuka.
Yang lebih baru, versi yang lebih kuat, bertukar informasi dengan 15 sistem lain
(misalnya, penagihan), akan mempermudah akses perwakilan layanan pelanggan data
pelanggan dan akan meningkatkan jumlah informasi pelanggan yang tersedia untuk
penjualan dan transaksi layanan. Berapa banyak waktu dan berapa banyak uang kan
anggaran untuk proyek ini?

Ada beberapa teknologi dan produk yang telah berevolusi sejauh dan secepat teknologi
informasi (TI) memiliki. Namun, keberhasilan mencengangkan TI dapat menyesatkan, menipu,
sehingga Anda sangat meremehkan apa yang diperlukan untuk membangun dan menerapkan
stabil, kuat, sistem yang aman yang akan bekerja di bawah beragam kondisi organisasi.
Anda harus memeriksa jawaban Anda untuk terakhir kalinya sebelum membaca di? OK, inilah
yang terjadi:

• Pelaksanaan SAP oleh perusahaan pelayanan makanan utama mengambil lebih dari
enam tahun dan lebih dari $ 200 juta. Hal itu terperosok oleh kemunduran dan buntu,
dengan korban-profil tinggi, termasuk pemimpin proyek, yang ditugaskan kembali di
tengah-tengah pelaksanaan.
• Perusahaan perhotelan besar menginvestasikan lebih dari $ 50 juta dalam desain dan
pengembangan aplikasi dan mengintegrasikannya dengan aplikasi lain dalam
infrastruktur perusahaan. Proyek ini memakan waktu sekitar dua tahun dan
kesimpulan itu telah biaya sekitar $ 120 juta. Sistem yang dihasilkan, investasi
terbesar perusahaan dalam sejarah, dianggap sukses.
• Upgrade di perusahaan telekomunikasi itu gagal total. Sistem baru itu tidak stabil,
menabrak untuk hari pada satu waktu, dan sistem lama tidak lagi digunakan. Kesulitan
layanan pelanggan diterjemahkan ke dalam sekitar $ 100 juta dalam pendapatan yang
hilang selama tiga bulan yang dibutuhkan untuk menyelesaikan upgrade. Sebuah
saingan mengakuisisi perusahaan, yang terperosok dalam kesulitan, selama setengah
valuasi aslinya.

Wawasan kritis yang bisa diperoleh dari latihan sederhana ini adalah bahwa sistem informasi
organisasi mengantar kekayaan kompleksitas yang pergi
 jauh melampaui yang terkait dengan lingkungan komputasi personal yang paling akrab bagi
pengguna biasa akhir (misalnya, pembelian dan menginstal Microsoft Office; Gambar 11.1).
Sayangnya, manajer dikelilingi oleh retorika yang menyesatkan dari pernyataan seperti “IT
mudah; bagian yang sulit adalah orang,”atau‘Hari ini, perusahaan dapat dengan mudah
mengembangkan atau teknologi pembelian untuk mendapatkan kemampuan untuk secara cepat
sesuai pesaing mereka,’atau‘IT adalah komoditas.’
pandangan-pandangan ini oversimplifications kotor realitas. Ketika mereka dipegang oleh
orang-orang yang tidak pernah terlibat dalam upaya pengembangan sistem informasi berskala
besar, mereka berbahaya menyembunyikan kebenaran: upaya pengembangan sistem informasi
organisasi yang sangat kompleks dan berisiko usaha. Sebuah studi McKinsey dilakukan pada lebih
dari 5.400 proyek TI menunjukkan bahwa rata-rata, mereka menjalankan 45% dari anggaran, 7%
dari waktu ke waktu, sementara memberikan 56% lebih sedikit nilai dari yang diharapkan, dan
bahwa 17% dari mereka menghasilkan konsekuensi negatif untuk mengancam “yang keberadaan

perusahaan.”1 Fokus saat ini pada inisiatif transformasi digital meningkat IT kompleksitas dan

ambisi proyek, berdampak, sering negatif, tingkat keberhasilan.2 Sementara masalah organisasi,
lebih-optimisme dan tujuan yang buruk adalah penyebab khas, kurangnya keterampilan teknologi,
tata pemerintahan yang buruk, dan kompleksitas proyek diwakili penyebab berkontribusi penting
untuk kegagalan implementasi.

Gambar 11.1. Potensi dan risiko proyek IS

Sumber: Dasar majalah, http://www.baselinemag.com

IT proyek yang kompleks dan berisiko justru karena mereka melibatkan kedua
teknis dan sosial tantangan-dan persimpangan dua.
Rob Austin, IS profesor dan penulis, ditangkap gagasan ini terbaik ketika menjelaskan mengapa
proyek sistem informasi mungkin tidak akan pernah sebagai disiplin dan diprediksi sebagai proses
rekayasa lainnya (misalnya, pembangunan pabrik). Dia menyatakan sebagai berikut:

Dalam istilah IT klasik, penting “persyaratan” sering tidak dilihat terlebih dahulu. Jika
pernyataan ini terdengar salah untuk Anda, mencoba alternatif-bahwa itu selalu
mungkin untuk membedakan semua persyaratan penting terlebih dahulu, terlepas dari
ukuran dan kompleksitas sistem dan tingkat teknologi dan perubahan bisnis. [. . . ]
Memang, apa yang membuat sistem yang bagus pada akhirnya, biasanya, tidak hanya
bahwa itu memenuhi persyaratan yang diketahui sebelumnya. Perbedaan antara
sistem nilai tambah TI yang besar dan anjing kikuk bahwa setiap orang membenci
sering dalam rincian yang ditemukan di sepanjang jalan, karena sistem
diimplementasikan dan pengguna mulai memiliki rasa yang lebih nyata tentang

bagaimana itu akan bekerja.3

Interaksi berbagai aktor (sering dengan agenda yang berbeda), ukuran tipis banyak sistem
organisasi, segudang diharapkan dan tak terduga kondisi organisasi sistem harus mendukung, dan
sifat terus berkembang dari perusahaan modern yang membuat proyek-proyek ini sangat
menantang. Informasi proyek sistem memerlukan keahlian teknis. Mereka juga menyerukan dosis
besar keterampilan manajerial dan keterlibatan informasi oleh manajer umum dan fungsional yang
memberikan kontribusi keahlian materi pelajaran penting.

11.2 Memenuhi Kebutuhan Informasi Pengolahan

Di Bab 2, Kami menyatakan bahwa alasan utama organisasi modern memperkenalkan sistem
informasi adalah untuk memenuhi kebutuhan pengolahan informasi mereka. sistem informasi
pengaruh TI pada intinya mereka untuk mengoptimalkan cara di mana menangkap perusahaan,
proses, toko, dan mendistribusikan informasi. Dengan demikian mereka menjadi enabler dan pilar
yang di atasnya sebuah perusahaan mengeksekusi strategi digital.
 Bagaimana perusahaan go tentang memperkenalkan pengolahan informasi fungsionalitas yang
diperlukan untuk memenuhi kebutuhan pengolahan informasinya? Bagaimana perusahaan
mengembangkan sistem yang memungkinkan transformasi digital mereka? Bagaimana sistem
informasi datang ke dalam organisasi modern? Pada tingkat yang paling umum dari analisis, proses
ini memiliki dua utama elemen-pengembangan teknologi dan informasi sistem penyebaran:

• Pengembangan teknologi. sistem informasi modern yang dibangun pada inti IT.
Apakah teknologi tersebut diperoleh dan terintegrasi ke dalam infrastruktur
perusahaan yang sudah ada atau kustom dibangun oleh (atau untuk) organisasi,
menghasilkan inti IT merupakan prasyarat untuk memberikan fungsi pengolahan
informasi yang dibutuhkan.
• pengembangan sistem informasi. Membuat dibutuhkan inti TI tidak cukup untuk
memenuhi kebutuhan informasi dari perusahaan pengolahan (lihatBab 2). perusahaan
harus berhasil mengintegrasikan teknologi dengan komponen lain dari organisasi
(yaitu, orang, proses, struktur) untuk mengembangkan sistem informasi bekerja. Ini
adalah proses implementasi.

Proses pengembangan teknologi dan implementasi saling terkait, tidak berurutan. Karena efek
sistemik (Bab 2), Komponen dari suatu sistem informasi harus berinteraksi satu sama lain tanpa
gesekan. Dengan demikian desain sebuah program perangkat lunak baru (yaitu, pengembangan
teknologi) harus memperhitungkan bagaimana teknologi akan digunakan (yaitu, proses), oleh
siapa (yaitu, orang), dan di bawah apa yang enabler organisasi dan kendala (yaitu, struktur) .
Artinya, pengembangan teknologi harus memperhitungkan pelaksanaan masa depan akun karena
sedang dirancang.

tiga Pendekatan
Ada tiga pendekatan umum untuk akuisisi fungsi pengolahan informasi dan pengenalan sistem
informasi berbasis IT. Perhatikan bahwa masing-masing pendekatan meliputi baik perkembangan
teknologi dan proses implementasi. Namun, perbedaan penting antara mereka berkaitan dengan
bagaimana komponen-dan teknologi yang lebih khusus, perangkat lunak yang mendefinisikan
kemampuan dari sistem-dirancang dan dikembangkan:
 1. desain kustom dan pengembangan. Dengan pendekatan ini, mengimplementasikan
organisasi aplikasi perangkat lunak yang tegas dibuat, apakah internal atau melalui
pengembangan outsourcing, untuk kebutuhan yang unik dari perusahaan.
2. seleksi dan akuisisi sistem. Dengan pendekatan ini, organisasi
mengimplementasikan aplikasi perangkat lunak yang dikembangkan oleh vendor dan
tersedia di pasar.
3. pengembangan pengguna akhir. Dengan pendekatan ini, organisasi menggunakan
aplikasi perangkat lunak yang dibuat ad hoc oleh pengguna akhir dan bukan sistem
informasi perusahaan profesional.

Kami jelaskan di bawah keuntungan dan risiko yang terkait dengan masing-masing pendekatan.
Kami juga memperkenalkan metodologi yang paling lazim digunakan untuk mengartikulasikan
desain sistem informasi dan proses pembangunan di masing-masing kasus. Tujuan kami di sini
bukan untuk Anda untuk menjadi ahli dalam desain sistem dan pengembangan. Sebaliknya, itu
adalah untuk membantu Anda memelihara pemahaman tentang proses sehingga Anda dapat
berhasil mengambil bagian di dalamnya.

Membuat dibandingkan Beli

Dalam beberapa kasus, kebiasaan mengembangkan perangkat lunak di jantung sistem informasi
baru bukanlah pilihan untuk perusahaan Anda; itu adalah sebuah kebutuhan. Ini adalah kasus
ketika sistem harus mengaktifkan sebuah inisiatif baru dan tidak ada pasar untuk produk seperti
sudah ada. Misalnya, ketika Amazon pertama kali diperkenalkan sistem rekomendasi pribadi nya,
perdagangan elektronik adalah sebagian besar wilayah yang belum dipetakan dan perusahaan itu
memang membentuk industri ritel online. Menunggu produk off-the-rak untuk dikembangkan
bukanlah pilihan.
Biasanya, meskipun, perusahaan harus mempertimbangkan pilihan antara pengembangan adat
dan pembelian teknologi yang dibutuhkan. Setiap pendekatan menawarkan beberapa kelebihan
dan kekurangan dan semakin organisasi memutuskan untuk membalikkan kursus-proses yang
dikenal sebagai insourcing. Pada 2013, petugas informasi kepala General Motors' (CIO) Randy
Mott berakhir kontrak $ 3 miliar per tahun melakukan outsourcing, memutuskan bukan untuk
sampai jumlah insinyur perangkat lunak GM dari 1.400 ke 8.000. Dia diringkas alasan untuk
keputusan: “Karena kami membawa [teknologi informasi] kembali bekerja di rumah, kami
dapat mengambil off tutup apa yang mungkin.”4 Baru-baru ini, CEO Jeff Immelt berkomitmen
lebih dari $ 1 miliar untuk mengubah GE menjadi salah satu perusahaan perangkat lunak atas 10
di dunia, percaya perangkat lunak itu dan analisis sekarang kompetensi strategis di mana

kelangsungan hidup dan keberhasilan GE tergantung.5

Keuntungan Pembangunan Kustom Sementara perangkat lunak dikemas tersedia di pasar,

dalam banyak kasus perusahaan masih akan terlibat dalam desain kustom dan pengembangan
untuk memanfaatkan keuntungan dari proses ini. keuntungan seperti antara lain sebagai berikut.

unik Menjahit Ciri khas aplikasi perangkat lunak kustom yang dikembangkan adalah bahwa
mereka dibentuk untuk menyesuaikan fitur unik dari perusahaan bahwa komisi mereka. Sebuah
kutipan oleh Bill Bass, mantan wakil presiden senior untuk eCommerce Akhir Lands', memberikan
metafora yang tepat: ‘Fitting 100 beberapa juta wanita di Amerika Serikat pada 8 atau 10 ukuran

dasar serta mereka ingin benar-benar mustahil.’6 Ketika kita membeli pakaian dalam ukuran
standar, mereka sering cocok di satu area dan kurang baik di lain. Biasanya, kita menerima standar
ini cocok. Namun mereka yang merasa sulit untuk menemukan pas pakaian (dan mampu
membelinya) dapat membeli pakaian tailor-made.
Tubuh manusia adalah unik, dan tidak ada dua orang yang sama. Hal yang sama berlaku untuk
organisasi modern. Dengan demikian COTS software akan “fit” dengan baik di beberapa daerah
perusahaan tetapi mungkin menciptakan masalah pada orang lain dan memerlukan beberapa

penyesuaian dari organisasi.7 Sebaliknya, custom-made software, seperti setelan tailor-made,

dapat dirancang untuk cocok dengan sempurna dengan karakteristik dan kebutuhan organisasi.
Perhatikan bahwa sementara setiap organisasi adalah unik, tidak semua proses yang. Sebagai
contoh, sementara Lands' End dan Eddie Bauer adalah dua organisasi yang berbeda, mereka berdua
menyediakan e-mail untuk karyawan mereka dan melakukannya dengan cara yang sangat mirip.
Standard server mail software kemungkinan akan melayani kebutuhan kedua perusahaan cukup
baik. Sebaliknya, jika proses bisnis bahwa perangkat lunak ini dirancang untuk memungkinkan
unik dan nilai tambah (yaitu, sumber keunggulan kompetitif), COTS software dapat merusak
keunikan mereka dan merugikan perusahaan.
Fleksibilitas dan Pengendalian aplikasi perangkat lunak kustom-dikembangkan menawarkan
tingkat tertinggi fleksibilitas dan kontrol untuk organisasi. Karena tim proyek membangun sistem
dari awal, perangkat lunak dapat dibentuk menjadi bentuk apapun stakeholder (misalnya,
manajemen, pengguna akhir) ingin untuk mengambil, dan perusahaan berutang tidak ada biaya
lisensi untuk vendor perangkat lunak. Selain itu, karena perusahaan mempertahankan kontrol atas
kode, sistem dapat berkembang, setiap saat dan dengan sumber daya yang tepat, segala arah
perusahaan ingin.
tingkat kontrol tidak dapat dicapai dengan perangkat lunak COTS dibeli dari vendor, karena
rumah-rumah software perlu mengembangkan aplikasi yang melayani kebutuhan sejumlah besar
pembeli. Selain itu, software house harus memprioritaskan fitur yang akan dikodekan ke upgrade.
Biasanya, mereka adalah orang-orang yang memiliki daya tarik luas daripada permintaan niche
dari masing-masing klien.

Keuntungan Pembelian Sebagai industri perangkat lunak telah berkembang dan tumbuh secara
dramatis selama 30 tahun terakhir, tawaran off-the-rak telah menjadi komprehensif. Mungkin
dorongan terbesar di balik penggunaan aplikasi COTS telah datang dalam beberapa tahun terakhir
dari kelangsungan hidup awan terpercaya komputasi solusi-khusus, kenaikan ke menonjol dari
software-as-a-service (SaaS) solusi (lihatbagian 3). Membeli perangkat lunak dari vendor, baik di
awan atau untuk dipasang di pusat data perusahaan sendiri, menghasilkan sejumlah keuntungan
untuk organisasi pembelian.

Lebih cepat Roll-Out Sebuah organisasi yang pembelian software baru biasanya tertarik pada
fungsi pengolahan informasi memungkinkan, tidak di IT itu sendiri. Jadi seberapa cepat
perusahaan dapat “berdiri dan berjalan” dengan sistem informasi baru menjadi perhatian penting.
perangkat lunak yang dibeli secara dramatis mengurangi waktu yang dibutuhkan untuk
memperoleh perangkat lunak dan memulai proses implementasi. Daripada terlibat dalam proses
pembangunan kustom yang panjang, perusahaan penelitian dan mengevaluasi ada aplikasi sebelum
memilih salah satu. Setelah membeli aplikasi yang dipilih, tahap implementasi siap untuk
memulai.

pengetahuan Infusion Keunggulan lain yang ditawarkan oleh aplikasi off-the-rak adalah akses ke
keahlian kode dalam perangkat lunak. Karena program perangkat lunak
dapat mengaktifkan dan membatasi cara di mana pengguna menyelesaikan tugas atau menjalankan
proses bisnis (Bab 2), Sebuah organisasi yang pembelian perangkat lunak dikemas juga
mengakuisisi “cara melakukan bisnis.” Perhatikan contoh operator call center yang mengambil
pesanan dari pembeli katalog. Desain aplikasi akan menentukan urutan interaksi berlangsung
(misalnya, salam, barang yang akan dikirim, verifikasi alamat, pembayaran) dan data apa yang
diperlukan untuk menyelesaikan transaksi (misalnya, tidak ada pesanan dapat diselesaikan tanpa
nomor telepon yang valid).
Gagasan ini infus pengetahuan sekarang desain dan pemasaran alat penting untuk vendor
perangkat lunak, khususnya penyedia SaaS, yang secara proaktif mencari praktik terbaik untuk
kode mereka ke dalam aplikasi mereka. Kembali ke contoh call center, sebuah sering disebutkan
praktek terbaik dalam operasi call center adalah untuk memungkinkan interaksi personal dengan
setiap pelanggan. Dengan demikian vendor software call-center mungkin kode fitur dalam
penerapannya yang secara otomatis membawa sejarah pesanan pelanggan atau petunjuk untuk
tawaran yang ditargetkan sehingga perwakilan dapat terlibat dalam informasi-dan lebih
menguntungkan-percakapan dengan pelanggan.

ekonomis Menarik Sementara itu selalu sulit untuk menggeneralisasi ketika datang ke desain
sistem, pemeliharaan, dan biaya pengembangan, pembelian off-the-rak aplikasi biasanya
memungkinkan perusahaan untuk memanfaatkan skala ekonomi yang dicapai oleh vendor. Seperti
contoh massal diproduksi dan pakaian tailor-made, ketika vendor dapat menghasilkan banyak unit
dari aplikasi perangkat lunak yang sama, itu menikmati penurunan biaya yang, pada gilirannya,
menurunkan biaya unit tetap. Hal ini terutama berlaku dengan perangkat lunak, informasi klasik
yang baik (lihatBab 4) Ditandai dengan biaya yang sangat tinggi menghasilkan salinan pertama,
tapi diabaikan reproduksi dan biaya distribusi.

Kualitas tinggi Banyak perdebatan seputar isu kualitas perangkat lunak, dengan skeptis menunjuk
ke banyak contoh aplikasi dikemas yang memiliki bug yang signifikan. Namun rumah software
besar dengan produk yang matang akan mengarah ke anggaran pengujian yang cukup besar dan
dasar terinstal besar pengguna sebagai bukti bahwa aplikasi mereka telah dimasukkan melalui
langkah dan dengan demikian semua masalah besar telah muncul.
Beli dan Membuat
Make vs keputusan membeli biasanya diperlakukan sebagai salah satu dikotomis (yaitu,

perusahaan harus memilih satu atau pendekatan lainnya).8 Dalam prakteknya, aturan umum
praktis adalah bahwa akuisisi perangkat lunak harus lebih suka pengembangan adat ketika solusi
off-the-rak memenuhi 80% dari fungsi yang diperlukan. Tapi apa yang terjadi jika itu 20% adalah
strategis untuk bisnis Anda? Organisasi dapat mengadopsi pendekatan dicampur, pertama
memperoleh solusi COTS dan kemudian memodifikasi secara ekstensif. Ini adalah daerah lain di
mana munculnya komputasi awan berubah hal. Sebagaimana kita bahas padabagian 3, Perangkat
lunak awan vendor berinovasi dan rilis update dan fungsionalitas baru lebih cepat dari sebelumnya-
dalam beberapa kasus, mingguan! kecepatan seperti penyebaran jelas mengurangi kebutuhan
kustomisasi internal. Bahkan, banyak dimodifikasi atau aplikasi kustom dapat membatasi

kapasitas organisasi untuk memodernisasi infrastruktur atau bermigrasi mereka ke awan.9

Menjaga dengan integrasi saat ini dan tren teknologi (bagian 3), Organisasi diharapkan untuk
mengembangkan aplikasi kustom mana strategis diperlukan dan memanfaatkan configurability-
kemungkinan inhering untuk menyesuaikan aplikasi-COTS software dalam kasus-kasus lainnya.

11.3 Membangun Sendiri: Sistem Desain dan Pengembangan

Sampai munculnya ke menonjol dari industri perangkat lunak, akuisisi perangkat lunak dikemas
adalah pengecualian, bukan norma, untuk sebagian besar organisasi. tradisi panjang sekalipun,
merancang dan mengembangkan aplikasi perangkat lunak dan sistem informasi organisasi selalu
menjadi kompleks, kegagalan rawan usaha. Dilihat oleh banyak orang sebagai lebih mirip dengan
alkimia daripada ilmu yang handal, sistem desain dan pengembangan terus menakut-nakuti non-
manajer TI, yang menganggap hal itu sebagai ladang ranjau tantangan teknis, perilaku, dan
manajerial (Gambar 11.2).
Gambar 11.2. Kehidupan pengembangan sistem siklus (SDLC) seperti yang dirasakan oleh banyak
manajer
Sumber: ProjectCartoon.com

Dalam rangka untuk mengelola risiko dan kompleksitas yang terkait dengan pengembangan
adat, spesialis sistem informasi, akademisi, dan konsultan telah berkontribusi pada penciptaan
sejumlah sistem desain dan pengembangan metodologi.

Sistem Development Life Cycle

Metodologi pengembangan dua sistem yang dominan saat ini adalah siklus hidup pengembangan
sistem (SDLC) dan lincah-istilah payung dari berbagai pengembangan perangkat lunak
pendekatan ditandai dengan perkembangan pesat dan penyebaran. Pendekatan SDLC didasarkan
pada gagasan bahwa pembenaran rinci dan perencanaan adalah kendaraan untuk mengurangi risiko
dan ketidakpastian dalam upaya sistem desain dan pengembangan. Sehingga menghabiskan waktu
yang cukup di depan, tim proyek meningkatkan kemungkinan pemecahan masalah bisnis yang
tepat dengan desain sistem informasi yang tepat. Untuk alasan ini, SDLC
adalah metodologi yang sangat terstruktur di mana output dari satu tahap menjadi masukan dari
depan dan di mana kemudian berusaha tim proyek untuk menyimpan perubahan ke minimum

setelah proyek telah dimulai.10

Metodologi SDLC diartikulasikan dalam tiga fase definisi, membangun, dan implementasi-
masing-masing dibagi lagi menjadi tiga langkah (tabel 11.1).

Definisi Fase Definisi SDLC berkaitan dengan jelas mengidentifikasi fitur dari sistem informasi
yang diusulkan. Para aktor penting dalam fase ini adalah pengguna akhir calon dan manajer umum
atau fungsional yang mewakili stakeholder utama.
Dari staf sistem informasi, sistem dan analis bisnis terlibat. analis sistem sangat terampil
profesional sistem informasi yang fasih dalam kedua masalah teknologi dan komunikasi. Peran
mereka adalah untuk membantu pengguna mengidentifikasi dan mengartikulasikan persyaratan
sistem dan berfungsi sebagai penghubung dengan staf teknis (yaitu, pengembang). analis bisnis
adalah individu dengan keahlian dalam desain ulang proses bisnis serta teknologi. Mereka
membantu memastikan bahwa proses bisnis dan program perangkat lunak di jantung dari suatu
sistem informasi secara bersama-sama dioptimalkan dan bekerja dengan lancar bersama-sama.

Penyelidikan Selama penyelidikan, para pendukung sistem baru harus mengidentifikasi apa
masalah bisnis sistem akan berhubungan dengan. Manajer yang membayangkan cara-cara baru
operasi adalah kekuatan pendorong pada tahap ini, karena mereka merumuskan tujuan utama,
ruang lingkup, dan proposisi nilai dari sistem baru. Tahap ini biasanya sangat informal. Tahap
berikutnya membawa disiplin yang lebih besar untuk analisis.

Tabel 11.1. fase utama SDLC

Definisi
Analisis Kelayakan
Investigasi
Analisa sistem
 Mem
bang
un
Desain sistem
Programming
pengujian

Penerapan
Operasi instalasi
Pemeliharaan

Analisis kelayakan Dalam rangka untuk memastikan bahwa sumber daya yang langka organisasi
yang dimanfaatkan terbaik, tim proyek harus berat meneliti proyek yang diusulkan sebelum
memberikan formal hijau. Secara khusus, tim harus mengevaluasi kelayakan teknis, operasional,

dan ekonomi dari proyek.11

kelayakan teknis adalah evaluasi apakah sistem yang diusulkan adalah layak dari sudut pandang
IT. Tim harus bertanya apakah keadaan seni dalam perangkat keras, perangkat lunak, dan peralatan
telekomunikasi adalah sedemikian rupa sehingga sistem yang diusulkan akan bekerja sebagaimana
dimaksud (misalnya, itu akan memiliki kapasitas penyimpanan yang cukup dan waktu respon
dapat diterima). Sejarah perkembangan sistem baru berlimpah, dengan contoh-contoh
implementasi teknologi yang mendahului waktu mereka, sehingga merusak keberhasilan sistem.
kelayakan operasional, kadang-kadang disebut kelayakan perilaku, adalah evaluasi apakah
sistem informasi secara keseluruhan, bukan hanya komponen teknologi, adalah layak. Analisis ini
membutuhkan evaluasi dari tiga komponen lain untuk memastikan bahwa karyawan memiliki
keterampilan yang diperlukan untuk memanfaatkan teknologi baru dan bahwa mereka akan
menerima (atau dapat diberikan insentif untuk menerima) sistem kerja baru. Selama fase ini, tim
proyek harus membayangkan bagaimana proses bisnis akan didesain ulang dan harus meramalkan
driver kemungkinan resistensi pengguna dan penolakan.
kelayakan ekonomi adalah evaluasi terhadap keuangan dari sistem yang diusulkan. Sejumlah
teknik telah dikembangkan dari waktu ke waktu untuk membenarkan investasi yang diusulkan,
termasuk laba atas investasi (ROI), payback, dan perhitungan nilai sekarang bersih. Pada akhirnya,
mengevaluasi kelayakan finansial terdiri dari melakukan analisis biaya / manfaat untuk
memastikan
bahwa uang yang akan dihabiskan untuk desain sistem dan pengembangan proyek memenuhi
rintangan keuangan perusahaan untuk investasi. Kasus bisnis memberikan dasar untuk analisis ini
(lihatBab 10).
Hasil dari analisis kelayakan adalah dokumen yang berpuncak pada “pergi” atau “tidak-pergi”
rekomendasi. Pada titik ini perusahaan telah menginvestasikan sejumlah kecil sumber daya, relatif
terhadap biaya proyek penuh; sehingga jika proyek ini adalah untuk dibatalkan, ini adalah waktu
yang tepat untuk melakukannya.

Analisa sistem Setelah keputusan telah dibuat bahwa sistem bernilai mengejar, tim proyek perlu
mengidentifikasi dan mengartikulasikan persyaratan sistem. Sistem analis dan para pemangku
kepentingan (yaitu, pengguna akhir, manajemen) mengambil tengah panggung pada saat ini. Jika
sistem ini tidak hanya mengotomatisasi tugas-tugas yang ada tetapi malah memungkinkan proses
bisnis didesain ulang, analis bisnis akan bergabung dengan tim.
Dalam implementasi sistem yang besar, adalah mustahil untuk melibatkan semua pengguna
pada tahap ini; bukan, subset dari populasi pengguna bergabung dengan tim, kadang-kadang penuh
waktu. Perhatikan bahwa sangat penting untuk memilih pengguna yang mewakili lebih luas
populasi yaitu, tim harus mencakup tidak hanya pengguna yang melakukan tertinggi atau paling
berpengalaman dengan teknologi (disebut superusers) tetapi juga berkinerja dan yang paling
penting , dissenting pengguna (orang-orang yang memang mungkin menolak daripada dukungan
sistem baru).
Aspek penting lain dari keterlibatan pengguna adalah bahwa hal itu tidak harus “berpakaian
jendela” atau “manajemen kesan.” analis Sistem harus benar-benar mencari dan masukan nilai
pemangku kepentingan dalam proses. Analis sistem adalah spesialis dalam fase ini, bukan
pengguna. Oleh karena itu adalah tugas sistem analis untuk memastikan permukaan produktif dan
komprehensif persyaratan.
Sebagai hasil dari tahap ini, tim proyek menghasilkan dokumen sistem persyaratan (Gambar
11.3). Dokumen ini apa masukan sistem akan menerima, apa output akan menghasilkan, pengguna
apa yang akan memiliki akses ke informasi apa, dan sebagainya. Dokumen biasanya meliputi layar
mock-up dan skenario (Gambar 11.4) Dan dikirim ke para pemangku kepentingan untuk diperiksa
dan disetujui.
Dalam aplikasi ketat dari metodologi SDLC, setelah stakeholder menyetujui dokumen,
persyaratan sistem yang “beku” dan biaya
 perubahan masa depan, jika ada diminta, menjadi tanggung jawab para pemangku kepentingan.
Langkah ini diperlukan untuk meminimalkan dampak dari lingkup creep fenomena dimana
stakeholder menambah atau persyaratan perubahan selama fase membangun dari SDLC, sehingga
secara signifikan meningkatkan biaya dan jauh menunda pembangunan.

Gambar 11.3. kebutuhan pengguna

Gambar 11.4. skenario sampel untuk proses pemesanan hotel

Membangun Tahap membangun dari SDLC adalah yang paling teknis, dan salah satu yang
kebanyakan orang gambar ketika mereka membayangkan bagaimana perangkat lunak ini
dirancang dan dikembangkan. Fase ini adalah domain utama dari pengembang: sistem arsitek dan
programmer. Tujuannya adalah untuk mengambil dokumen persyaratan sistem dan menghasilkan
kuat, mengamankan, dan aplikasi efisien.

Desain sistem Fase membangun dimulai dengan tahap desain sistem. Pengambilan
hasil dari fase definisi (yaitu, apa aplikasi harus melakukan), arsitek menciptakan struktur sistem
(yaitu, bagaimana aplikasi akan melakukan tugasnya). Pada tahap ini, mengidentifikasi tim apa
hardware yang akan digunakan, bahasa apa yang akan diadopsi, data apa struktur yang diperlukan,
dan sebagainya. Output dari tahap ini adalah satu set yang tepat dari dokumen yang programmer
gunakan untuk menulis kode.

pemrograman Ini adalah proses menerjemahkan desain software abstrak menjadi satu set perintah
atau instruksi yang dapat dieksekusi oleh perangkat keras. Jika aplikasi membutuhkan penciptaan
database baru, struktur mereka juga dikembangkan pada tahap ini (Gambar 11.5).
Sebuah elemen penting dari tahap pemrograman, tapi satu yang pengembang sering merasa
jijik, adalah dokumentasi. dokumentasi menyeluruh dan jelas sangat penting dalam program
perangkat lunak organisasi karena mereka besar, kompleks, dan diharapkan untuk terakhir untuk
beberapa tahun. Tanpa dokumentasi yang memadai, sistem tersebut menjadi tidak mungkin untuk
mendukung dan memelihara, biarkan peningkatan sendirian dan berkembang dari waktu ke waktu.

pengujian Sementara pengujian sistem adalah suatu proses yang programmer terus-menerus
terlibat dalam ketika mereka mengembangkan, diformalkan penilaian komponen dan kemudian
aplikasi lengkap merupakan tahap penting dalam SDLC. Sementara sebagian besar non-IT
personil jarang berpikir tentang pengujian, tahap ini dapat mengambil banyak waktu dan sumber
daya sebagai tahap pemrograman. Tahap pengujian diartikulasikan dalam pengujian alpha, yang
dilakukan oleh pengembang sendiri, dan pengujian beta, dilakukan dengan merilis versi beta untuk
satu set terbatas pengguna yang sebenarnya yang menggunakannya dan melaporkan setiap masalah
yang mereka mengidentifikasi.
Perhatikan bahwa tujuan dari tahap pengujian tidak untuk mengidentifikasi dan benar semua
kemungkinan bug yang mengganggu sistem, karena ini adalah tidak ekonomis dan jarang
dibutuhkan. Sebaliknya, tahap pengujian dirancang untuk menekankan sistem, untuk memastikan
bahwa itu dapat melakukan dalam keadaan produksi, dan untuk memperbaiki kesalahan yang
paling penting. Tujuannya adalah untuk melepaskan aplikasi ketika itu cukup baik, bukan ketika
itu adalah sempurna.

Penerapan Setelah perangkat lunak telah dikembangkan dan diuji,

tim proyek perlu memastikan bahwa itu benar terintegrasi dengan komponen lain dari sistem
informasi. Ini adalah tahap pelaksanaan, waktu yang sangat halus ketika keterampilan manajemen
proyek dan keterlibatan eksekutif sangat penting.

Gambar 11.5. desain database yang mendasari sistem hotel manajemen properti

Instalasi Selama tahap instalasi, sistem ini dimuat pada perangkat keras produksi dan database
akan diisi. Instalasi biasanya berlangsung selama periode lambat untuk organisasi dan, jika
mungkin, sementara sistem ini tidak diperlukan (misalnya, selama akhir pekan, di malam hari).
Jika sistem yang ada digantikan, perusahaan bermigrasi dari yang lama ke yang baru mengikuti
salah satu dari empat pendekatan (Gambar 11.6):
Gambar 11.6. migrasi pendekatan

• Paralel. Sistem lama dan baru dijalankan untuk waktu bersama-sama. Pendekatan ini
adalah yang paling konservatif, karena menawarkan asuransi terhadap kegagalan
aplikasi baru. Hal ini juga paling mahal karena membutuhkan redundansi yang
signifikan dari upaya. Dalam beberapa kasus, pendekatan ini adalah satu-satunya
pilihan (misalnya, sistem yang harus beroperasi 24/7/365).
• Langsung. Sistem lama tiba-tiba dihentikan, dan pemotongan perusahaan ke yang baru.
Ini adalah yang paling pendekatan radikal tapi satu yang kadang-kadang tidak dapat
dihindari (misalnya, sistem lama berhenti berfungsi).
 • bertahap. Sistem baru semakin menggantikan fungsi dari yang lama. Pendekatan ini
paling cocok untuk aplikasi modular atau componentized yang dapat digulirkan secara
bertahap.
• Pilot. Nah cocok untuk operasi multi unit (misalnya, hotel, rantai pengecer),
pendekatan ini memungkinkan perusahaan untuk menjalankan sistem baru di salah
satu unit usaha atau di salah satu departemen perusahaan sebelum bergulir keluar
sepenuhnya.

Di luar aspek teknis dari tahap instalasi, ada dua proses penting yang terjadi saat ini: pelatihan
pengguna akhir dan manajemen perubahan. pelatihan pengguna akhir biasanya terjadi dalam
pengaturan formal, seperti ruang kelas atau laboratorium komputer seadanya. Perubahan
manajemen adalah proses smoothing transisi dari cara berbagai pemangku kepentingan
berinteraksi dengan sistem sebelumnya dan melakukan pekerjaan mereka untuk praktek kerja baru.
resistensi pengguna dan inersia adalah bahaya terbesar pada saat ini. Sampai-sampai para
pemangku kepentingan telah terlibat aktif dalam tahap awal SDLC dan desain sistem, fase ini akan
kurang traumatis, sehingga meminimalkan risiko penolakan.

Operasi Pada tahap ini, sistem ini dan berjalan, dan organisasi mulai menggunakannya. Tim
proyek dibubarkan dan sistem baru menjadi aset tetap perusahaan untuk dipertahankan dan
dikelola.

Pemeliharaan Setelah sistem di tempat dan dan berjalan, baik kesalahan yang telah lolos tahap
pengujian dan perangkat tambahan yang telah lolos tahap definisi persyaratan mulai muncul.
Pemeliharaan adalah proses pengumpulan informasi ini, memprioritaskan permintaan, dan
menerapkan kedua perbaikan dan peningkatan. Perhatikan bahwa sebagai komprehensif dan
dirancang dengan baik sebagai sistem baru mungkin, organisasi dalam evolusi yang berkelanjutan.
Akibatnya, dari waktu ke waktu itu adalah normal bagi kesenjangan muncul antara fungsi sistem
saat ini dan kebutuhan perusahaan. (Ingat ini waktu berikutnya Anda tergoda untuk bertanya, “Apa
yang mereka pikirkan ketika mereka merancang sistem ini ?!”)
Kesenjangan fungsi ditutup secara berkelanjutan dengan cara upgrade dan penambahan sampai
pemeliharaan seperti menjadi ekonomis
tidak layak dan manajemen membuat kasus untuk pengembangan sistem informasi baru. Untuk
alasan ini, beberapa penulis telah mulai menunjukkan bahwa tradisional sekuensial pendekatan

SDLC yang perlu dievaluasi kembali.12

Keuntungan Pendekatan SDLC SDLC adalah metodologi yang sangat terstruktur yang
menyediakan pendekatan sistematis untuk mengurangi ketidakpastian dan risiko yang terkait
dengan sistem desain dan pengembangan proyek. Ini jelas mengidentifikasi peran dan harapan
bagi anggota tim proyek, dan menawarkan cetak biru untuk bagaimana individu harus berinteraksi.
Dengan menuntut pembenaran dan persyaratan definisi menyeluruh, itu sangat baik cocok untuk
proyek-proyek skala besar di mana perubahan yang terjadi selama pembangunan atau
implementasi bisa sangat mahal.
SDLC juga menawarkan kendaraan untuk komunikasi dan negosiasi antara tim proyek dan
banyak stakeholder proyek. Ia melakukannya dengan mengharuskan evaluasi dan persetujuan
kiriman untuk setiap fase, sehingga merangsang diskusi, memfasilitasi identifikasi prioritas, dan
permukaan tersembunyi trade-off.

keterbatasan Sementara metodologi SDLC telah berkembang dari pendekatan air terjun
tradisional menjadi proses yang lebih berulang di mana desainer dan pengembang diperbolehkan
beberapa evaluasi ulang dari tahap sebelumnya, SDLC tetap menjadi pendekatan yang sangat
terstruktur. Dengan demikian kritik menunjukkan bahwa itu menciptakan overhead besar dalam
hal waktu dan biaya dan tidak memungkinkan tim proyek untuk benar mengatasi perubahan yang
tak terelakkan yang terjadi selama kehidupan proyek yang kompleks.

prototyping
Menyadari keterbatasan yang melekat dalam metodologi SDLC, pendekatan prototyping berakar
pada gagasan bahwa tidak mungkin untuk secara jelas memperkirakan dan rencana rinci seperti
usaha yang kompleks seperti sistem informasi desain dan pengembangan proyek. Sebaliknya tim
ini lebih baik dilayani dengan tetap gesit dan iterasi cepat melalui beberapa desain untuk nol dalam
pada satu optimal.
Penerimaan tumbuh metodologi prototyping telah diaktifkan oleh
alat-alat yang mempercepat proses pembangunan, seperti bahasa pemrograman nonprocedural.
Alat-alat ini memungkinkan pengembang untuk secara cepat membuat kerja (atau sebagian
bekerja) model sistem yang diusulkan dan umpan balik mengumpulkan stakeholder tentang desain
sistem, fungsi, antarmuka pengguna, dan sebagainya.

Prototyping Life Cycle Salah satu aplikasi dari metodologi prototyping adalah dalam batas-batas
SDLC, sebagai cara untuk kebutuhan pengguna Menimbulkan dan mencari masukan ke dalam
desain antarmuka pengguna. Nilai dari pendekatan ini berasal dari fakta bahwa itu adalah mudah
bagi pengguna untuk bereaksi terhadap prototipe daripada bagi mereka untuk membayangkan dan
mengartikulasikan persyaratan dalam abstrak. Selain itu, dengan melibatkan pengguna dalam
pengembangan ujung depan aplikasi, tim desain dapat menumbuhkan dukungan mereka dan
meningkatkan peluang penerimaan sistem final.
Namun, prototyping dapat digunakan sebagai alternatif untuk SDLC untuk mengembangkan
sebuah sistem yang lengkap sesuai dengan langkah-langkah berikut:

Persyaratan Definisi Pada tahap ini tim pengembangan berusaha persyaratan dasar. Tingkat presisi
yang dibutuhkan jauh lebih sedikit daripada yang dibutuhkan dalam SDLC karena persyaratan
tidak dibekukan pada saat ini. Sebaliknya, pemahaman adalah bahwa umpan balik masa depan dan
modifikasi berat akan membentuk sistem.

Prototipe awal Berbekal persyaratan dasar, tim mengembangkan iterasi pertama dari sistem.
Perangkat lunak ini bisa menjadi hanya shell (yaitu, antarmuka pengguna nonfungsional), aplikasi
sebagian fungsional, atau “pertama-of-a-seri” prototipe yang berfungsi penuh.

Evaluasi Pada saat ini para pemangku kepentingan meninjau prototipe dan memberikan umpan
balik pada desain saat ini serta permintaan untuk perangkat tambahan dan fungsionalitas baru.

Revisi Berdasarkan umpan balik yang dihasilkan selama tahap evaluasi,

tim pengembangan desain dan kode perubahan yang diminta. Fase ini mengarah pada prototipe
baru yang akan disampaikan kepada stakeholder untuk evaluasi. Perhatikan bahwa setiap saat
selama iterasi ini tim dan para pemangku kepentingan dapat menyimpulkan bahwa tidak ada
investasi lebih lanjut dalam proyek dibenarkan. Dalam hal ini perusahaan berhenti upaya
pembangunan.

Penyelesaian Setelah stakeholder dan tim pengembangan puas dengan fungsionalitas dari sistem,
proses evaluasi / revisi berulang berhenti dan tim pengembangan memfinalisasi sistem. Pada tahap
ini, kode pengembang fitur penting yang pengguna biasanya tidak permintaan (misalnya,
keamanan, administrasi). Dokumentasi dan pengujian tindak, sebelum rilis resmi dari sistem.

Keuntungan Pendekatan Prototyping Mengingat karakteristik pendekatan prototyping, sistem

yang dikembangkan dengan cara ini cenderung lebih cepat disampaikan dan lebih dekat dengan
harapan para pengguna, karena para pemangku kepentingan lebih terlibat seluruh upaya
pembangunan. Dengan demikian prototyping paling cocok untuk proyek-proyek skala kecil dan
orang-orang yang secara radikal mengubah cara di mana pekerjaan dilakukan. Pendekatan
prototyping juga memungkinkan perusahaan untuk bereksperimen dengan teknologi baru dan
fungsionalitas sistem baru karena membutuhkan investasi yang lebih kecil dari sumber daya dari
SDLC sebelum produk dapat dievaluasi-sehingga membatasi risiko dan biaya hangus.

keterbatasan Premi bahwa pendekatan prototyping menempatkan pada kecepatan dan

fungsionalitas pembangunan dapat menyebabkan tim untuk merilis sistem yang kurang dari
keamanan, ketahanan, dan keandalan sudut pandang. Sistem dibangun dengan menggunakan
pendekatan prototyping biasanya kurang benar-benar teruji dan didokumentasikan dibandingkan
mereka yang menggunakan pendekatan yang lebih terstruktur. Selain itu, laju iterasi dan pelepasan
prototipe baru dapat menyesatkan pihak yang meremehkan kompleksitas pengembangan

perangkat lunak. Konsekuensinya adalah merajalela scope creep.13 Keterbatasan ini membuat
pendekatan prototyping tidak cocok untuk upaya pembangunan skala besar dan sistem yang
kompleks.
Pengembangan Agile
Sebuah generasi baru pengembangan perangkat lunak pendekatan telah diambil terus-baru ini,
sebagian karena meningkatnya popularitas prototyping. Pendekatan pengembangan perangkat
lunak secara kolektif diberi label sebagai metodologi pengembangan perangkat lunak tangkas dan

hari ini banyak diadopsi oleh organisasi.14 Meskipun proyek-proyek pembangunan masih
mengikuti air terjun didirikan (50%) dan model iteratif (25%) dan hanya menggunakan seperempat

tangkas metodologi, proyek perangkat lunak lebih menjadi lincah.15

Para pendukung filosofi pengembangan perangkat lunak tangkas ditangkap dalam sebuah
dokumen yang disebut “manifesto tangkas.” Pernyataan pembukaan dalam dokumen yang

berbunyi,16

Kami mengungkap cara yang lebih baik untuk mengembangkan perangkat lunak dengan
melakukan hal itu dan membantu orang lain melakukannya. Melalui karya ini kita telah
datang ke nilai:

• Individu dan interaksi atas proses dan alat-alat

• software Kerja lebih dokumentasi yang komprehensif
• kolaborasi pelanggan negosiasi kontrak lebih
• Menanggapi perubahan selama mengikuti rencana

Artinya, sementara ada nilai dalam item di sebelah kanan, kami nilai item di
sebelah kiri lebih.

Manifesto tangkas jelas mengidentifikasi prioritas dan karakteristik kunci dari metodologi
tangkas. Pertama dan terpenting adalah kemampuan beradaptasi dan kecepatan. metode Agile
tidak memanggil untuk jumlah besar perencanaan yang menjadi ciri khas metodologi tradisional.
pendukung Agile percaya bahwa perencanaan untuk semua persyaratan dan kontinjensi tidak
mungkin di semua tapi sepele perkembangan sistem. perencanaan yang signifikan akan sebenarnya
menjadi bumerang dan membatasi kemampuan tim pengembangan untuk menyesuaikan diri
dengan informasi baru yang tak terelakkan. Oleh karena itu pengembang Agile fokus pada
pengembangan aplikasi dengan kecepatan dan melepaskan sistem sering-biasanya dalam waktu
kurang dari sebulan. Ini adalah iterasi yang cepat ini pembangunan dan rilis yang akan muncul
persyaratan yang akurat dan cepat memungkinkan tim pengembangan untuk konvergen ke sistem
yang memenuhi harapan pelanggan.
Sebuah ciri khas kedua metodologi pengembangan tangkas adalah
kerja sama tim di kantor-kantor ruang terbuka yang memfasilitasi komunikasi. pendukung Agile
menganjurkan penggunaan tim lintas-fungsional kecil dengan perwakilan pelanggan dan harian
pertemuan tatap muka. Dalam rangka untuk mengatur pekerjaan dan mempertahankan jadwal
agresif yang mencirikan tangkas proyek, pengembang “chunk” pekerjaan ke dalam komponen
dikelola belum berdiri sendiri. Tim kemudian iterates melalui semua tahapan pembangunan-dari
persyaratan elisitasi melalui pengujian dan penerimaan pelanggan. Karakteristik yang menarik dari
metodologi tangkas terdiri dari pengaturan waktu tetap dan sumber daya untuk memberikan
fungsionalitas yang diharapkan.
Scrum, dimulai oleh Jeff Sutherland pada tahun 1993, adalah yang paling digunakan antara
metodologi tangkas karena kemampuannya untuk menangani kebutuhan pengguna berubah
dengan cepat. Scrum kemajuan pengembangan perangkat lunak melalui serangkaian iterasi disebut
sprint, yang berlangsung biasanya dua sampai empat minggu. Sprint umumnya dimulai dengan
tahap perencanaan singkat (dan untuk panjang sprint tim bertemu setiap hari-Scrum harian) dan
akhir dengan review dan retrospektif. Prinsip di balik sprint adalah bahwa pada akhir setiap lari,
perangkat lunak harus siap untuk pengiriman ke prinsip client-setidaknya dalam. Sementara
metodologi pengembangan tangkas masih relatif baru dan dalam fluks, mereka telah mendapatkan
penerimaan dalam komunitas pengembangan perangkat lunak dan sekarang diterapkan dalam
proyek-proyek dari berbagai kompleksitas.

Pengembangan outsourcing
program perangkat lunak kustom-dirancang semakin dikembangkan oleh rumah perangkat lunak
yang “mengisi” untuk sistem informasi perusahaan profesional. Pengaturan ini, biasanya disebut
outsourcing pengembangan perangkat lunak, sangat bervariasi, dengan beberapa perusahaan
hanya melakukan outsourcing pemrograman dan pengujian tahap, sementara yang lain resor untuk
penyedia eksternal untuk melihat mereka melalui seluruh siklus hidup pengembangan sistem.
Outsourcing proyek pengembangan perangkat lunak telah meningkat secara dramatis dalam
popularitas setelah adopsi Internet. program perangkat lunak, sebagai informasi klasik yang baik
(Bab 4), Dapat dirancang dan dikembangkan di mana saja di dunia. Sebagai akibatnya,
meningkatkan proporsi pengembangan perangkat lunak kustom untuk organisasi adalah
kode luar negeri. Pertimbangkan tim virtual pengembang sebagai contoh. proyek perangkat lunak
semakin diselesaikan oleh tim pengembangan yang bekerja sama tetapi tidak secara fisik terletak
di kantor yang sama. Sementara pertimbangan biaya mungkin datang ke pikiran sebagai alasan
utama untuk membangun tim virtual, penelitian yang dilakukan oleh Konsorsium Cutter
menunjukkan bahwa lebih dari 85% responden melihat kemampuan untuk kolam bakat yang

paling berkualitas di proyek sebagai driver utama untuk adopsi mereka.17

Dengan adopsi luas dan internasionalisasi pengembangan perangkat lunak kustom, satu set alat
untuk mengevaluasi kualitas penyedia telah muncul. Yang paling populer, Capability Maturity
Model (CMM), peringkat organisasi pengembangan perangkat lunak sesuai dengan kemampuan
mereka untuk perangkat lunak kualitas produk pada skala 1 sampai 5 dengan mengevaluasi
serangkaian proses standar berpikir untuk menentukan kualitas perangkat lunak. Bekerja pada
CMM dimulai pada Software Engineering Institute (SEI) di Carnegie Mellon University (CMU)
di awal 1990-an sebagai sebuah proyek yang didanai oleh Departemen Pertahanan Amerika
Serikat (DoD). Departemen Pertahanan sedang mencari untuk lebih memahami bagaimana hal itu
bisa sistematisasi proses pengembangan perangkat lunak sehingga dapat menjamin pembangunan
yang handal dan menghindari baik kegagalan dan ketidakpastian yang ditandai itu. Sebuah
perpanjangan alami dari upaya ini adalah untuk mempekerjakan CMM untuk mengevaluasi vendor
dan kontraktor perangkat lunak. CMM ini didasarkan pada gagasan inti yang pelaksanaannya dapat
diandalkan dan konsisten dari serangkaian tertentu proses merupakan tingkat yang lebih tinggi
kematangan pengembangan perangkat lunak dan, sebagai akibatnya, memastikan produk
perangkat lunak berkualitas tinggi (Gambar 11.7).
CMM asli telah berkembang secara signifikan selama bertahun-tahun, dan sebagai bukti
keberhasilannya, sekarang digunakan untuk mengevaluasi dan meningkatkan kualitas banyak
proses organisasi lainnya (misalnya, layanan pelanggan, akuisisi). rumah perangkat lunak saat ini,
terutama mereka yang terlibat dalam pengembangan pelanggan outsourcing, mencari Capability

Maturity Model Integration (CMMI) sertifikasi,18 dan Anda, sebagai pembeli jasa mereka, harus
meminta informasi tersebut. CMMI Institute di Carnegie Mellon adalah yang bertanggung jawab
atasproses sertifikasi dan secara berkala merilis statistik agregat (Gambar 11.8).
Salah satu proposisi nilai pokok outsourcing pengembangan perangkat lunak kustom adalah
rasio biaya / kualitas unggul. Perusahaan di negara-negara dengan biaya hidup yang tinggi, seperti
Amerika Utara atau Eropa Barat, dapat outsourcing pengembangan ke negara-negara seperti India,
Irlandia, atau China, dengan kolam besar
 insinyur perangkat lunak yang sangat terampil dan programer dan biaya yang lebih rendah dari
hidup (yaitu, upah yang lebih rendah). Outsourcing perkembangan ke daerah ini dari dunia
memungkinkan perusahaan untuk menerima produk-produk berkualitas unggul di sebagian kecil
dari biaya pengembangan internal (Gambar 11.9).

Gambar 11.7. Lima tingkat kematangan proses perangkat lunak

Sumber: Berdasarkan Tim Produk CMMI (2010), CMMI untuk Pembangunan, Versi 1.3, Laporan
Teknis (Carnegie Mellon University / Software Engineering Institute), CMU / terhadap barang
2010-TR-033
Gambar 11.8. tingkat proses kematangan tren organisasi dinilai
Sumber:Diadaptasi dari Maturity Profil Laporan (2015), CMMI Institute
Gambar 11.9. Distribusi perusahaan CMMI-dinilai di dunia
Sumber: Diadaptasi dari Maturity Profil Laporan (2015), CMMI Institute

11.4 Membeli Aplikasi Off-the-Shelf

SDLC menyediakan dasar untuk proses seleksi sistem dan pembelian bahwa organisasi gunakan
untuk merancang dan mengembangkan sistem informasi berdasarkan program software off-the-
shelf (tabel 11.2). Proses seleksi sistem sering dimulai ketika manajer belajar tentang kemampuan
aplikasi baru yang sedang diiklankan, dijelaskan dalam pers, atau dipromosikan oleh perusahaan
konsultan. Mengikuti proses sistem seleksi penting karena memungkinkan penyelidikan sistematis
aplikasi ini serta produk yang bersaing
-thus memastikan bahwa semua masalah dianggap dan bahwa perusahaan memilih solusi terbaik
untuk kebutuhan saat ini.
Definisi
Kedua penyelidikan dan analisis kelayakan tahap secara kualitatif sama dengan yang di SDLC.
Pada saat ini, para pendukung sistem mengartikulasikan visi untuk sistem informasi yang
diusulkan dan mengevaluasi kelayakan teknis, operasional, dan ekonomi. Hal ini dalam tahap yang
tersisa dari fase definisi bahwa keanehan utama dari proses seleksi sistem terjadi.

Analisa sistem Selama tahap analisis sistem, panitia seleksi berfokus pada memunculkan fungsi
khusus yang diperlukan dari sistem yang diusulkan. Seperti dengan SDLC, fase ini memerlukan
interaksi analis sistem dan stakeholder. Namun, tingkat presisi dan detail yang dicari oleh panitia
seleksi kurang dari yang dibutuhkan untuk pengembangan kustom. Tujuan di sini adalah memiliki
cukup pemahaman tentang persyaratan sistem untuk merumuskan kriteria evaluasi.

Merumuskan Kriteria Evaluasi Sistem seleksi adalah upaya terstruktur untuk mengevaluasi
semua solusi perangkat lunak yang tersedia secara komersial yang dapat mengaktifkan sistem
informasi yang diusulkan. Untuk melakukannya, perlu untuk mengembangkan satu set metrik yang
dapat diterapkan secara seragam untuk semua paket diselidiki. Kriteria juga harus setuju untuk
komunikasi untuk vendor perangkat lunak dengan cara permintaan proposal (RFP) proses.
Pendekatan yang umum adalah dengan menggunakan dokumen persyaratan sistem untuk
mengidentifikasi fitur yang aplikasi yang sesuai harus memiliki dan kelompok mereka ke dalam
tiga kategori:

Tabel 11.2. Tahapan proses sistem seleksi

Definisi
analisis penyelidikan
analisis Kelayakan
Sistem
Merumuskan kriteria evaluasi
 daftar pendek kompilasi dari vendor
Kompilasi dan mendistribusikan request for proposal (RFP)
Mengevaluasi alternatif
bernegosiasi kontrak

Membangun
desain sistem (kustomisasi) Programming
(kustomisasi)
pengujian

Penerapan
Operasi instalasi
Pemeliharaan

• fitur penting. Mereka kemampuan yang sistem harus memiliki. Sistem yang
kehilangan salah satu dari fitur ini secara otomatis dibuang.
• fitur nilai tambah. Mereka kemampuan itu, sementara tidak penting, menawarkan
keuntungan yang signifikan untuk mana perusahaan akan bersedia membayar premi.
• fitur yang tidak penting. Mereka kemampuan yang “baik untuk memiliki” tapi
menghasilkan keuntungan yang nyata kecil untuk mana perusahaan tidak bersedia
untuk membayar premi.

Kompilasi Daftar Pendek Vendor Berbekal kriteria evaluasi, panitia seleksi mencari informasi
tentang solusi yang ada. Website, pers perdagangan, penjual brosur, dan pameran perdagangan
adalah sumber yang layak informasi. Informasi yang dikumpulkan digunakan untuk
mengidentifikasi daftar singkat awal vendor.
Tahap ini penting karena dua alasan. Pertama, menciptakan RFP yang menghasilkan respon
berkualitas tinggi yang ditargetkan, dan kemudian mengevaluasi tanggapan tersebut, memakan
waktu. Kedua, produk yang tidak memenuhi persyaratan yang diperlukan dapat
diidentifikasi cukup cepat, dan vendor akan menghargai tidak diminta untuk merespon RFP bahwa
mereka tidak memiliki kesempatan untuk memenuhi.

Kompilasi dan Mendistribusikan RFP RFP adalah dokumen komunikasi formal yang digunakan
untuk memperoleh substansial, informasi rinci dari vendor terpilih. Sebagian besar organisasi
memiliki template untuk dokumen tersebut. RFP harus menjelaskan apa panitia seleksi telah
diidentifikasi sebagai persyaratan sistem kritis, lingkungan di mana sistem akan digunakan, dan
setiap metrik kinerja yang diperlukan dan harapan.
Setelah distribusi ke vendor terpilih, mereka yang tertarik akan menanggapi RFP. Tim seleksi
harus meminta vendor untuk mematuhi ke template, membuat cross-perbandingan dari aplikasi
yang sederhana, dan harus meminta informasi harga. Vendor juga harus memberikan informasi
harga tersebut sesuai dengan template perusahaan, memastikan bahwa mekanisme harga untuk
aplikasi, kustomisasi, dan pemeliharaan dan upgrade yang jelas dan dapat dibandingkan antar
vendor. Akhirnya, panitia seleksi harus menentukan batas waktu dimana vendor harus merespon
untuk dipertimbangkan.

evaluasi Alternatif Setelah semua vendor tertarik telah merespon RFP, solusi bersaing dievaluasi
menggunakan kriteria yang dikembangkan sebelumnya. Panitia seleksi mengkompilasi daftar
vendor atas dan mencari informasi lebih lanjut diperlukan untuk membuat keputusan akhir. Ini
termasuk di tempat demonstrasi, evaluasi situs referensi, dan seperti. Hasil dari tahap ini dalam
proses seleksi adalah daftar peringkat-memerintahkan calon diterima.

bernegosiasi kontrak Negosiasi dapat relatif cepat dan sederhana, atau mereka dapat menjadi
proses yang sangat terlibat yang membutuhkan masukan dari para profesional dan penasihat
hukum. Tujuan dari panitia seleksi adalah untuk menyusun dan menandatangani kontrak yang
menyediakan perusahaan dengan solusi yang dibutuhkan dan insulates dari risiko di masa
mendatang. elemen umum dari negosiasi adalah komponen dan besarnya biaya (misalnya,
instalasi, pelatihan, kustomisasi, pemeliharaan, upgrade), kewajiban akhirnya dan perjanjian
tingkat layanan, kontrol atas kekayaan intelektual, dan sejauh mana modifikasi diperbolehkan.
Membangun
Tahap membangun di cermin proses seleksi sistem yang dari SDLC tetapi jauh lebih sempit dalam
lingkup. Ketika program perangkat lunak yang akan diinstal tanpa konfigurasi atau kustomisasi,
seperti halnya dengan aplikasi sederhana, perusahaan dapat bergerak langsung ke pengujian formal
dan implementasi. Namun, seperti yang telah disebutkan di atas, hal ini menjadi semakin umum
untuk organisasi yang membeli aplikasi off-the-rak untuk mengkonfigurasi dan menyesuaikan

mereka secara ekstensif.19

Sejauh kustomisasi diperlukan, perusahaan akan terlibat dalam desain sistem dan pemrograman
perangkat tambahan yang diperlukan. Ini adalah di mana kontrak tertulis erat menjadi penting,
karena proses kustomisasi dapat menambah waktu dan biaya untuk proyek. Kontrak harus
menentukan siapa yang bertanggung jawab untuk menyesuaikan aplikasi-vendor, perusahaan, atau
pihak ketiga (misalnya, perusahaan konsultan independen, integrator) -dan kondisi usaha
kustomisasi (misalnya, jadwal).
Apakah disesuaikan atau tidak, perusahaan harus menguji sistem. Dalam kasus aplikasi off-
the-rak, tahap pengujian sebagian besar berkaitan dengan kinerja sistem daripada dengan
identifikasi dan koreksi bug.

Penerapan
Fase implementasi juga sangat mirip dengan yang dijelaskan sebelumnya mengenai SDLC.
Menariknya, bahkan dalam kelas yang sama dari aplikasi perangkat lunak (misalnya, ERP), suatu
perusahaan dapat memilih pendekatan yang berbeda untuk bergerak dari yang lama ke sistem baru.
Catatan juga bahwa tingkat perubahan proses dan pelatihan yang dibutuhkan untuk mendapatkan
aplikasi buy-in dari pengguna biasanya lebih besar ketika melaksanakan off-the-rak. Hal ini karena
program dikemas tidak dirancang dengan kekhasan organisasi Anda dalam pikiran. Sebaliknya
rumah software membangun program untuk menarik pasar seluas mungkin.
Meminta masukan pemangku kepentingan selama seleksi dan evaluasi solusi bersaing adalah
salah satu cara untuk mendaftarkan mereka dalam proses dan mengurangi risiko penolakan.
Namun, Anda harus tetap berencana untuk menginvestasikan sumber daya yang cukup selama fase
implementasi untuk mengatur aplikasi, melatih karyawan, dan terlibat dalam manajemen
perubahan-terutama ketika
aplikasi yang lebih besar dalam lingkup dan memaksa perubahan dalam praktek kerja tradisional.

DevOps
Paradigma tangkas telah disangkal dampak praktek-praktek pembangunan dan telah baru-baru ini
memperluas pengaruhnya ke IT operasi juga. Secara historis, telah ada pembagian antara
pengembang, orang-orang yang bertugas menciptakan fungsi baru sistem, dan operasi, orang-
orang yang bertanggung jawab atas penggelaran dan menjalankan sistem setelah selesai. Anda
dapat melihat orang-divisi di SDLC dan pemisahan proses pengembangan dan implementasi.
Dalam kasus stereotip terburuk, operasi (Ops) anggota tim melihat pengembang sebagai terputus
dari dunia nyata dari lingkungan produksi. Individu tidak peduli dengan isu-isu pragmatis operasi
bisnis ingin setiap fitur baru yang mereka dirancang dan dibangun untuk segera dikerahkan.
Pengembang (Pengembang), di sisi lain, melihat tim Ops sebagai sekelompok lambat, individu
risiko yang merugikan diatur dalam cara mereka dan enggan untuk perubahan. Untuk mengurangi
memutuskan antara pembangunan dan operasi, pendekatan baru, umumnya disebut DevOps,
adalah memegang.
DevOps, pengembangan dan operasi, sebagai istilah menyiratkan, adalah pendekatan terpadu
terinspirasi oleh gerakan lincah. DevOps dirancang untuk struktur kerjasama yang sedang
berlangsung pengembang dan operasi tim dalam sebuah organisasi. Tujuannya adalah untuk
membangun rasa saling percaya dan pengertian. Lebih kongkrit, yang DevOps pendekatan
berusaha untuk mengurangi jumlah ulang perangkat lunak dan komunikasi overhead yang berasal
dari kurangnya koordinasi antara kedua kelompok (lihattabel 11.3). Misalnya, penundaan dalam
penyebaran akan mempengaruhi siklus pengembangan sebagai umpan balik dari pelanggan
tertunda dan downtime yang tidak produktif disuntikkan dalam proses pembangunan. Mengingat
DevOps memproses secara keseluruhan, overhead berkurang dengan mengotomatisasi dan
merampingkan proses penyebaran.
DevOps teknik memanfaatkan berbagai alat penyebaran cepat untuk mendukung integrasi
berkesinambungan, penyebaran, rilis, dan kegiatan operasi. Karena DevOps adalah seperangkat
prinsip dan praktek, alat khusus bervariasi antara organisasi, tim, dan bahkan rilis. Tim
pengembangan mungkin memutuskan untuk menggunakan Eclipse, sebuah lingkungan
pengembangan terintegrasi (IDE), untuk menulis dan debug kode. Eclipse kemudian dapat
dikonfigurasi untuk bekerja dengan GitHub, yang
memimpin sumber online kode repositori, untuk mempertahankan sistem yang konsisten dan
terpusat untuk melacak dan rilis perangkat lunak kontrol. Jenkins, alat otomatisasi, kemudian bisa
dikonfigurasi untuk secara rutin membangun dan memulai lingkungan virtual di Amazon Elastic
Cloud sekali kode baru dirilis. Akhirnya, nagios dapat digunakan untuk memantau penggunaan
aplikasi dan infrastruktur TI dan memberikan umpan balik langsung dan berharga tentang
bagaimana ini melakukan aplikasi. Meskipun tidak penting bagi Anda untuk mengingat alat
khusus, sangat penting bagi Anda untuk menghargai lingkungan kerja yang berbeda instrumen ini
membuat. Dalam pelaksanaan yang ketat dari SDLC, penyebaran bahkan tidak dapat direncanakan
sampai pengembang menyelesaikan tahap membangun dan secara resmi menyerahkan tanggung
jawab kepada tim operasi. Sebaliknya, di bawah DevOps paradigma,

Tabel 11.3. DevOps prinsip dan implikasi

inspirasi prinsip- Implikasi

prinsip
Kepercayaan Dapatkan semua pemangku kepentingan proses untuk bekerja secara
efektif bersama-sama melalui loop umpan balik disiplin
prestasi Mengotomatisasi mana mungkin untuk mengurangi penundaan dan
biaya overhead dan terlibat dalam metrik bersama
Komunikasi dan Mengembangkan alat untuk mendukung aktivitas otomatis
kolaborasi pemantauan dan pelacakan dan repositori bersama
pembangunan Menyediakan perkembangan pesat (sehingga cenderung
berkelanjutan dan mengakomodasi tangkas metode) tanpa kualitas scarifying dan inovasi
penyebaran

Menanamkan logika perbaikan terus-menerus, DevOps bersama-sama meningkatkan perangkat

lunak, lingkungan, infrastruktur, dan proses pengiriman keseluruhan, memungkinkan perusahaan
untuk fokus pada inovasi yang cepat. Seperti Kurt Bittner, analis utama di Forrester Research

mengatakan, “Jika tangkas adalah pembuka, pengiriman terus menerus adalah headliner itu.”20
Ini adalah DevOps mendekati, memanfaatkan alat-alat baru untuk penyebaran perangkat lunak
yang cepat, yang memungkinkan ini “pengiriman terus menerus.” Pertimbangkan Duetto, startup
manajemen pendapatan kita bahas di
Bab 1. Duetto membanggakan diri pada merilis perangkat lunak untuk klien dua sampai tiga kali
per minggu: “Teknisi kami, dalam kemitraan dengan tim produk, mempertahankan kecepatan iri
dua sampai tiga rilis per minggu kaya fitur dan stabil kode, dan pelanggan kami merasakan

perbedaan .”21

11.5 Pengembangan Open Source

Perangkat lunak open source tidak lagi tren yang sedang berkembang. Hari ini solusi open source
adalah pilihan yang layak bagi manajer untuk dipertimbangkan ketika merencanakan desain sistem
baru dan implementasi. Gartner memperkirakan bahwa kode sumber terbuka hadir dalam
portofolio perangkat lunak mission-critical (bukan hanya aplikasi!) Dari 90% dari arus utama

organisasi TI di seluruh dunia.22

Kecenderungan menuju penggunaan perangkat lunak open source mendapatkan momentum
yang signifikan dengan munculnya Internet, tapi tetap hari ini kesempatan yang penting dan
berkembang TI untuk organisasi modern. Linux, sistem operasi yang berjalan di sebagian besar
pusat data, masih merupakan contoh terbaik dari pengembangan perangkat lunak open source.
Tapi solusi open source sekarang mainstream dengan nama-nama rumah tangga seperti Android,
Apache Web Server, Apache Hadoop, yang WildFly (sebelumnya JBoss), MySQL RDBMS,
Eclipse IDE, dan MongoDB. proyek sumber ini terbuka matang ke dalam sistem dan aplikasi yang
sering produk industri terkemuka di kategori masing-masing. Saat ini banyak kode bahwa mesin
berjalan mutakhir aplikasi pembelajaran (lihatBab 12), Dari visi komputer untuk pengenalan suara,
yang tersedia untuk di-download di GitHub dan terima kasih dapat digunakan kembali bebas ke
sumber terbuka.
Gerakan open source telah bersatu di sekitar Open Source Initiative (OSI), sebuah organisasi
yang didedikasikan untuk mempromosikan aplikasi open source dan kode sistem, dengan fokus
pada manfaat dan kualitas untuk komunitas bisnis. Website OSI ditangkap evolusi gerakan:
“Perangkat lunak open source adalah ide yang saatnya telah akhirnya datang. Selama dua puluh
tahun telah membangun momentum dalam budaya teknis yang membangun Internet dan World
Wide Web. Sekarang itu melanggar keluar ke dunia komersial, dan bahwa ini mengubah semua

aturan. Apakah kamu siap?"23

Memimpin perusahaan seperti Netflix diketahui telah bermigrasi sebagian besar aplikasi
mereka dengan alternatif open source. Selain itu, perusahaan menerbitkan dan
mendukung banyak proyek open source yang tetap sangat dihormati di bidang keamanan, data
yang besar, penyebaran, dan kehandalan infrastruktur.

Open Source: Definisi

Perangkat lunak open source sering bingung dengan software-as bebas di gratis. Bahkan, lisensi
untuk perangkat lunak open source mungkin atau mungkin tidak ditawarkan tanpa biaya
(perangkat lunak bebas-of-charge disebut freeware). Sebaliknya, open source istilah digunakan
untuk membedakannya dari sumber tertutup, atau kepemilikan, program yang mencegah pengguna
dari mengakses dan memodifikasi kode sumber. Misi dari OSI menangkap gagasan ini: “Open
source adalah suatu metode pengembangan untuk perangkat lunak yang memanfaatkan kekuatan
didistribusikan peer review dan transparansi proses. Janji open source adalah kualitas yang lebih
baik, keandalan yang lebih tinggi, lebih fleksibel, biaya yang lebih rendah, dan mengakhiri

predator penjual kunci- di.”24

program perangkat lunak yang dibuat oleh para insinyur perangkat lunak, yang merancang
algoritma, dan programmer, yang kode menggunakan bahasa pemrograman tertentu. Kode yang
dihasilkan oleh programmer, yang dapat dipahami oleh siapa saja yang fasih dalam bahasa
pemrograman yang digunakan, disebut kode sumber (lihatGambar 11.10).
Agar program untuk bekerja, kode sumber harus diubah (yaitu, ditafsirkan atau dikompilasi) ke
format yang komputer dapat mengeksekusi, yang disebut kode objek. Biasanya, ketika Anda
membeli lisensi perangkat lunak dari sebuah perusahaan perangkat lunak (misalnya, Microsoft
Office, Oracle Database 12c), Anda diberi kode objek dan hak untuk menjalankannya pada
komputer Anda, tetapi Anda tidak disediakan dengan kode sumber. Bahkan, setiap upaya untuk
melakukan reverse engineering kode objek untuk mendapatkan akses ke kode sumber dianggap
sebagai pelanggaran terhadap kekayaan intelektual dari rumah perangkat lunak dan akan mendarat
Anda gugatan beralasan.
Tidak seperti software proprietary, program open source yang didistribusikan dengan maksud
mengungkapkan memungkinkan pengguna untuk mendapatkan akses, memodifikasi, dan
meningkatkan kode sumber. Lisensi open source biasanya menunjukkan karakteristik sebagai
berikut:

• redistribusi Gratis. Perangkat lunak ini dapat secara bebas diberikan atau dijual.
• kode sumber yang tersedia. Kode sumber diterbitkan dan bebas
 diperoleh.
• karya berasal. Lisensi dapat memodifikasi perangkat lunak dan mendistribusikan
bawah persyaratan lisensi yang sama seperti aslinya.
• Tidak ada diskriminasi. Lisensi ini tersedia untuk setiap lembaga, termasuk organisasi-
organisasi nirlaba dan pengguna komersial.
• teknologi netralitas. Lisensi dan semua ketentuannya harus bebas dari pembatasan
terkait dengan penggunaan teknologi atau ketik antarmuka.

Analisis open source lisensi karakteristik menunjukkan bahwa gerakan open source
mendorong, bukan menentang, aplikasi komersial dan redistribusi komersial. keramahan ini
menuju aplikasi bisnis telah menjadi katalis untuk penerimaan luas dan pertumbuhan software
open source sebagai alternatif untuk program proprietary. Memang, banyak organisasi
mempertimbangkan open source alternatif untuk keputusan pengembangan perangkat lunak make-
atau-beli tradisional yang dibahas di atas. Orang lain melihat open source sebagai cara untuk
mendorong tumbuhnya inovasi dan pengembangan. Sebagai contoh, Google telah merilis lebih
dari 2.000 aplikasi open source dan baru-baru ini terbuka TensorFlow bersumber, mesin
perpustakaan belajar.

Gambar 11.10. contoh kode sumber

Sementara perangkat lunak open source adalah mudah didownload dan digunakan kembali,
sekarang Anda menyadari bahwa mendapatkan perangkat lunak ini hanya sebagian kecil dalam
pengembangan sistem dan implementasi proses yang diperlukan untuk berhasil menyebarkan
sistem informasi organisasi bekerja. Dalam rangka untuk membantu perusahaan-perusahaan
modern yang memanfaatkan software open source, dan untuk menangkap peluang bisnis yang
besar yang diciptakan oleh gerakan open source, sejumlah organisasi telah muncul. Tiga model
berikut saat ini tersedia.25
Sponsored Open Source Sejumlah tidak-untuk-profit yayasan memberikan dukungan dan
koordinasi upaya open source. Sebagai contoh, Apache Software Foundation koordinat perangkat
tambahan untuk web server Apache, dan Mozilla Foundation mendukung pengembangan Firefox
web browser dan banyak produk lainnya (Gambar 11.11).
Beberapa perusahaan juga mensponsori proyek open source mereka sendiri, biasanya
“pembukaan” produk perangkat lunak mereka sendiri dengan merilis kode sumber. Contoh
pertama di daerah ini ditawarkan oleh Netscape Corp., yang merilis kode sumber dari web browser
pada tahun 1998. Baru-baru ini, Sun Microsystems, dibeli oleh Oracle pada tahun 2008, merilis
kode sumber OpenOffice suite dan pada bulan November 2006 bahkan merilis kode sumber dari
bahasa pemrograman Java nya. Google Rilis TensorFlow pada bulan November 2015 adalah
contoh yang baru-baru ini.

Layanan Open Source Model layanan open source muncul di akhir 1990-an dengan
meningkatnya perhatian yang mengumpulkan dengan sistem operasi Linux. Sementara lisensi
untuk Linux harus bebas, sejumlah perusahaan, yang dipimpin oleh pelopor Red Hat Inc, mulai
pengisian untuk instalasi, dukungan, pelatihan, dan semua layanan tambahan lainnya biasanya
terkait dengan penjualan perangkat lunak. Hari ini sejumlah upstarts dan perusahaan yang
didirikan bersaing di pasar ini, termasuk nama-nama besar seperti IBM, Hewlett-Packard (HP),
dan Unisys. penyimpanan mereka mendukung seluruh stabil aplikasi open source seperti Linux
(sistem operasi), Apache (web server), MySQL (database sistem manajemen), dan aplikasi data-
besar berorientasi seperti MongoDB (database NoSQL), Hadoop (didistribusikan dan pengolahan
kerangka ), dan Spark (kerangka komputasi cluster).
Gambar 11.11. Situs web Mozilla Foundation

Profesional Open Source Evolusi terbaru dalam model open source adalah open source
profesional. Label ini mengacu pada organisasi itu, sementara menjadi bagian dari gerakan open
source dan berlangganan ke open source lisensi hal, mempertahankan kontrol yang cukup ketat
atas program perangkat lunak yang mereka jual. Sebagai contoh, sebuah organisasi open source
profesional akan memiliki inti set sendiri programmer dan pengembang yang memberikan arahan
untuk proyek tersebut. Pada saat yang sama, meskipun, kelompok akan memanfaatkan komunitas
yang lebih besar dari programmer open source, penguji, dan pengadopsi. Organisasi-organisasi ini
bergantung pada pengetahuan dan pemahaman dari kode sumber inti untuk memberikan layanan
yang lebih baik ketika klien mengadopsi perangkat lunak mereka.

Keuntungan dan Kerugian Open Source Software

Sebagai manajer masa depan, Anda akan tanpa ragu menjadi bagian dari panitia seleksi sistem.
Semakin, komite tersebut memiliki pilihan untuk mengadopsi software open source daripada
membeli program proprietary. Sementara keputusan semacam ini sangat konteks tertentu, di
bawah ini kita mengidentifikasi manfaat utama dan kelemahan dari open source.

Keuntungan Keuntungan utama dari open source dipuji oleh para pendukungnya adalah fungsi
dari kemampuan proyek open source untuk memanfaatkan komunitas besar pengembang,
programer, penguji, dan pelanggan. Keuntungan ini antara lain sebagai berikut:

• kesegaran. Para pendukung perangkat lunak klaim open source yang jatuh tempo
proyek (misalnya, Linux) lebih kuat, lebih dapat diandalkan, dan kualitas umumnya
lebih tinggi dari aplikasi proprietary sebanding (misalnya, Microsoft Windows).
• Kreativitas. Perangkat lunak open source memanfaatkan kreativitas ribuan
pengembang di seluruh dunia. Dengan demikian, itu lebih mungkin untuk
menghasilkan solusi terobosan baru (misalnya, Firefox tab yang sedang berada,
sekarang standar di kelas ini aplikasi) daripada produk tradisional yang dibuat oleh
komunitas kecil dalam satu software house. Banyak tepi dan pasar yang inovatif
(misalnya, data besar, pembelajaran mesin, awan) memang berdasarkan
perkembangan open source.
• Terbatas lock-in. perangkat lunak open source bukan tanpa beralih biaya, tetapi
pendukung mengklaim bahwa biaya tersebut jauh lebih rendah daripada yang terkait
dengan perangkat lunak proprietary. Sebagai contoh, pelanggan perangkat lunak open
source dapat membuat modifikasi sendiri ke kode sumber daripada harus bergantung
pada vendor perangkat lunak untuk melakukannya.
• lisensi Sederhana. Karena struktur lisensi open source, pelanggan tidak perlu khawatir
tentang kendala hukum yang rumit (misalnya, jumlah pengguna bersamaan). Mereka
hanya menginstal banyak salinan dari program yang mereka butuhkan.
• Lisensi gratis. Meskipun tidak dianggap sebagai salah satu manfaat utama open source
oleh gerakan open source, biaya total kepemilikan masih merupakan faktor penting
untuk perusahaan-perusahaan yang mengadopsi open source
 aplikasi. Karena open source umumnya dapat lisensi gratis, biaya lebih rendah
daripada yang terkait dengan aplikasi proprietary.

kekurangan Software ini tidak berarti sederhana (atau murah) untuk menginstal dan
mengoperasikan, dan perangkat lunak open source tidak terkecuali. Jadi skeptis merespon dengan
menaikkan kekhawatiran berikut:

• biaya tak terduga. Skeptis ingin mengatakan bahwa perangkat lunak bebas adalah
seperti gratis anjing-ya, Anda mendapatkannya untuk apa-apa, tapi kemudian Anda
akan menemukan banyak (sering tidak direncanakan) biaya sepanjang jalan. studi
terbaru menunjukkan bahwa sementara di 80% kasus, perangkat lunak open source
ini digunakan untuk mengurangi biaya, penghematan dapat dibuktikan hanya 50%

dari mereka.26 Dengan demikian Anda perlu hati-hati mengevaluasi instalasi open
source berdasarkan total biaya kepemilikan (lihat Bab 10).
• Dukungan bervariasi. Tergantung pada produk dan di mana perusahaan Anda
memperolehnya, dukungan dapat berkisar dari berkualitas tinggi untuk tidak ada,
bahkan dalam kaitannya dengan jatuh tempo-dan luas adopsi-perangkat lunak.
• Keamanan. Skeptis mengklaim bahwa penerbitan kode sumber memberikan
keuntungan bagi mereka yang ingin istirahat keamanan. Para pendukung sumber
respon terbuka yang komunitas besar pengembang akan mengidentifikasi dan
menutup lebih kelemahan dari tim kecil pengembang perusahaan.
• Kesesuaian. Standardisasi produk menggunakan satu atau kompatibilitas beberapa
vendor menyederhanakan dan integrasi. Tidak ada jaminan bahwa solusi open source
kompatibel dengan satu sama lain dan / atau dengan perangkat lunak proprietary.
• Lanskap hukum. Perangkat lunak open source mensyaratkan bahwa tidak ada bagian
dari kode dilindungi oleh hak cipta. tantangan pengadilan terakhir telah mengangkat
momok bahwa tidak ada cara untuk memastikan bahwa kode hak cipta tidak akan
membuatnya menjadi solusi open source, sehingga membuka pelanggan untuk
kewajiban. Sebagai tanggapan, beberapa perusahaan yang mendukung perangkat
lunak open source (misalnya, JBoss, HP, Red Hat) telah mengadopsi klausul ganti
rugi dalam perjanjian lisensi mereka.

Singkatnya, keputusan apakah untuk pergi dengan open source dan dengan apa
produk tergantung pada karakteristik organisasi dan jatuh tempo dari program perangkat lunak.
Beberapa produk, seperti sistem operasi Linux, sudah satu dekade sehingga kuat lalu bahwa pada
awal tahun 2005 MIT Media Lab merasa nyaman menasihati pemerintah Brasil untuk menghindari
produk Microsoft untuk perangkat lunak open source, berpendapat bahwa “perangkat lunak bebas

jauh lebih baik pada dimensi biaya, tenaga, dan kualitas.”27 Produk lain memerlukan komitmen
yang lebih kuat dalam hal dukungan dan investasi. Sangat penting bahwa organisasi mengadopsi
produk tersebut memiliki keahlian dan sumber daya untuk menerapkan dan memelihara mereka.

11.6 Pembangunan End-User

Sebagaimana kita bahas pada Bab 1, Kemudahan penggunaan teknologi informasi terus
meningkat, sementara biaya telah menurun secara dramatis selama bertahun-tahun. Kedua
kekuatan telah bersekongkol untuk membawa kekuatan pengembangan perangkat lunak kepada
massa dalam bentuk pengembangan pengguna akhir. pengembangan pengguna akhir adalah istilah
umum menangkap banyak cara di mana pekerja pengetahuan, tidak profesional TI, membuat
perangkat lunak.
Pengguna akhir sistem yang dikembangkan berkisar dari model spreadsheet (misalnya,
kalkulator ROI ditulis dalam Microsoft Excel), untuk database pribadi atau departemen, untuk
program perangkat lunak penuh dibangun dengan bahasa yang ramah pengguna komputer
(misalnya, Visual Basic untuk aplikasi) atau pengembangan alat-alat seperti bahasa generasi
keempat. pengembangan pengguna akhir telah menerima dorongan baru dengan lonjakan analisis
dan proyek sains data (lihatBab 1). Dibantu oleh ekosistem tumbuh di sekitar perangkat lunak yang
kuat open source seperti R dan Python, Anda akan segera menemukan diri Anda menggores data
Anda sendiri, membangun model analisis Anda sendiri, dan bahkan menciptakan dashboard untuk
rekan kerja Anda. Alat dan data yang ada; semua yang Anda perlu adalah keterampilan!
Menyenangkan seperti ini “sistem bayangan” yang, kehadiran mereka tumbuh dalam organisasi

modern28 harus dikelola secara hati-hati. Bagi Anda sebagai manajer, memahami manfaat dan
keterbatasan pengembangan pengguna akhir adalah sebuah awal.
Manfaat Pengembangan End-User
Manfaat utama dari pengembangan pengguna akhir berasal dari pemberdayaan pengguna
dan fakta bahwa beberapa beban pada departemen sistem informasi biasanya terlalu banyak bekerja
diangkat. Manfaat antara lain sebagai berikut:
• Peningkatan kecepatan pembangunan. Komunitas pengguna biasanya harus
mengarahkan permintaan untuk sistem baru, dan perbaikan yang saat ini, dengan
fungsi IS. Pada gilirannya, fungsi IS harus memprioritaskan penyebaran sumber daya
yang langka. Akibatnya, proyek-proyek yang pengguna akhir dapat menyelesaikan
secara independen akan selesai lebih cepat berdasarkan tidak masuk antrian.
• kepuasan pengguna akhir. Salah satu masalah utama dengan sistem baru adalah
ketidakpuasan pengguna atau penolakan langsung. Ketika pengguna membuat
aplikasi mereka sendiri, mereka lebih mungkin puas dengan hasilnya; mereka baik
telah menciptakan fungsi yang mereka inginkan atau telah sendiri memutuskan apa
fitur untuk melupakan.
• Mengurangi tekanan pada fungsi IS. pengembangan pengguna akhir dapat membatasi
jumlah permintaan IS fungsi menerima, memungkinkan mereka untuk lebih fokus
pada proyek-proyek yang, karena ruang lingkup dan kompleksitas mereka, benar-
benar membutuhkan perhatian mereka.
Risiko Pengembangan End-User
Sayangnya, pengembangan pengguna akhir hadiah sejumlah risiko yang sulit-to mengelola yang
membatasi nilainya bagi organisasi:

• standar kualitas tidak dapat diandalkan. Ada alasan mengapa pengembangan

perangkat lunak adalah proses yang panjang. kualitas perangkat lunak membutuhkan
sejumlah kegiatan yang mungkin tidak mudah terlihat, tetapi diperlukan-seperti
pengujian, dokumentasi, keamanan, integrasi, dan sejenisnya. Karena keahlian
terbatas dan pengetahuan sebagian besar pengguna akhir, kualitas pekerjaan mereka
bervariasi secara dramatis.
• tingginya insiden kesalahan. Audit spreadsheet digunakan dalam organisasi
menunjukkan bahwa persentase yang cukup besar, antara 20% dan 40% (kadang-
kadang 90%), mengandung kesalahan. Fokus pada hasil (yaitu, program apa tidak)
dan perkembangan yang cepat biasanya bersekongkol untuk meningkatkan
kemungkinan kesalahan dalam aplikasi-pengguna akhir dikembangkan.
• risiko kelangsungan. Karena pengembangan pengguna akhir sering tidak
 mematuhi metodologi pengembangan sistem tradisional, mungkin sulit bagi siapa pun
tetapi individu yang menulis program untuk memahaminya, meningkatkan, dan
mendukungnya. Kurangnya dokumentasi senyawa masalah ini. Skenario umum
melibatkan orang-orang seperti Anda yang mengembangkan aplikasi besar selama
magang hanya untuk melihat mereka memudar terlupakan perusahaan setelah mereka
meninggalkan perusahaan.
• Peningkatan tekanan pada fungsi IS. Sementara pembangunan end-user dapat
meringankan beberapa tuntutan pembangunan pada IS fungsi, sering menciptakan
lebih banyak permintaan untuk bantuan selama proses pembangunan dan, dari waktu
ke waktu, lebih banyak permintaan untuk bantuan mengelola aplikasi setelah rilis.
Ringkasan
Bab ini melanjutkan pembahasan kita tentang teknik dan metodologi organisasi modern
menggunakan untuk memperkenalkan dan mengelola sistem informasi (IS) dalam kerangka
berdasarkan program sistem informasi strategis.
Secara khusus, dalam bab ini kami fokus pada tiga pendekatan yang digunakan untuk
memperkenalkan sistem informasi organisasi baru: desain kustom dan pengembangan, sistem
seleksi dan akuisisi, dan pengembangan pengguna akhir. Kami telah belajar:

• Mencengangkan kemajuan yang memiliki teknologi informasi ditandai (TI) selama

40 tahun terakhir sering menyesatkan umum dan manajer fungsional. Menjadi
sebagian besar akrab dengan komputasi personal, mereka meremehkan berapa banyak
waktu dan berapa banyak uang yang diperlukan untuk membangun stabil, kuat, dan
sistem yang aman yang akan bekerja di bawah beragam kondisi organisasi. Untuk
menghindarikesalahpahaman ini, manajer harus menjadi akrab dengan proses dimana
sistem informasi berbasis IT datang ke dalam organisasi modern.
• Memperkenalkan sebuah sistem informasi organisasi adalah proses dua langkah yang
membutuhkan pengembangan teknologi dan proses implementasi. Kedua proses,
sementara sering digambarkan secara terpisah, saling melengkapi dan saling terkait.
Baru-baru ini, pengembangan dan operasi (DevOps) telah muncul sebagai praktek
dalam konteks
 pengembangan perangkat lunak tangkas untuk mencapai waktu respon yang lebih
pendek ketika datang ke pengiriman fitur atau perbaikan bug memanfaatkan integrasi
berkesinambungan dan penyebaran berkelanjutan.
• perusahaan modern yang memperkenalkan sistem informasi baru menggunakan salah
satu pendekatan berikut: desain kustom dan pengembangan, sistem seleksi dan
akuisisi, atau pengembangan pengguna akhir. Perbedaan penting antara mereka
adalah cara di mana aplikasi perangkat lunak pada inti dari sistem informasi yang
dikembangkan. Dalam pendekatan pertama, profesional TI dalam organisasi atau
mereka yang dikontrak mengembangkan disesuaikan unik perangkat lunak untuk
kebutuhan perusahaan. Dalam pendekatan kedua, panitia seleksi memilih aplikasi off-
the-rak. Dalam pendekatan ketiga, itu adalah pengguna akhir perusahaan, daripada
profesional TI, yang membuat perangkat lunak.
• Metodologi utama untuk pengembangan sistem kustom adalah siklus hidup
pengembangan sistem (SDLC). SDLC, didasarkan pada gagasan bahwa rinci muka
perencanaan adalah kendaraan untuk mengurangi risiko dan ketidakpastian dalam
upaya sistem desain dan pengembangan, paling cocok untuk pengembangan besar,
aplikasi perangkat lunak yang kompleks. SDLC yang diartikulasikan selama tiga
definisi utama phases-, membangun, dan tahap implementasi dan sembilan.
Keterbatasan utama dari SDLC adalah penciptaan overhead substansial dan kekakuan
yang membatasi kemampuan tim proyek untuk mengatasi perubahan yang tak
terelakkan.
• Metodologi prototyping telah muncul sebagai alternatif untuk SDLC. Prototyping
berakar pada gagasan bahwa tidak mungkin untuk secara jelas memperkirakan dan
rencana rinci seperti usaha yang kompleks seperti sistem informasi desain dan
pengembangan proyek. Sebaliknya tim ini lebih baik dilayani dengan tetap gesit dan
iterasi cepat melalui beberapa desain untuk nol dalam pada satu optimal. Keuntungan
prototyping meliputi kepuasan pengguna (terutama untuk aplikasi skala kecil atau
mereka yang secara dramatis mengubah praktek kerja), perkembangan yang cepat,
dan eksperimen. Kelemahan termasuk risiko sistem-kualitas yang lebih rendah
daripada yang dikembangkan menggunakan lebih terstruktur metodologi dan scope
creep.
• Agile metode tempat penekanan pada tim pengembangan dan keterlibatan pengguna.
Setiap memperkenalkan iterasi fitur atau perubahan ke dalam
 produk, dan ini ditinjau oleh tim pengembangan dan pengguna. metodologi tangkas
memberikan kemampuan untuk arah pembangunan perubahan kemudian dalam
pembangunan.
• Open source program perangkat lunak, yang memungkinkan perusahaan mengadopsi
untuk menerima dan memodifikasi kode sumber, semakin menjadi pilihan yang layak
untuk organisasi. Ketika menimbang keputusan untuk mengadopsi open source bukan
sebuah program perangkat lunak proprietary, Anda perlu mengevaluasi keuntungan
sebagai berikut dan kerugian dari proyek open source. Pro meliputi ketahanan,
kreativitas, terbatas lock-in, perizinan disederhanakan, dan lisensi gratis. Kontra
termasuk biaya tak terduga, berbagai tingkat dukungan kualitas, masalah keamanan,
masalah kompatibilitas, dan pemandangan hukum yang berpotensi kompleks.
• Dengan munculnya internet dan pertumbuhan industri perangkat lunak di negara-
negara dengan akses ke kolam besar bakat dan biaya hidup yang rendah, maka
semakin layak untuk pengembangan outsource aplikasi kustom.
• Industri perangkat lunak telah berkembang ke titik di mana hampir semua aplikasi
membutuhkan suatu perusahaan tersedia dari rak. Ketika membangun sistem
informasi di sekitar aplikasi perangkat lunak dikemas, perusahaan harus terlibat dalam
proses sistem seleksi dan akuisisi formal. Melakukan hal memastikan bahwa tim
seleksi mengevaluasi semua kemungkinan solusi dan memperoleh salah satu yang
paling cocok dengan kebutuhan perusahaan. Pemilihan dan akuisisi proses cermin
SDLC, dengan beberapa variasi penting selama definisi dan membangun fase.
• Munculnya bahasa yang kuat dan mudah digunakan komputer, alat-alat
pengembangan perangkat lunak, dan layanan cloud dan infrastruktur telah
memungkinkan gelar belum pernah terjadi sebelumnya dari pengembangan perangkat
lunak oleh pengguna akhir (yaitu, non-profesional TI). Manfaat pembangunan end-
user meliputi peningkatan kecepatan dan kepuasan pengguna akhir dan tekanan
rendah pada IS fungsi untuk mengembangkan aplikasi baru. Risiko pengembangan
pengguna akhir termasuk standar tidak dapat diandalkan kualitas, tingginya insiden
kesalahan dalam aplikasi, risiko kesinambungan, dan meningkatkan tekanan pada IS
fungsi untuk mendukung pengembangan dan pengelolaan aplikasi pengguna akhir.
Studi Pertanyaan
1. Jelaskan alasan umum dan manajer fungsional sering gagal untuk memahami
kompleksitas pengembangan sistem informasi organisasi. Dapatkah Anda
memberikan contoh dari pengalaman Anda?
2. Apa perbedaan antara pengembangan teknologi dan pengembangan sistem
informasi? Apa hubungan antara kedua proses?
3. Bagaimana perkembangan tiga sistem informasi pendekatan yang digunakan saat
ini dalam organisasi modern berbeda? Dapatkah Anda memberikan contoh
masing-masing?
4. Memberikan argumen yang mendukung kedua make dan buy pendekatan. Apa
keuntungan utama dari setiap keputusan? Semakin perusahaan mendekati
pengembangan sistem informasi sebagai “membeli dan membuat” proses. Apa
yang kita maksud dengan “membeli dan membuat”? Mengapa pendekatan ini
mendapatkan meningkatkan popularitas hari ini?
5. Jelaskan siklus hidup pengembangan sistem (SDLC) metodologi dalam konteks
“nyata” misalnya. Dengan kata lain, berpikir tentang (atau bayangkan) situasi di
mana Anda mengusulkan perlunya sistem informasi baru. Untuk sistem upaya
pengembangan ini, menjelaskan apa yang terjadi (atau seharusnya terjadi) selama
fase definisi, membangun, dan implementasi.
6. Ulangi pertanyaan 5, kali ini menggunakan metodologi prototyping.
7. Ulangi pertanyaan 5, kali ini menggunakan pemilihan sistem dan akuisisi
metodologi.
8. Mengartikulasikan keuntungan dan kerugian dari metode tangkas dan DevOps.
9. Apakah perangkat lunak open source? Apa keuntungan dan kerugian utama
perangkat lunak open source? Ketika Anda akan mempertimbangkan sumber
implementasi perangkat lunak open dalam organisasi Anda? Ketika kan tidak?
10. Mengartikulasikan keuntungan dan kerugian dari pengembangan pengguna
akhir.