Chapter 9

Methodologies For Custom Software Development

I.

Latar Belakang
Jika sebuah perusahaan mempunyai mempunyai sumberdaya yang cukup untuk

membangun/mengembangkan

sistem

informasinya

sendiri,

maka

perusahaan

dapat

melakukannya. Namun sebaliknya jika perusahaan tidak memiliki sumberdaya untuk

membangun/ mengembangkan sistem informasinya sendiri maka perusahan bisa menggunakan
jasa vendor untuk urusan tersebut.
Dalam chapter 9 ini, pertama yang akan dibahas adalah dua pendekatan untuk
mengembangkan customize application yang diantaranya adalah:
-

Pendekatan SDLC yang tradisional

Evoluntary prototyping approach

System Development Life Cycle didefinisikan sebagai sebuah pendekatan yang bersifat
tradisional untuk mengembangkan software yang terkosutumisasi untuk sebuah organisasi. Ada
beberapa langkah yang terdapat dalam pendekatan ini yang disajikan dalam gambar dibawah ini:

Fase definisi ini merupakan fase yang kritis karena dalam fase ini mulai diidentifikasi mengenai
cara kerja pengembangan sistem dan dalam fase ini juga di break down secara detail mengenai
apa saja yang seharusnya dilakukan oleh sistem agar spesialis IS (tim yang bekerja membangun
sistem) dapat membangun sistem yang benar dan sesuai dengan kebutuhan.

Dalam fase konstruksi, tim IT yang bertugas membangun dan mengembangkan sistem membuat
working sistem yang sesuai dengan spesifikasi yang telah ditetapkan dalam awal pembuatan
proyek IS. Pada fase konstruksi ini, untuk membangun sebuah working system yang tepat tim IS
yang bertugas membutuhkan banyak tekinik terstruktur misalnya saja DFD, model E-R, dan
chart.
Salah satu karakteristik dari SDLC adalah adanya review yang secara formal dilakukan oleh para
anggota tim pengembangan IS dan beserta bisnis manajemen pada akhir setiap fase proyek
tersebut diatas. Tujuan dilakukannya review tersebut adalah untuk memferivikasi kebutuhan end
user yang akan menggunakan sistem tersebut, selain itu review dilakukan juga untuk
mendiskusikan isu-isu penting yang terjadi selama proses pembuatan atau pengembangan sistem.
Tanpa adanya persetujuan formal (formal approval) maka tim proyek IS tersebut tidak bisa
melanjutkan pekerjaannya ke fase berikutnya misalnya saja peralihan antara fase definisi
menjadi fase konstruksi. Oleh karena itu, setiap penyelesaian fase pada SDLC merupakan sebuah
milestone dalam proses pembuatan/pengembangan sistem.
Dalam fase implementasi, sistem yang baru mulai di pasang (install) dan mulai beroperasi dalam
perusahaan. Selain sudah mulai beroperasi, sistem yang baru dipasang tersebut juga mulai
dimaintain dengan cara dilakukan modifikasi sesuai dengan kebutuhan sehingga bisa terus
memenuhi kebutuhan organisasi.
Dalam fase implementasi, operation and maintenance, sistem baru yang telah berjalan (new
system implemented) dianggap sebagai investasi perusahaan yang akan menimbulkan beberapa
biaya untuk maintenance sistem.
Pada era 1980, adalah hal yang biasa jika menemukan bentuk aplikasi software yang
terkostumisasi dan berumur lebih dari satu dekade. Hal tersebut dikarenakan aplikasi software
tersebut sudah dimodifikasi sesuai dengan kebutuhan organisasi. Kritik atas penggunaan
software yang terkostumisasi adalah ketika terjadi perubahan pada aplikasi software hal tersebut
bisa menimbulkan krisis dalam perusahaan misalnya saja dalam perjalanan modifikasi software
system tersebut terdapat potensi kegagalan sistem.

Dalam gambar 9.2 disajikan besaran biaya (cost) estimasian dalam setiap tahap SDLC. Perkiraan
tersebut adalah untuk perusahaan dengan ukuran perusahaan yang medium dengan total biaya
implementasi adalah sebesar 1 juta dollar ($1 million).
Breakdowan biaya yang terdapat dalam gambar 9.2 dibawah tidak termasuk didalamnya adalah
biaya yang harus ditanggung oleh tiap unit bisnis untuk melakukan training atas sistem informasi
baru yang digunakan oleh perusahaan.
Dalam banyak metodologi SDLC, dibutuhkan banyak dokumentasi. Misalnya saja pada tahap
awal (early step) sebelum tim proyek IS menuliskan kode-kode komputer, hasil spesifik yang
dapat diberikan oleh masing-masing fase SDLC dituliskan terlebih dahulu. Tahapan SDLC baru
bisa dikatakan selesai jika review formal telah dilakukan dan telah mendapatkan persetujuan dari
manajemen.
II.

