Dokumen ini membahas siklus hidup pengembangan sistem (SDLC) dan strategi pengembangan perangkat lunak. SDLC terdiri dari tujuh fase yaitu perencanaan, analisis, desain, pengembangan, pengujian, penerapan, dan pemeliharaan. Tiga strategi pengembangan perangkat lunak yang dijelaskan adalah pengembangan air terjun, pengembangan iteratif, dan pengembangan agile. Dokumen ini juga membahas pertimbangan organisasi d

1. KONSEP DASAR
SISTEM INFORMASI
Kelompok 6
Dirga Eka Prasetya 1204220002
Ahmad Sukron F. A. 1204220057
Muhammad Ihsan R. 1204220101
Reza Fajar P. 1204220065

2. Chapter 11
pengembangan
sistem dan
pengadaan
Tujuan Pembelajaran
Jelaskan tujuh fase dari siklus hidup pengembangan sistem.
Jelaskan tiga strategi utama pengembangan perangkat
lunak.
Jelaskan mengapa organisasi memilih satu strategi
pengembangan perangkat lunak daripada yang lain untuk
proyek tertentu.
Jelaskan bagaimana organisasi memutuskan apakah akan
membangun atau membeli, dan langkah-langkah yang
mereka gunakan jika mereka memilih untuk membeli sistem
Informasi.
Identifikasi beberapa cara di mana elemen manusia penting
untuk pengembangan dan pengadaan sistem.
1.
2.
3.
4.
5.

3. Siklus hidup pengembangan sistem

4. Perencanaan
Tujuan dari langkah ini adalah untuk menentukan kebutuhan bisnis untuk proyek tersebut, menilai kepentingannya bagi
perusahaan, dan menentukan apakah proyek tersebut benar-benar layak. Sebagian besar organisasi tidak kekurangan ide untuk
proyek sistem informasi, tetapi mereka semua memiliki waktu dan dana yang terbatas. Memang, banyak yang memiliki antrean
panjang ide untuk meningkatkan atau mengganti sistem yang ada atau menerapkan yang baru, yang semuanya mungkin tampak
bermanfaat.
Menilai Kebutuhan Bisnis Tiga faktor utama yang mendukung kebutuhan bisnis dan menentukan di mana harus mengalokasikan
dana untuk proyek pengembangan sistem adalah:
▶Laba atas investasi (ROI)
▶Keunggulan kompetitif
▶Manajemen risiko
Studi Kelayakan Studi kelayakan merupakan bagian penting dari proses perencanaan yang memeriksa apakah inisiatif tersebut
layak dari sudut pandang teknis, keuangan, dan hukum. Mungkin tidak layak secara teknis jika teknologinya belum ada atau
belum cukup matang untuk mendukung tujuan proyek. Secara finansial, laba atas investasi mungkin menjanjikan, tetapi organisasi
mungkin tidak memiliki modal yang cukup untuk mendanainya. Tinjauan hukum dapat mengungkap risiko yang dapat membuat
perusahaan terkena tuntutan hukum.

5. Analisis
Setelah proyek disetujui untuk dilanjutkan, langkah selanjutnya adalah menganalisis dan mendokumentasikan
apa yang sebenarnya harus dilakukan oleh sistem dari perspektif bisnis (berlawanan dengan teknis). Selama
analisis persyaratan, pemangku kepentingan mengidentifikasi fitur yang dibutuhkan sistem dan kemudian
memprioritaskannya sebagai wajib, pilihan, atau tidak penting. Mengumpulkan persyaratan ini memerlukan
banyak pertemuan, wawancara, dan ulasan tentang bagaimana proses yang ada terungkap. Orang yang
memimpin analisis ini membutuhkan latar belakang yang kuat dalam manajemen bisnis dan sistem informasi,
tetapi juga keterampilan mendengarkan dan membangun konsensus yang luar biasa. Para pemangku
kepentingan akan memiliki pandangan yang berbeda tentang bagaimana proses sebenarnya bekerja dan
bagaimana proses tersebut harus ditingkatkan, terutama ketika pekerjaan mereka sendiri terlibat. Analisis
persyaratan yang dilakukan dengan baik juga harus mengungkap peluang untuk mengoptimalkan proses bisnis
dan bahkan menghilangkan beberapa di antaranya. Perhatian pada bagaimana sistem informasi dapat
meningkatkan manajemen proses bisnis (BPM) dapat menghasilkan dividen yang kaya. Sebagai contoh, sebuah
proses yang termasuk mengarahkan pembelian pasokan ke penyelia untuk disetujui mungkin tidak diperlukan
sama sekali jika aturan yang digunakan penyelia untuk membuat keputusan dapat dibangun ke dalam sistem
pakar. Entri data manual dari formulir tulisan tangan adalah target utama untuk eliminasi, menggunakan
pengenalan karakter yang cerdas, atau pelanggan yang dengan senang hati akan memasukkan data mereka
sendiri di web.

