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 end-

user 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:

- Mempunyai kemampuan untuk menyelesaikan masalah (problem solving skill)

- Mempunyai pengetahuan tentang teknologi informasi yang memadai

- Dan memiliki pemahaman mengenai bisnis perusahaan dengan baik

XI. 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:

- SDLC ini cenderung memakan waktu yang lama

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

XIII. 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 dilakukan dalam

mengimplementasikan pendekatan prototype yang diantaranya adalah:

- 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

melakukan perubahan yang penting untuk meningkatkan efisiensi.

- Tahap terakhir adalah melakukan penginstallan dari system prototype tersebut,

mengoperasikannya dan melakukan maintenance.

XIV. 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.