Inisiasi Proyek Sistem Baru

Organisasi-organisasi bisnis bisa menggunakan berbagai pendekatan untuk memutuskan

investasi pada suatu aplikasi-aplikasi software. Proses inisiasi ini dimulai dengan melakukan
pengumpulan proposal oleh departemen bisnis yang membutuhkan sistem baru tersebut.
Beberapa perusahaan besar mensyaratkan

agar proposal tersebut untuk di lakukan review

terlebih dahulu dan diprioritaskan. Ketika investasi dan sumberdaya potensial dilibatkan
departemen yang mengajukan proposal tersebut mungkin saja harus menunggu persetujuan
tahunan terlebih dahulu. Ketika budget dari sebuah proyek (dalam hal ini proyek IS) jumlahnya
banyak maka kemungkinan persetujuan untuk hal tersebut dilakukan oleh management executive
committee dan Board of directors. Sedangkan untuk budget yang rendah prosedur persetujuannya
(approval) sampai pada level managemen atas perusahaan, kemungkinan persetujuan bisa
dilakukan dalam waktu yang lebih sering (frequent basis). Berikut disajikan contoh perhitungan
budget dalam fase SDLC

Biasanya proposal mengenai proyek IS yang dibutuhkan oleh suatu unit departemen berisi
tentang deskripsi bahwa unit departemen tersebut membutuhkan aplikasi software yang baru
dengan penjelasan awal mengenai keuntungan potensial penggunaan aplikasi software tersebut
beserta biaya yang dibutuhkan dan risiko yang menyertainya.
Ketika proposal IS tersebut telah disetujui dan sumberdaya untuk mengerjakan proyek tersebut
telah disiapkan oleh perusahaan maka proses formal SDLC sudah bisa dijalankan. Berikut akan
dibahas lebih dalam terkait fase-fase dalam SDLC.
III.
-

Fase Definisi (Definition Phase)

Analisis Kelayakan (Feasibility Analysis)

Dalam langkah pertama dari SDLC, manager proyek IS beserta dengan analis sistem yang
berkitan bersama dengan manajer unit departemen akan menyiapkan analisis kelayakan dari
proyek sistem yang diajukan. Analisis kelayakan tersebut dilakukan dengan mendasarkan pada
tiga hal berikut:
-

Aspek ekonomi
Aspek operasional
Aspek teknikal

Dalam proses analisis kelayakan (feasibility analysis) it specialist bekerja bersama dengan
manajer unit departemen yang mengajukan proposal IS tersebut. Hal tersebut dilakukan untuk
mengetahui detail mengenai bagaimana sebuah aplikasi softare atau sistem IT akan bekerja, apa

output yang dihasilkan dari sistem tersebut, apa saja input yang harus ada atau input yang
dibutuhkan untuk menghasilkan output yang diinginkan, bagaimana cara memperoleh input
tersebut dan kemungkinan database yang dibutuhkan. Aktifitas selanjutnya yang juga penting
adalah perlunya melakukan definisi terhadap cakupan atau batasan sistem seperti misalnya:
-

Siapakah pengguna sistem tersebut

Apa yang bisa dilakukan oleh sistem tersebut
Apa yang tidak bisa dilakukan oleh sistem tersebut
Dan pemrosesan data seperti apa yang dilakukan oleh sistem dan juga pemrosean data
apa yang tidak bisa dilakukan oleh sistem

IS specialist dalam hal ini bertanggungjawab untuk melakukan penilaian kelayakan teknikal dari
sistem informasi yang akan dibangun. Analisis kelayakan tersebut dilakukan berdasarkan
pengetahuannya bersama dengan staff IT perusahaan. Hal lain yang perlu dipertimbangkan oleh
IS Specialist dalam melakukan analisis kelayakan adalah mengenai pertimbangan sumberdaya
dan infrastruktur yang dibutuhkan untuk mengembangkan dan mendukung sistem yang akan
dibangun.
Manajer bisnis yang terkait bertanggungjawab untuk menganalisis kelayakan ekonomi dari
proposal yang diajukan dan kelayakan operasional dari sistem tersebut. Analisis kelayakan
operasional (operational feasibility) juga berkaitan dengan bagaimana sistem yang diajukan
untuk dibangun atau dikembangkan tersebut bisa mengatasi isu-isu bisnis (business issue) yang
dihadapi perusahaan yang memicu untuk dilakukannya pengembangan atau pembangunan sistem
informasi yang baru.
Langkah selanjutnya Manajer bisnis perusahaan dan IS analyst bekerja bersama untuk
melakukan analisis biaya dan manfaat (cost benefit analysis) untuk menentukan kelayakan
sistem yang diajukan secara ekonomi. Misalnya saja berapa biaya yang dibutuhkan beserta
berapa keuntungan pendapatan yang akan disediakan dari implementasi sistem yang baru.
Jika diperhatikan, keuntungan yang bisa diperoleh dari implementasi sistem baru tidak selalu
harus berwujud, banyak diantaranya yang tidak berwujud atau intangible sehingga sulit diukur
dengan satuan uang (misalnya rupiah atau dollar). Contoh dari keuntungan tidakberwujud
(intangible benefit) yang diperoleh dari implementasi sistem baru adalah pelayanan konsumen
yang lebih baik, informasi yang lebih akurat dan komprehensif yang digunakan untuk proses