6. Dokumen Definisi Persyaratan Output dari fase analisis adalah dokumen definisi persyaratan (RDD), yang
menentukan secara rinci fitur apa yang harus dimiliki sistem, diprioritaskan oleh para pemangku
kepentingan. Ini juga mencakup asumsi dan batasan yang memengaruhi sistem, seperti kebutuhan untuk
bermigrasi dan kemungkinan memformat ulang data dari sistem yang ada. Selain fitur aktual sistem,
dokumen harus membahas jenis persyaratan yang tercantum dalam Gambar 11-3. Para pemangku
kepentingan menandatangani dokumen tersebut, memastikan bahwa ini memang sistem yang mereka
butuhkan, ditentukan setepat mungkin.

7. Rancangan
Fase rancangan melibatkan menerjemahkan RDD ke dalam desain teknis yang bisa diterapkan. Di sini, tim
membuat keputusan tentang arsitektur sistem, dan menyusun rencana yang menjelaskan detail teknis.
Desain Arsitektur Pilihan lingkungan pengembangan perangkat lunak dan arsitektur perangkat keras
adalah salah satu yang kritis. Organisasi harus melakukannya mempertimbangkan arsitektur perusahaan
secara keseluruhan. Meskipun lingkungan pengembangan perangkat lunak tertentu mungkin sedikit lebih
efisien untuk proyek tertentu, kerugian dari arsitektur yang terfragmentasi dan terintegrasi dengan buruk
terlalu mahal untuk diabaikan. Pilihan juga akan dipengaruhi oleh pengalaman dan kemampuan staf TI.
Perusahaan yang staf TI-nya sangat berpengalaman dengan bahasa pemrograman Java, server Linux, dan
database MySQL, misalnya, akan condong ke arah itu untuk proyek-proyek baru guna meningkatkan
keahlian yang ada. Namun, jika staf hanya berpengalaman dalam teknologi lama, kepala arsitek organisasi
ingin mengambil kesempatan ini untuk melatih staf dalam alat baru, yang selaras dengan arsitektur masa
depan perusahaan.

8. Perkembangan
Mengubah desain menjadi sistem informasi operasional adalah tujuan dari fase pengembangan.
Bergantung pada ruang lingkup sistem, fase ini mungkin memerlukan tim pengembang untuk bekerja
selama berbulan-bulan, masing-masing membangun satu bagian dari sistem.
Pengembang perangkat lunak menggunakan sistem informasi mereka sendiri untuk merampingkan
pekerjaan dan saling memberi informasi tentang kemajuan atau tantangan. Misalnya, perangkat lunak
kontrol versi melacak versi kode, bertindak seperti perpustakaan dengan prosedur checkout untuk
mencegah pengembang menulis file satu sama lain.
Perangkat lunak pelacakan proyek dan masalah menawarkan fitur yang berguna untuk membantu
pengembang tetap mengikuti semua aspek proyek mereka. Pengembang dapat mengunggah diagram dan
dokumentasi, mengomentari aktivitas, menjelaskan tantangan, melaporkan bug, dan meminta bantuan.
Perangkat lunak menyimpan riwayat lengkap aktivitas proyek, termasuk tanggal yang menunjukkan kapan
setiap modul dimulai dan diselesaikan dan siapa yang ditugaskan untuk setiap tugas. Ini juga menawarkan
dasbor yang dapat disesuaikan sehingga pengembang dapat melihat sekilas bagaimana proyek berjalan
dan aktivitas apa yang harus mereka selesaikan hari ini (Gambar 11-5).

10. Pengujian

11. Pengujian berlangsung selama fase pengembangan, saat masing-masing modul diselesaikan. Ketika sistem
telah selesai, ia menjalani pengujian yang jauh lebih ketat untuk memastikan bahwa seluruh sistem bekerja
dengan lancar bersama-sama, bukan hanya modul individualnya. Gambar 11-6 mencantumkan contoh
jenis pengujian yang mungkin dilakukan pengembang.
Setiap pengujian meniru peristiwa yang akan ditangani sistem saat ditayangkan. Kasus uji
didokumentasikan dengan hati-hati sehingga pengembang dapat melakukan koreksi jika terjadi kegagalan.
Alat perangkat lunak juga sangat membantu pengujian ini. Misalnya, setelah pengembang membuat
pustaka kasus uji, alat perangkat lunak dapat secara otomatis menjalankannya terhadap sistem saat
berkembang untuk menguji kesalahan. Perangkat lunak ini dapat mensimulasikan pasukan pelanggan,
secara bersamaan mencoba melengkapi formulir berbasis web dengan data yang berbeda, kesalahan input
yang berbeda, browser yang berbeda, dan hasil yang diharapkan berbeda.

12. Penerapan
Saat tanggal go-live semakin dekat, tugas beralih ke kebutuhan pengguna akhir yang akan menggunakan
dan mengelola sistem. Mereka akan membutuhkan dokumentasi dan pelatihan untuk memahami dengan
jelas cara kerja sistem baru dan perbedaannya dari yang lama, jika ada. Pekerjaan mereka mungkin
banyak berubah dan mereka harus merasa yakin bahwa mereka dapat menangani peran baru tersebut.
Organisasi memiliki beberapa pilihan tentang bagaimana menerapkan sistem baru:
▶Implementasi parallel
Implementasi paralel meluncurkan sistem baru sementara yang lama masih berjalan. Karyawan
melakukan pekerjaan mereka dua kali, sekali di setiap sistem, atau dua tim terpisah menangani proses
yang sama, satu tim di setiap sistem. Keuntungan dari pendekatan ini adalah kedua sistem memproses
kasus yang sama, jadi jika yang baru beroperasi dengan benar, keluarannya harus sama. Namun,
implementasi paralel sangat mahal dan biasanya hanya berlangsung dalam waktu singkat. Juga, jika sistem
lama dihentikan karena beberapa proses ceroboh, perbandingannya mungkin tidak valid.

13. ▶Implementasi bertahap
Implementasi bertahap meluncurkan modul secara bertahap daripada sekaligus. Misalnya, ERP mungkin
dimulai dengan sumber daya manusia, kemudian fase dalam komponen modul keuangan. Tim
implementasi dan pelatih dapat fokus pada satu grup departemen pada satu waktu, membantu mereka
terbiasa dengan perangkat lunak baru sementara pengembang memperhatikan gangguan. Kerugiannya
adalah bahwa modul sistem baru mungkin terintegrasi dengan erat, sehingga menerapkan satu tanpa yang
lain dapat menimbulkan kebingungan dan memerlukan antarmuka sementara ke sistem lama. Misalnya,
sistem sumber daya manusia akan menyertakan data penggajian yang harus diteruskan ke buku besar
umum yang lama jika buku besar yang baru belum berjalan. Konsistensi juga menjadi masalah jika
informasi disimpan di lebih dari satu tempat saat modul dimasukkan secara bertahap.
▶Implementasi langsung
Implementasi langsung mematikan sistem lama dan meluncurkan semua modul dari yang baru pada satu
tanggal siaran langsung yang sangat padat, kadang-kadang disebut "big bang" (menurut cara para
astronom menggambarkan asal ledakan alam semesta). Seringkali karyawan pulang pada malam hari dan
kembali pada pagi hari untuk menemukan sistem baru di tempat. Keuntungan utama adalah bahwa semua
jembatan sementara antara modul lama dan baru tidak diperlukan, dan orang-orang yang perannya
menjangkau modul tidak perlu bolak-balik. Strategi bekerja dengan baik untuk sistem yang lebih kecil dan
mungkin satu-satunya pilihan logis bagi mereka. Namun, risikonya bisa tinggi untuk implementasi skala
besar dari perangkat lunak yang kompleks seperti ERP, yang melibatkan ribuan karyawan.