pengambilan keputusan (decision making), proses yang lebih cepat atu bisa juga berupa moral
karyawan yang lebih baik.
Selain menganalisis mengenai jumlah uang yang harus dikeluarkan, perlu juga dilakukan
estimasi mengenai lama pengerjaan proyek IS tersebut. Estimasi tersebut dilakukan oleh IS
analyst. Proses estimasi ini akan sangat sulit dilakukan jika scope pekerjaan implementasi sistem
tergolong pekerjaan yang besar.
Hal selanjutnya adalah analisis risiko. Biasanya perusahaan pada saat mengembangkan atau
membangun sistem yang baru akan membuat portofolio risiko dari yang paling tinggi sampai
yang paling rendah. Risiko ini bisa muncul dari hambatan-hambatan yang ada dalam mencapai
keuntungan yang diharapkan dari sistem informasi yang akan dibangun (contoh dari risiko ini
misalnya adalah penolakan terhadap sistem baru yang dilakukan oleh beberapa karyawan
perusahaan) ketidakpastian dalam estimasi ekonomi dan ketidaksiapan karyawan atas teknologi
baru yang dibangun atau dikembangkan.
Hasil dari analisis kelayakan adalah dokumken yang biasanya berisi 10 sampai dengan 20
halaman yang termasuk didalamnya terdapat overview dari pihak eksekutif perusahaan berserta
rekomendasi yang berupa deskripsi tentang apa yang akan dilakukan oleh sistem tersebut dan
bagaimana sistem tersebut beroperasi. Selain itu pada dokumen hasil tersebut juga disertakan
mengenai analisis biaya-manfaat, risiko tentang sistem yang akan dibangun atau dikembangkan.
Dokumen tersebut biasanya disebut dengan system proposal document atau business case.
IV.

Requirement Definition

Jika system proposal document tersebut disetujui maka langkah selanjutnya adalah requirement
definition dimulai. Bagaimana sebuah sistem dapat dibangun dengan benar atau dikembangkan
dengan benar bergantung pada bagaimana tahap requirement definition dilakukan. Jika langkah
ini dilakukan dengan tidak benar/ tidak semestinya, maka bisa saja sistem yang dibangun salah
atau tidak tepat.
Dalam fase requirement definition lebih berkepentingan terhadap logical design yang berfokus
pada proses, aliran data (data flows) dan hubungan antar data (data interrelationship)
dibandingkan dengan implementasi secara fisik.

Analis sistem (IS analyst) dalam fase ini bertanggungjawab untuk memastikan bahwa
requirement definition yang dibutuhkan telah cukup ada/tersedia. Dalam fase ini mungkin saja
terlihat mudah untuk mendefinisikan apa yang sebenarnya sistem lakukan (proposed system do)
pada level end user. Tetapi sebenarnya hal ini sangat sulit untuk mengidentifikasi apa yang
sebearnya sistem lakukan untuk membaca kode-kode komputer agar sistem tersebut dapat
berjalan dengan baik. Banyak dari aplikasi/ software business yang sangat kompleks, yang
digunakan untuk mendukung pekerjaan fungsional manusia atau mendukung sebuah proses yang
melibatkan unit-unit bisnis lain.
Dalam tahap ini dibutuhkan IS specialist yang benar-benar professional dan handal agar bisa
mendefinisikan design

aplikasi software atau sistem yang dibutuhkan oleh end usernya.

Biasanya untuk mengatasi kerumitan ini, perusahaan juga mendatangkan konsultan dari luar
untuk membantu menyelesaikan kerumitan tersebut.
V.

Fase Pembangunan (Construction Phase)