14. Pemeliharaan
Perbaikan Bug dan Permintaan Perubahan Meskipun telah dilakukan pengujian ekstensif, tidak ada sistem dengan
kerumitan apa pun yang bebas bug. Kasus uji yang digunakan untuk mengubah sistem menjadi bentuk hanya
menyentuh sebagian kecil dari semua kemungkinan kejadian dan kombinasi. Setelah sistem aktif, pengguna
memperkenalkan lebih banyak kasus dan bug muncul.
Untuk mengelola semua perbaikan bug dan permintaan perubahan, organisasi menerapkan proses kontrol perubahan.
Staf TI membantu mengklarifikasi permintaan perubahan dan memperkirakan sumber daya yang diperlukan untuk
menyelesaikannya. Mereka kemudian bekerja sama dengan unit bisnis dan manajemen eksekutif untuk menentukan
prioritas. Backlog dari perbaikan ini dapat tumbuh sangat lama, terutama seiring bertambahnya usia system.
Ketika Sistem Informasi Menua
Tidak seperti peralatan mekanis, perangkat lunak tidak rusak saat digunakan. Namun, sistem informasi menua, dan
akhirnya membutuhkan penggantian. Seiring waktu, beban pemeliharaan dapat menjadi sangat berat. Semua
perubahan menumpuk di dalam kode, menambahkan tambalan dan solusi yang menyumbat kode yang dulunya
disederhanakan. Proyek pemeliharaan yang diperlukan untuk menjaga sistem tetap aman dan mutakhir dengan versi
terbaru dari teknologi dasar sering kali ditunda, karena unit bisnis mencurahkan sumber daya untuk fitur baru yang
menawarkan keunggulan kompetitif. Seperti sebuah rumah tua yang pemiliknya menambahkan taman mawar yang
indah daripada mengganti kabel tembaga yang rusak, sistem informasi mengumpulkan tanda-tanda penuaan yang
tersembunyi. Sistem menjadi lebih sulit untuk beradaptasi dengan perubahan kebutuhan bisnis, dan juga dapat
menghadirkan risiko kegagalan bencana.

15. Strategi pengembangan
perangkat lunak

16. Siklus hidup pengembangan sistem (SDLC) menggambarkan perkembangan yang teratur dari
perencanaan hingga pemeliharaan dan akhirnya penggantian, dengan langkah-langkah terpisah
di antaranya. Namun, proyek aktual mungkin menyimpang dari pendekatan langkah demi
langkah yang langsung, dengan menggunakan metode pengembangan alternatif. SDLC sejalan
erat dengan metode air terjun, yang akan kita bahas terlebih dahulu.

17. Pengembangan perangkat lunak air terjun
Dalam metode air terjun, tugas-tugas SDLC terjadi secara berurutan, dengan satu
aktivitas dimulai hanya setelah aktivitas sebelumnya selesai (Gambar 11-8). Fase analisis
menentukan persyaratan, dan pada saat itu pengembang memperkirakan waktu dan
sumber daya yang diperlukan untuk menyelesaikan proyek. Pemrogram tidak mulai
menulis kode apa pun sampai semua fase sebelumnya diselesaikan, termasuk desain
terperinci. Orang yang berbeda mungkin terlibat dalam setiap tugas, dan mereka
menyerahkan pekerjaan mereka ke tim berikutnya saat bagian mereka selesai.Secara
teori, perkembangan berlanjut dari satu tugas ke tugas berikutnya. Namun dalam
praktiknya, persyaratan sering berubah setelah tahap selanjutnya dimulai, memaksa air
terjun untuk kembali menanjak. Desainnya harus diubah, dan pemrogramannya juga
harus diubah. Meskipun metode air terjun telah digunakan selama beberapa dekade,
tingkat keberhasilan seringkali cukup mengecewakan, terutama untuk proyek besar
yang membutuhkan waktu lama untuk diselesaikan.