Setelah dalam tahap sebelumnya dibahas mengenai design logical dari sistem yang akan
dibangun, maka dalam fase ini IS specialist melakukan design mengenai physical, technical,
sytem berdasarkan pada dokumen fungsional pada fase definisi yang telah dijelaskan diatas.
Dalam tahap desain sistem (system design), IS specialist memutuskan beberapa hal diantaranya
adalah:
-

perangkat keras (hardware) dan system software apa yang digunakan untuk dapat

mengoperasikan sistem
Desain dan struktur database yang dibutuhkan
dan desain mengenai processing modules yang terdiri dari sistem itu sendiri dan
hubungan diantara sistem yang ada

Desain yang baik (a good design) merupakan hal yang kritis dalam fase ini karena kualitas
teknikal dari sistem tidak bisa lagi ditambahkan setelah sistem tersebut terimplementasi. Oleh
karenanya desain yang sesuai harus dibangun dari awal. Berikut disajikan gambar mengenai
karakteristik sistem yang berkualitas tinggi.

Seperti yang terlihat dalam gambar 9.3 sistem dikatakan berkualitas jika terdapat kontrol atau
pengendalian untuk memastikan bahwa data yang diinputkan akurat sehingga hasil atau output
yang dihasilkan pun akurat. Sistem yang baik juga bisa diaudit dimana sistem tersebut bisa di
telusuri (trace). Misalnya saja auditor bisa melakukan penelusuran terhadap suatu transaksi
melalui sistem atau aplikasi yang digunakan oleh perusahaan. Selain itu sebuah sistem yang
berkualitas juga bisa diandalkan (reliable) misalnya saja ketika sistem tersebut error maka sistem
harus mempunyai kemampuan untuk melakukan recovery atau pemulihan dan resume operasi
tanpa harus kehilangan data.
Sistem yang baik juga harus kokoh atau robust. Selain itu, sistem juga harus efisien, menyedikan
respon yang cepat, menghasilkan output yang efisien dan input yang juga efisien, penyimpanan
data yang efisien, dan efisien dalam menggunakan sumberdaya komputer.
Sistem juga harus fleksibel dan bisa didokumentasikan dengan mudah (well documented) baik
untuk end user. Selain itu, sistem yang baik merupakan sistem yang bisa di maintain dan
disesuaikan mengikuti perubahan kebutuhan organisasi.
Untuk bisa memastikan bahwa desain sistem yang baru tersebut akurat dan lengkap, biasanya IS
specialist akan melakukan walktrough desain yang akan diimplementasi dengan kolega dan
dengan manajer bisnis end user terkait dengan menggunakan model grafik (graphical model)
yang terdapat pada chapter 8.
Hasil dari tahapan desain sistem yang paling utama adalah dokumentasi desain yang detail yang
kemudian akan diberikan kepada programmer dan staf teknikal lainnya. Model-model desain
sistem diciptakan atau dihasilkan dari berbagai alat pengembangan seperti misalnya diagram

struktur fisik sistem (diagram of the system physical structure) juga merupakan hasil dari tahap
ini.
Dokumentasi sistem juga termasuk deskripsi detail tentang semua database yang dibutuhkan dan
spesifikasi program untuk masing-masing sistem.
Dalam tahap ini juga diperlukan persetujuan dari end users dan IS manager atas dokumentasi
yang dihasilkan tersebut sebelum sistem yang diajukan benar-benar dibangun.
VI.

Pengujian Sistem (System Testing)

Pengetesan sistem ini membutuhkan banyak sekali waktu. Tahapan ini meliputi pengujian oleh
IS specialist yang kemudian diikuti dengan pengujian oleh pengguna sistem. Pertama-tama setiap
modul of code harus dites, kemudian modul-modul tersebut dirangkai kedalam subsistem dan di
uji. Kemudian setelah subsitem tersebut di uji maka susbsistem tersebut kemudian digabungkan
dan selanjutnya dilakukan pengujian terhadap keseluruhan sistem yang terintegrasi. Masalah
dapat saja muncul dalam tahap berbagai tahap pengujian yang telah diuraikan diatas. Tetapi
koreksi atas kesalahan akan menjadi lebih sulit ketika banyak komponen yang terintegrasi satu
dengan yang lainnya sehingga tahap ini membutuhkan banyak waktu untuk mengatasi masalah
yang mucul dalam tahap pengujian.
IT spesialis bertanggungjawab untuk menghasilkan sistem informasi yang berkualitas yang juga
bisa bekerja secara efisien . Tahap pengujian ini dilakukan untuk memastikan bahwa persyaratan
(requirement) yang dibutuhkan untuk membangun sebuah sistem terpenuhi dan sistem bisa tetap
bekerja walapun load-nya tinggi dan juga pada situasi yang stressful selain itu keamanan
sistemnya pun bisa tetap terjaga dengan baik.
Selain dilakukan pengujian oleh IS specialist, pengujian yang juga penting dilakukan adalah
system user testing atau dinamakan juga user acceptance testing. Tujuan dari pengujian tersebut
adalah untuk memastikan bahwa sistem yang dibangung bekerja secara handal dan melakukan
apa yang harus dilakukan oleh sebuah sistem.

Hal tersebut berarti user harus merancang

pengujian data dan prosedur dalam sistem tersebut. Rencana untuk pengujian ini harus sudah
dimulai setelah fase definisi.

Penelitian yang berkaitan dengan fase pengujian menunjukan bahwa partisipasi end-user dalam
tahap pengujian (testing phase) bisa memberikan kontribusi terhadap komitmen end-user
terhadap sistem yang baru.
VII.

Fase Implementasi (Implementation Phase)

Baik IS spesialis maupun end user mempunyai peran yang penting dalam fase implementasi ini.
Partisipasi mereka dalam tahap isntalasi sistem yang baru meliputi pembangunan database dan
file dan melakukan konversi dari data yang relevan dari sistem yang lama ke sistem yang baru.
Beberapa data yang tidak relevan, akurat dan tidak lengkap dihapus dan tidak dimasukan
kedalam sistem yang baru.
Aktivitas yang krusial lainnya dari fase implementasi adalah training untuk end user yang akan
menggunakan sistem tersebut. Kegiatan training ini juga meliputi memotivasi orang atau
karyawan atau end user untuk mengubah kebiasaanya sehingga sistem yang baru tersebut bisa
diterima dengan baik.
Selain aktivitas diatas, melakukan install atas hardware dan software juga merupakan salah satu
aktivitas dalam fase implementasi. Salah satu konstrain yang mungkin ada dan ditemui adalah
resistensi dari karyawan untuk menggunakan sistem baru tersebut.
Konversi yang dilakukan atas sistem lama menuju sistem baru, bisa jadi menjadi proses yang
sulit untuk end-user. Hal tersebut karena sistem yang baru tersebut harus diintegrasikan kedalam
aktivitas organisasional. Pengguna akhir (end-users) tidak hanya harus belajar untuk
menggunakan sistem baru tersebut tetapi juga harus mulai merubah cara bekerja mereka. Bahkan
jika software yang dibangun perusahaan sudah sempurna, sistem akan mengalami kegagalan
ketika end-user nya tidak menginkan adanya sistem baru tersebut terimplementasi atau pun enduser tidak tahu bagaimana cara menggunakan sistem tersebut.
Terdapat beberapa strategi dalam melakukan transisi dari sistem lama ke sistem yang baru.
Berikut disajikan strategi implementasi tersebut.

Dalam strategi pararel, perusahaan atau organisasi tetap menggunakan sistem yang lama
bersaman dengan sistem yang baru sampai dengan sistem yang baru bisa bekerja dengan baik
dan dengan seharusnya setelahnya perusahaan akan melakukan penghentian pemakaian sistem
yang lama. Strategi ini merupakan strategi konversi yang konvensional.
Kelemahan dari strategi ini adalah karyawan harus menggunakan kedua sistem (sistem lama dan
sistem yang baru) hal ini tentu saja kurang efisien. Selain itu, strategi ini digunakan untuk
mengetahui hasil akhir atau output dari sistem yang baru apakah telah sesuai dengan yang
diharapkan ataukah tidak. Ketika tidak, maka sumber masalah harus bisa ditemukan dan
dilakukan tahapan koreksi atau perbaikan. Oleh karena itu, dalam tahapan ini tingkat stress bisa
jadi sangat tinggi.
Strategi kedua adalah pilot strategy, strategi ini menyediakan pilihan yang cukup menarik.
Dalam strategi ini, penggunaan sistem yang baru hanya diimplementasikan hanya untuk satu
bagian dari organisasi saja. Tujuan strategi ini untuk mengatasi masalah yang berkaitan dengan
implementasi sistem baru ketika nanti sistem tersebut diimplementasikan secara keseluruhan
dalam organisasi. Contohnya adalah untuk perusahaan dengan banyak cabang, strategi ini
mungkin saja layak digunakan hanya pada satu cabang perusahaan saja sehingga bisa diperoleh
pengalaman mengenai bagaimana pengkonversian data dan beberapa masalah procedural yang
muncul. Jika masalah tersebut dapat diatasi dengan baik, maka sistem tersebut dapat
diimplementasi pada seluruh organisasi.