19. Metode Iteratif
Metode berulang memampatkan cakrawala waktu untuk pengembangan perangkat
lunak, sebagian untuk mengurangi dampak kebutuhan bisnis yang berubah dengan
cepat dan pengerjaan ulang yang dihasilkan. Mereka berfokus pada waktu yang tersedia
hingga rilis berikutnya, atau iterasi, dan tim pengembangan menentukan berapa banyak
persyaratan yang dapat diberikan dalam jangka waktu tersebut. Sementara metode air
terjun memperkirakan waktu dan sumber daya yang dibutuhkan berdasarkan analisis
kebutuhan, metode iteratif melakukan sebaliknya.

21. Pendekatan iteratif bervariasi, tetapi sebagian besar menggabungkan tugas di SDLC
dengan cepat, dan tumpang tindih. Gambar 11-9 menunjukkan bagaimana tugas dapat
dilakukan untuk proyek yang diharapkan akan dirilis dalam 6 bulan. Perhatikan
bagaimana tugas diurutkan, tetapi tidak berakhir sebelum tugas berikutnya dimulai.
Pendekatan umum yang digunakan dalam metode iteratif yang membantu pengembang
perangkat lunak menghidupkan aplikasi dengan lebih cepat disebut pengembangan
aplikasi cepat (RAD). Pengembang membuat prototipe perangkat lunak yang dapat
mereka bagikan dengan pengguna dan mendapatkan umpan balik mereka untuk
melakukan koreksi dan peningkatan sebelum menghabiskan lebih banyak waktu untuk
membangun versi yang berfungsi penuh. Pengguna akhir jauh lebih terbantu ketika
mereka dapat melihat prototipe meskipun sebagian besar sebenarnya tidak berfungsi.
Pendekatan ini bekerja dengan baik dengan fase yang tumpang tindih yang khas dari
pengembangan iteratif, dan juga sering digunakan dalam pendekatan pengembangan
perangkat lunak lainnya.

22. Metode Agile
Metode pengembangan perangkat lunak tangkas menggunakan pendekatan yang kurang
terstruktur di mana tugas tidak diurutkan sesuai dengan SDLC. Sebaliknya, banyak
aktivitas terjadi secara bersamaan. Tim pengembangan biasanya sangat kohesif dan
biasanya terkolokasi daripada terdistribusi secara geografis seperti tim dalam proyek air
terjun. Tim tangkas juga mencakup satu atau lebih pengguna bisnis yang didedikasikan
untuk proyek tersebut. Durasi pengembangan, yang disebut “kotak waktu”, cukup
singkat, seringkali hanya 2 hingga 6 minggu.

23. Scrum
menawarkan kerangka kerja untuk pengembangan perangkat lunak yang bergantung
pada tim yang terjalin erat dan kohesif yang melakukan “sprint” masing-masing selama
2 hingga 4 minggu. Suara pelanggan dalam tim disebut "pemilik produk", dan orang ini
memastikan proyek menambah nilai bisnis. Dia mungkin seorang eksekutif pemasaran
jika proyek tersebut melibatkan hubungan pelanggan atau seorang manajer dari
keuangan jika fitur baru akan meningkatkan proses penagihan.