Untuk perusahaan yang kompleks, strategi yang mungkin cocok untuk diimplementasikan adalah
strategi phased conversion. Contoh penerapan phased conversion strategy misalnya adalah
perusahaan yang mempunyai proses order dan sistem pengendalian persediaan yang besar.
Pertama-tama perusahaan bisa melakukan konversi atas order entry

sehingga personel

perusahaan bisa dengan mudah menginput pesanan pelanggan (customer order) dan kemudian
mencetak pesanan pelanggan dalam format perusahaan. Selanjutnya perusahaan dapat
melakukan konversi atas sistem pengendalian gudang persediaan kedalam komputer sehingga
kedua aktivitas tersebut yaitu proses input pesanan pelanggan dan proses pengendalian
persediaan di gudang bisa dihubungkan menjadi satu.
Dalam strategi ini, perusahaan bisa memperoleh keuntungan yang lebih cepat atas
pengimplementasian sistem yang baru.
Strategi selanjutnya adalah cutover strategy.

Dalam startegi ini, perusahaan langsung

mengabaikan secara keseluruhan (totally abandon) sistem yang lama ketika sistem yang baru
diimplementasikan dalam perusahaan. Cutover strategy ini mempunyai risiko melekat yang
lebih besar tetapi disisi lain, strategi ini juga menarik untuk dilakukan ketika perusahaan tidak
bisa mengimplementasikan dua sistem secara bersamaan.
VIII.

Tahap Pengoperasian (Operation Phase)

Fase kedua dari tahap implementasi adalah tahap pengoperasian aplikasi yang telah dibangun.
Biasanya perusahaan menyimpan kurang lebih tiga versi aplikasi dari aplikasi yang
dibangun/dikembangkan yang diantaranya adalah:
-

Versi pengembangan (development version)

Versi pengujian (tets version)
Versi Produksi atau bisa disebut juga versi jadi dari sebuah aplikasi

Hal yang perlu diperhatikan pada tahap ini adalah pengoperasian sebuah versi aplikasi tidak akan
bisa siap pakai jika dokumentasi dari aplikasi tersebut ada. Dokumentasi tersebut dibagi menjadi
dua jenis yaitu:
-

Dokumentasi sistem untuk IS specialist yang akan mengoperasikan dan memelihara

(maintain) sistem
Dokumentasi untuk pengguna

IX.

Pemeliharaan (Maintenance)

Pemeliharaan (maintenance) merupakan sebuah proses untuk melakukan perubahaan setelah

sistem tersebut digunakan. Alasan melakukan pemeliharaan adalah untuk memperbaiki kesalahan
yang terdapat dalam sistem software.
Proses maintenance juga bisa dilakukan untuk bisa beradaptasi terhadap adanya perubahan
dalam organisasi. Misalnya saja perubahan karena adanya jenis perangkat keras yang baru (new
hardware) dan adanya software system yang baru serta adanya perubahan peraturan pemerintah.
Selain itu, penyebab utama lainnya sebuah perusahaan atau organisasi melakukan pemeliharaan
(maintenance) terhadap sistemnya adalah karena untuk meningkatkan kemampuan sistem
(enhance the system).
Dalam kenyataanya, proses pemeliharaan (maintenance) ini memerlukan lebih banyak waktu dan
sumberdaya daripada tahap pengembangan/pembangunan sistem. Hal tersebut digambarkan
dalam gambar berikut ini:

Untuk bisa melakukan perubahan dalam sistem, maintenance programmer pertama-tama harus
mempertimbangkan mengenai beberapa hal yang diantaranya adalah:
-

Program apa yang harus diubah

Dan bagian spesifik mana dari program yang harus diubah

Selain itu, programmer harus memahami logika dari sistem yang akan diubah. Karena sebuah
sistem perusahaan bisa jadi sangat kompleks maka diperlukan adanya dokumentasi. Hal tersebut
dilakukan untuk mempermudah pemahaman atas sistem itu sendiri.
Beberapa kendala yang mungkin saja terjadi dalam proses maintenance diantaranya adalah:
-

Ketika perubahan dilakukan dalam sistem yang kompleks maka hal tersebut bisa
menimbulkan ripple effect. Jika satu terpengaruh maka yang satunya juga akan

terpengaruh
Masalah lainnya adalah biasanya banyak dari praktisi IS yang memilih untuk
menggunakan sistem yang baru dibandingkan dengan sistem yang lama. Oleh karena itu,

proses pemeliharaan dianggap sebagai low-status work

Kekurangan staff IT untuk maintenance merupakan salah satu masalah karena
perusahaan bisa tertinggal dalam hal sistem informasinya.

Masalah-masalah tersebut kemudian bisa menimbulkan gap antara kebutuhan organisasi untuk
berubah dengan performa actual organisasi seperti yang digambarkan dalam gambar dibawah ini:

X.

Tim Proyek SDLC

Team yang dibentuk untuk melaksanakan SDLC ini biasanya bersifat sementara (temporary).
Personel yang terlibat didalamnya juga terdiri dari perosonel IS dan dari uit bisnis seperti yang
telah dijelaskan diatas. Biasanya tim proyek SDLC ini mempunyai manajer proyek yang
biasanya:

Biasanya secara tradisional berasal dari personel IS

Tetapi bisa juga berasal dari unit bisnis
Bisa juga gabungan
Manajer proyek ini berfungsi sebagai penanggungjawab untuk suksesnya sebuah proyek
sistem dalam menghasilkan sistem yang berkualitas dan dengan budget yang sesuai.

Dalam tim proyek SDLC selain terdapat manajer proyek juga terdapat analis sistem. Analis
sistem ini mempunyai tugas untuk menentukan kelayakan dari sistem yang baru dan untuk
mengembangkan secara detail system requirement untuk aplikasi yang terkostumisasi. Biasanya
analis sistem ini bekerja berdekatan dengan manajer dan end-user. Salah satu kualifikasi penting
yang diantaranya adalah:
XI.

Mempunyai kemampuan untuk menyelesaikan masalah (problem solving skill)

Mempunyai pengetahuan tentang teknologi informasi yang memadai
Dan memiliki pemahaman mengenai bisnis perusahaan dengan baik
Mengelola Proyek SDLC

Kriteria untuk menentukan sebuah proyek SDLC sukses diantaranya adalah:

-

Ukuran Proyek yang bisa di kelola (manageable project size)

Proyek yang dikerjakan sebisa mungkin dapat dikelola dalam artian jika proyek IS yang
dikerjakan scope nya terlalu besar maka akan sangat sulit untuk dapat menyeimbangkan dengan
biaya yang telah dibudgetkan. Selain itu, risiko kegagalan mengerjakan proyek yang besar lebih
tinggi dibandingkan dengan proyek kecil. Selain itu, besar kecilnya proyek IS juga menentukan
lamanya proyek akan selesai. Jika ukuran proyek dapat dikeola dengan baik maka kesuksesan
akan lebih dimungkinkan.
-

Persyaratan Definisi yang Akurat (Accurate Requirement Definition)

Hal ini penting dilakukan seperti yang telah dibahas diatas bahwa requirement definition
dibutuhkan untuk menciptakan design sistem yang baik dan sesuai dengan kebutuhan organisasi.
-

Sponsor eksekutif (Executive Sponsorhip)

Agar proyek IS tersebut suskses diperlukan support dan komitmen dari manajemen eksekutif
perusahaan. Tanpa dukungan dari eksekutif perusahaan, proyek IS akan sulit untuk
dikerjakan.

XII.
-

Keuntungan dan Kerugian SDLC

Keuntungan penggunaan SDLC diantaranya adalah:
Proses SDLC ini sangat terstruktur dan mempunyai proses yang sistematis
Dalam fase definisi seperti yang telah dijelaskan diatas, bahwa proses SDLC ini

memerlukan requirement definition secara keseluruhan

Menyajikan milestone yang jelas dengan persetujuan manajemen pada setiap fase

Sedangkan kelemahan sistem SDLC diantaranya adalah:

XIII.

SDLC ini cenderung memakan waktu yang lama

Dan memerlukan komitmen dari seluruh orang yang ada dalam perusahaan (top-down)
Prototyping Methodology

Metode SDLC yang telah dibahas diatas mendasarkan bahwa kebutuhan bisnis akan sistem
bersifat statis selama masa proyek tersebut dijalankan. Pada masa selanjutnya mulai
dikembangkan pendekatan lain yaitu pendekatan prototyping approach atau pendekatan purwa
rupa. Dalam pendekatan prototype ini memungkinkan pembangunan/ pengembangan sistem
dengan lebuh cepat dan kemudian dapat diperbaiki setelah pengguna mencoba bentuk prototype
tersebut.
Contoh penggunaan prototype ini misalnya saja bentuk prototype selected feature dimana bentuk
prototype hanya untuk beberapa fitur-fitur yang penting dan fitur lainnya terdapat pada modul
selanjutnya.
Pendekatan prototype ini akan menarik jika perusahaan sendiri sulit menentukan mengenai
sistem yang dibutuhka atau ketika perusahaan membutuhkan sistem secara cepat maka
pendekatan prototype ini menjadi penting.
Dalam pembahasan disini, pendekatan prototype diposisikan sebagai alternative dari SDLC.
Ketika sudut pandang tersebut diambil maka pendekatan prototype ini dirasa kurang sesuai dan
kurang praktis jika digunakan pada sistem yang besar dan kompleks. Namun ketika prototype ini
digunakan dalam proses SDLC untuk membantu menentukan kebutuhan dari sistem yang
terkostumisasi maka hal tersebut dapat membuat proses SDLC menjadi sukses. Hal tersebut
karena prototyping menyediakan cara yang praktis bagi perusahaan untuk dapat menggunakan
real