24. Pemrograman Ekstrim (XP)
Metode tangkas berbasis tim lainnya, pemrograman ekstrem (XP), berfokus pada rilis berkala
perangkat lunak yang dapat diterapkan dan kotak waktu untuk pengembangan. Pendekatan
ini menekankan empat prinsip dasar: coding, testing, listening, dan design. Sebuah proyek
dimulai dengan cerita pengguna, sering kali ditulis pada kartu indeks 3 × 5, dan tim
menyusunnya menjadi rencana untuk fitur yang akan ada di rilis perangkat lunak berikutnya.
Fitur yang membedakan XP adalah bahwa pengembang bekerja berpasangan, meninjau
pekerjaan satu sama lain, saling memberikan umpan balik, dan menguji kode seperti yang
tertulis. Seringkali pasangan akan duduk berdampingan, melihat monitor yang sama dan
mendorong keyboard dan mouse bolak-balik saat mereka berkolaborasi untuk menghasilkan
solusi pengkodean yang baik. Penekanan kuat XP pada pengujian juga merupakan fitur
penting, dan salah satu alasan pengembangannya adalah untuk meningkatkan kualitas
perangkat lunak. Kualitas perangkat lunak yang buruk merugikan ekonomi AS sekitar $59
miliar per tahun, dan pengujian yang lebih menyeluruh dapat membantu mengurangi
pemborosan tersebut.

25. Membandingkan pendekatan
pengembangan perangkat lunak

26. Jenis Proyek
pendekatan pembangunan sangat bergantung pada jenis proyek. Untuk
Misalnya, pendekatan berulang akan bekerja dengan baik untuk proyek di mana
persyaratannya bisa diluncurkan dalam fase diskrit sebagai rilis.
Kejelasan persyaratan juga dapat mempengaruhi pilihan. Metode air terjun akan
berfungsi jika persyaratannya jelas, stabil, dan mudah untuk mendefinisikan dengan
baik di muka. Ketika kebutuhan bisnis berubah dengan cepat, proyek panjang
berdasarkan metode air terjun akan gagal dan pendekatan tangkas harus digunakan.

27. Budaya organisasi
Budaya organisasi juga merupakan elemen penting. Pindah ke pengembangan tangkas pendekatan berarti
lebih dari memprogram berpasangan atau mengadopsi Scrum yang penuh warna kosakata. Ini adalah
pergeseran budaya yang mungkin tidak nyaman bagi banyak tim pengembangan. Setelah bertahun-tahun
menggunakan metode air terjun, misalnya, pengembang cenderung menolak perubahan atau penambahan
kebutuhan setelah tahap analisis dilakukan. Mereka melihatnya sebagai pengerjaan ulang, dan mereka
mencoba mengunci persyaratan melalui dokumen tertulis, kontrak, dan pengguna sign-off. Metode
tangkas membutuhkan pengembang yang menerima perubahan persyaratan, karena mereka memahami
bahwa tujuan akhir adalah untuk mengembangkan perangkat lunak itu pengguna benar-benar ingin, bukan
hanya menyelesaikan proyek tepat waktu. Pergeseran budaya lainnya adalah dari mentalitas "aku" menjadi
"kita". Metode air terjun menekankan tugas-tugas berurutan, sehingga pengembang yang menyelesaikan
tugas mereka tepat waktu menganggap mereka sukses bahkan jika proyek itu sendiri tertinggal. Tapi tim
tangkas secara kolektif bertanggung jawab atas pengiriman, dan anggota tim harus saling membantu
mencapai tujuan yang akan dicapai sukses. Tim harus kohesif dan saling percaya, karena pekerjaan dan
karier masing-masing anggota mungkin tergantung pada kinerja seluruh tim

28. Apakah Air Terjun Mati?
Kegembiraan seputar metode iteratif dan gesit yang gesit telah menghasilkan prediksi tentang malapetaka
untuk metode air terjun. Namun survei menunjukkan bahwa pendekatan lama masih banyak digunakan,
terlepas dari rekam jejaknya yang mengecewakan. Salah satu alasannya bertahan adalah karena para
manajer bisnis nyaman dengan strukturnya yang logis dan familiar. Tantangan budaya yang terkait dengan
metode gesit juga lebih besar dari yang diantisipasi beberapa organisasi. Mereka menemukan bahwa
pengembangan tangkas membutuhkan lebih banyak disiplin, tidak kurang, terutama untuk proyek yang
lebih besar, dan karyawan membutuhkan pembinaan dan waktu untuk menyesuaikan diri dengan
pendekatan berorientasi tim. Beberapa memilih untuk tidak melakukan peralihan itu. Pengembangan
perangkat lunak outsourcing juga cenderung ke arah metode air terjun. Sekali tahap persyaratan selesai,
kontraktor menggunakan hasilnya untuk menentukan biaya keseluruhan proyek, sebelum menandatangani
kontrak. Jika klien menginginkan perubahan persyaratan di tengah jalan, atau menambahkan fitur di luar
lingkup persyaratan awal, maka harga akan naik. Namun, untuk menghindari risiko metode air terjun
tradisional, perusahaan mengadaptasi metode ini ke kerangka waktu yang jauh lebih pendek dan tujuan
yang lebih terfokus, seringkali menambahkan kelincahan metode ke dalam campuran. Proyek-proyek
berkepanjangan di mana perangkat lunak dikirimkan bertahun-tahun setelah persyaratan dikumpulkan,
sebagian besar, adalah masa lalu.

29. Pengadaan perangkat lunak:
strategi "beli"

30. bagaimana organisasi memutuskan apakah membangun
atau membeli, juga langkah Langkah yang di gunakan
jika membeli system informasi
Karena perusahaan perangkat lunak komersial menambahkan lebih banyak fitur dan
mengurangi biaya lisensi, organisasi semakin mempertimbangkan strategi "beli", daripada
memilih custom development

31. Pro dan contra dari membeli dan membangun
Gambar tersebut menperlihatkan pro dan kontra utama yang terkait dengan sistem custom
development dan perangkat lunak yang dikemas sebelumnya.

32. Proses pengadaan
Gambar ini akan menunjukkan SDLC, termasuk langkah-langkah yang diambil organisasi
ketika mereka memutuskan untuk mengejar strategi "beli".
Selama fase awal SDLC, staf TI dan pengguna bisnis harus secara sistematis menjelajahi
lanscape perangkat lunak yang dikemas sebelumnya yang mungkin sesuai dengan
kebutuhan organisasi tersebut.

33. Adaptasi dan customisasi
Ketika solusi yang dikemas memenuhi 75% atau lebih dari kebutuhan organisasi, apa yang
terjadi ke 25% lainnya? Salah satu kemungkinannya adalah bagi perusahaan untuk
menyesuaikan prosesnya sendiri dengan Mengevaluasi respons terhadap RFP pada kriteria
tertimbang.

34. Elemen manusia dalam
pengembangan dan
pengadaan sistem

35. Unsur manusia mempengaruhi pengembangan dan pengadaan sistem,
sebagian karena orang dari berbagai bagian organisasi bekerja sama
dalam tim lintas fungsi, dan komunikasi kemungkinan masalah muncul.
Manajer senior harus menekankan nilai strategis sistem dan menginspirasi
karyawan untuk bekerja sama. Organisasi dapat mempekerjakan
konsultan untuk membantu implementasi sistem, sehingga profesional
sistem informasi perlu mengembangkan kontrak yang efektif untuk
keterampilan manajemen.

36. peran manajemen senior
Manajer senior memainkan peran kunci dalam pengembangan dan pengadaan
sistem, salah satunya harus menekankan nilai strategis dari sistem informasi baru
untuk organisasi dan melalui kemimpinan mereka dapat membawa perubahan
untuk organisasi
CIO dan manajer senior di unit bisnis harus menjaga komunikasi yang bagus untuk
mengimplementasikan layanan cloud dengan bijak dan aman, dan untuk
menghindari miss komunikasi antara CIO dan manager

37. Bekerja dengan konsultan
konsultan merupakan pekerja yang ahli dalam suatu bidang
Bekerja dengan consultan memiliki kerugian dan keuntungan antara lain:
Keuntungan
-memberikan akses organisasi ke pakar yang lebih ahli dalam bidang tersebut
-dan organisasi tidak perlu menugaskan terlalu banyak orang
Kerugian
-karyawan organisasi jadi tidak ikut terlibat sehingga mereka kehilangan kesempatan
mempelajari hal baru
-mungkin mereka jadi merasa kurang berkontribusi dalam perubahan organisasi

38. SEKIAN DAN TERIMA KASIH
KELOMPOK 6