system.

Berikut

disajikan

langkah-langkah

yang

harus

mengimplementasikan pendekatan prototype yang diantaranya adalah:

dilakukan

dalam

Langkah pertama yang dilakukan adalah identifikasi tentang kebutuhan dasar (basic
requirement) dari versi dasar sistem. Analist sistem dan end-user bertemu untuk

membahas mengenai input dan pemrosesan data, dan output dari sistem
Langkah kedua Analis sistem (system builder) kemudian membuat initial prototype
system berdasarkan kebutuhan yang telah diuraikan diatas. System builder kemudian
memilih software tools yang sesuai dan melakukan alokasi terhadap data yang
dibutuhkan sehingga data tersebut dapat diakses dengan mudah. Setelahnya system
builder membangun sistem yang diinginkan menggunakan higher level languages.
Langkah kedua ini bisa memakan waktu beberapa hari sampai dengan beberapa minggu.
Catatan yang penting, tahap kedua ini bisa bekerja dengan baik jika kualitas data yang

dibutuhkan untuk membangun sistem sudah baik.

Langkah ketiga berkaitan dengan tanggungjawab user atau pengguna sistem karena
dalam langkah ketiga ini sistem informasi sudah masuk dalam tahap implementasi
sehingga feedback yang harus ada merupakan hasil dari pengalaman pengguna dalam

menggunakan prototype ini.

Langkah ke empat berhubungan dengan langkah ketiga, pada langkah ini system builder
melakukan modifikasi terhadap sistem untuk memasukan beberapa perubahan yang perlu

dilakukan terhadap sistem prototype tersebut.

Ketika end user sudah merasa puas terhadap prototype system yang telah dimodifikasi
pada langkah ke empat maka barulah langkah kelima dimulai. Langkah ke lima

melibatkan evaluasi terhadap prototype final sebagai sistem operasi.

Jika prototype tersebut sudah menjadi sistem operasional perusahaan, dalam langkah ke
enam ini system builder kemudian melakukan penyelesaian fase konstruksi dengan cara

XIV.

melakukan perubahan yang penting untuk meningkatkan efisiensi.

Tahap terakhir adalah melakukan penginstallan dari system prototype tersebut,
mengoperasikannya dan melakukan maintenance.
Tim Proyek Prototype (The Prototype Project Team)

Tim proyek prototype ini bisa berasal dari perwakilan IS dan user yang membutuhkan sistem
tersebut. Personel yang berada dalam tim proyek prototype ini harus mempunyai kualifikasi
yaitu bisa membangun sistem dengan alat yang canggih (advance tools). Selain itu, diperlukan
juga peranan yang cukup signifikan dari user atau pengguna prototype untuk memberikan
feedback terhadap prototype yang ada.
XV.

Keuntungan dan Kekurangan Pendekatan Prototype

Beberapa keuntungan penggunaan pendekatan prototype diantaranya adalah:

-

Hanya diperlukan identifikasi terhadap kebutuhan dasar perusahaan untuk memutuskan

untuk menggunakan pendekatan prototype.

Pendekatan ini digunakan untuk mengembangkan sistem yang mengubah secara radikal
cara kerja suatu sistem sehingga user atau pengguna bisa langsung melakukan evaluasi

terhadap sistem
Dengan menggunakan prototype ini, perusahaan bisa melakukan eksplorasi atas teknologi

baru (berupa prototype itu sendiri)

Sistem dapat diuji dengan lebih cepat
Biaya dan manfaat dapat langsung diketahui setelah user menggunakan initial prototype
Lebih mudah untuk diterima oleh pengguna

Sedangkan untuk kelemahan penggunaan pendekatan protype adalah sebagai berikut:

-

Terdapat keterbatasan dalam hal keamanan (security) dan pengendalian terhadap fitur

dalam aplikasi yang digunkan

Dokumentasi akhir bisa jadi tidak lengkap
Akan sangat sulit untuk mengelola harapan pengguna atas sistem karena sistem ini

merupakan sistem prototype.