Anda di halaman 1dari 20

SISTEM INFORMASI MANAJEMEN

CHAPTER 9:
METHODOLOGIES FOR CUSTOME SOFTWARE
DEVELOPMENT
Dosen Pengampu: Dr. Ir. Maryono Supoyo, MS.

KELOMPOK 5

1. Ahmad Sugianto 041524253028


2. Fadly Alwahdy 041524253030
3. Monika Gabriela Budisantoso 041524253032
4. Fesi Dita Anugra 041524253032
5. Novi Lailiyul Wafiroh 041524253033
6. Movie Rahmatika Suryani 041524253035

MAGISTER AKUNTANSI

FAKULTAS EKONOMI DAN BISNIS

UNIVERSITAS AIRLANGGA

2016
1. LATAR BELAKANG
Jika organisasi memiliki ahli sistem informasi, mereka cenderung
mengembangkan custom application nya sendiri. Jika organisasi tidak
memiliki ahli SI, mereka cenderung bekerja sama dengan pemasok dari
luar untuk menyediakan personel SI secara temporer atau untuk
mengembangkan custom software bagi organisasi.
Pada bagian ini disajikan dua pendekatan untuk mengembangkan
customized application yaitu (1) pendekatan system development life
cycle (SDLC) tradisional dan (2) problem-oriented analytical and query
environment, serta dua pendekatan terbaru yaitu rapid application
development (RAD) dan agile development approach.
2. SYSTEMS DEVELOPMENT LIFE CYCLE METHODOLOGY
System Development Life Cycle didefinisikan sebagai sebuah
pendekatan yang bersifat tradisional untuk mengembangkan software
yang terkostumisasi untuk sebuah organisasi. Ada tiga fase dalam system
life cycle yaitu definition, construction dan implementation. SDLC
merupakan pendekatan yang sangat terstruktur. SDLC memberi titik awal
untuk memahami apa saja yang terkait dalam pengembangan sistem
aplikasi.
a. The SDLC Steps
SDLC mencakup tiga fase dan delapan tahap, namun jumlah ini juga
bergantung pada kondisi organisasi.
(1) Fase definition
merupakan fase penting
karena menggambarkan
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
system) dapat membangun sistem yang benar dan sesuai dengan
kebutuhan.
(2) Dalam fase construction, ahli SI menghasilkan working system
berdasarkan spesifikasi yang ditetapkan di awal. Fase ini mencakup
penggunaan teknik terstruktur seperti data flow diagram, E-R models dan
structure charts.
Karakteristik utama pendekatan SDLC adalah review formal secara
luas oleh anggota project team dan manajemen di akhir tiap tahap utama.
Review ini bertujuan memastikan apakah kebutuhan seluruh pihak yang
terpengaruh oleh sistem telah
terpenuhi, isu telah
dipertimbangkan serta dampak
sistem yang sedang
dikembangkan terhadap sistem
lain yang sudah ada harus
dipertimbangkan. Tanpa
persetujuan formal, project
team tidak dapat memulai
tahap selanjutnya.
(3) Dalam fase
implementation, sistem baru akan dijalankan dalam organisasi dan akan
terus dipertahankan atau diubah ketika diperlukan sehingga akan
senantiasa mencerminkan apa yang diperlukan organisasi. Dua tahapan
terakhir (operations and maintenance) dimasukkan dalam life cycle untuk
mengakui bahwa pengembangan custom application merupakan investasi
utama persahaan yang akan memiliki biaya operasional dan pemeliharaan
secara terus-menerus.
Figure 9.2 merinci biaya yang harus dikeluarkan perusahaan untuk
mengembangkan sistem, terlihat bahwa tahap requirement definition
memakan biaya paling besar karena penentuan kebutuhan bisnis secara
matang dapat mencegah banyaknya biaya yang dikeluarkan pada tahap
selanjutnya karena definisi kebutuhan yang kurang memadai. Pendekatan
SDLC tradisional disebut juga watefall model karena output satu tahapan
akan menjadi input tahapan selanjutnya namun juga dapat dikatakan
sebagai pendekatan spiral karena perubahan kebutuhan atau desain
menyebabkan kita kembali ke tahap awal.
b. Initiating New Systems Projects
Ada beberapa pendekatan yang dilakukan untuk memutuskan aplikasi
baru. Proses ini dimulai dari pengajuan proposal secara formal oleh
departemen bisnis. Proposal ini akan direview dan disusun prioritasnya
oleh komite pada tingkat departemen atau divisi. Ketika memerlukan
investasi dan sumber daya dalam jumlah besar, departemen mungkin
diminta menunggu karena memerlukan persetujuan manajemen puncak
dan dewan komisaris. Setelah proposal disetujui dan sumber daya
ditetapkan ke suatu proyek, proses formal SDLC dimulai.
Bagi beberapa proyek, persetujuan awal hanya berfungsi sebagai
dukungan untuk melanjutkan ke tahap analisis kelayakan (feasibility
analysis). Setelah itu, diperlukan persetujuan tambahan. Dokumen hasil
analisis kelayakan dijadikan dasar pengambilan keputusan apakah akan
investasi pada suatu custom application.
c. Definition Phase
1. Feasibility Analysis (Analisis Kelayakan)
Project manager dan analis sistem ditugaskan untuk bekerja bersama
manajer bisnis dalam menyusun analisis kelayakan sistem yang diajukan
secara rinci. Ada tiga jenis kelayakan yang akan dinilai yaitu dari segi
ekonomi, operasional dan teknis. Analis sistem informasi bekerja bersama
sponsoring manager (manajer yang mengusulkan sistem) dan atau
manajer bisnis yang lain untuk mendefinisikan apa yang diharapkan dapat
dilakukan sistem yang baru, output yang akan dihasilkan, input yang akan
diterima, bagaimana input diperoleh dan database yang diperlukan.
Aktivitas penting dalam tahap ini adalah mendefinisikan lingkup atau
batasan sistem, terkait siapa yang akan dilayani sistem, apa yang akan
dilakukan dan tidak dilakukan sistem serta pemrosesan data yang
dimasukkan dan tidak dimasukkan. Analis SI bertanggung jawab menilai
kelayakan teknis sistem berdasarkan pengetahuan teknologi terkini,
keahlian personel internal dan infrastruktur yang diperlukan untuk
mengembangkan dan mendukung sistem yang diajukan.
Manajer bisnis bertanggung jawab untuk menilai kelayakan ekonomi
dan operasional sistem yang diajukan. Operational feasibility terkait
menilai sejauh mana sistem yang diajukan dapat mengatasi isu bisnis atau
menimbulkan peluang. Manajer bisnis dan analis SI bekerja sama untuk
menyusun cost-benefit analysis dari sistem yang diajukan untuk
menentukan economic feasibility. Manfaat dapat berwujud contohnya
biaya yang dapat dihindari, seperti penghematan karena berkurangnya
personel, ruang dan persediaan; pendapatan baru yang akan muncul
karena pengambilan keputusan dan perencanaan yang lebih cepat atau
membuka peluang penjualan maupun manfaat tak berwujud (intangible
benefit) contohnya layanan pelanggan yang lebih baik, informasi yang
lebih akurat atau komprehensif untuk pengambilan keputusan.
Analis SI bertanggung jawab menetapkan biaya pengembangan
proyek sehingga ia harus menyusun project plan mencakup estimasi
waktu (dalam minggu atau bulan) tiap tahap dalam proses pengembangan
sistem dan estimasi anggaran sampai penerapan sistem. Organisasi juga
perlu mempertimbangkan risiko yang menghambat pencapaian manfaat
sistem baru misal hambatan dari pemain kunci (political feasibility) atau
perbedaan opini mengenai spesifikasi sistem baru, ketidakpastian
estimasi, staf pengembangan yang tidak berpengalaman.
Hasil analisis kelayakan adalah system proposal atau business
case yaitu dokumen 10-20 halaman yang berisi gambaran singkat dari
pihak eksekutif dan ringkasan rekomendasi, deskripsi apa yang akan
dilakukan sistem dan bagaimana sistem dijalankan, analisis biaya,
manfaat dan risiko sistem dan proyek yang diajukan serta rencana
pengembangan sistem. Dokumen ini akan dibahas dan disetujui oleh
sponsor dan IS project manager lalu direview oleh pihak yang berwenang
menyusun prioritas dan menyetujui sistem.
2. Requirements Definition
Tahap ini dimulai jika dokumen yang dihasilkan dari feasibility
analysis telah disetujui. Tahap ini menentukan ketepatan pengembangan
sistem dan memerlukan partisipasi dari manajemen pengguna. Jika tahap
ini tidak dilakukan dengan baik, akan tercipta sistem yang salah dan biaya
perubahan yang besar. Requirement definition disebut juga system
analysis atau logical design, yaitu definisi proses, arus data dan hubungan
antar data. Analis sistem bertanggung jawab memastikan bahwa
persyaratan digambarkan secara rinci untuk diberikan pada pihak yang
membangun sistem.
Sering terjadi ketidak sepakatan antar manajer bisnis dalam
menentukan spesifikasi aplikasi. IS Project manager dan analis sistem
bertanggung jawab membantu pengguna mencapai kesepakatan.
Konsultan juga dapat digunakan untuk memfasilitasi proses ini. Contoh
metode yang dapat dilakukan untuk memperoleh gambaran spesifikasi
sistem adalah wawancara personel kunci baik secara individu maupun
kelompok yang disebut Joint Application Design (JAD) atau review
dokumen terkait aplikasi (rencana bisnis, kritik terhadap sistem saat ini,
deskripsi pekerjaan, deskripsi aplikasi atau hasil penelitian terhadap
sistem serupa). Terkadang analis sistem mengobservasi pelaksanaan
pekerjaan pihak yang akan didukung oleh sistem baru atau perubahan
sistem sehingga hambatan, kesalahan dan kebingungan karena sistem
lama dapat diketahui.
Hasil tahap ini adalah system requirement document yang berisi
gambaran rinci input, output sistem dan proses yang dilakukan untuk
mengubah input menjadi output serta revisi terhadap cost-benefit analysis
dan revisi rencana untuk sisa tahapan pengembangan proyek. Analis SI
bertanggung jawab merumuskan dan mengubah dokumen spesifikasi
sistem sementara manajer bisnis bertanggung jawab memastikan bahwa
spesifikasi tertulis telah lengkap dan tepat. Hasil tahapan ini akan
dimintakan persetujuan oleh manajer bisnis dimana sistem dibangun dan
manajer SI yang tepat. Setelah dokumen tsb disetujui, artinya spesifikasi
sistem telah bersifat tetap dan ketika terjadi perubahan, harus dilakukan
proses persetujuan formal kembali.
d. Construction Phase (Fase Pembangunan)
1. System Design
Ahli SI merancang sistem secara teknis atau fisik berdasarkan
dokumen yang dihasilkan pada fase definition. Dalam tahap ini, dilakukan
pemilihan hardware dan software apa yang digunakan untuk menjalankan
sistem, merancang struktur dan isi database serta mendefinisikan
processing module (program) yang terkandung dalam sistem dan
keterkaitan antar program.
2. System Building
Ada dua aktivitas yang dilakukan dalam tahap ini yaitu menghasilkan
program dan mengembangkan atau meningkatkan database dan file yang
akan digunakan oleh sistem. Pekerjaan ini dilakukan oleh ahli SI. Pengguna
diminta menjawab pertanyaan apakah terdapat spesifikasi yang belum
tercata dan membantu menafsirkan dokumen spesifikasi dan desain. Pada
tahap ini juga dilakukan pembelian hardware baru dan software
pendukung, yang mengharuskan konsultasi dengan personel SI dan
operasi.
3. System Testing
Meliputi pengujian oleh ahli SI dan pengguna. Tiap modul harus diuji
lalu modul-modul akan disusun menjadi sub sistem dan diuji. Subsistem
lalu digabungkan menjadi suatu sistem lalu diuji. Ahli SI bertanggung
jawab untuk menghasilkan sistem berkualitas tinggi dan menjalankan
sistem secara efisien. Pengujian dilakukan untuk memastikan spesifikasi
telah terpenuhi, kinerja memadai bahkan saat lalu lintas sistem padat dan
sistem cukup aman.
Pengguna sistem juga bertanggung jawab melakukan pengujian
disebut user acceptance testing untuk memastikan sistem berjalan
dengan handal dan melakukan apa yang diharapkan dapat dilakukan.
Keterlibatan pengguna akhir dalam tahap pengujian akan meningkatkan
komitmen terhadap sistem baru serta menjadi awal pelatihan penggunaan
sistem baru.
e. Implementation Phase
Kesuksesan fase ini bergantung pada peran manajer bisnis. Proyek
sistem sering melibatkan perubahan besar pada pekerjaan pihak yang
akan menggunakan sistem sehingga perubahan ini harus diantisipasi dan
direncanakan sebelum impelementasi aktual dilakukan. 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.
1. Installation
Ahli SI dan pengguna berperan dalam tahap ini mencakup
merumuskan file dan database serta mengubah data yang relevan dari
satu atau lebih sistem lama ke sistem baru. Terkadang data pada sistem
lama mungkin tidak akurat dan tidak lengkap sehingga pengguna perlu
merapikannya. Proses ini mencakup memasukkan data yang telah direvisi
sehingga memerlukan upaya dari departemen pengguna. Aktivitas penting
lainnya dalam tahap instalasi adalah melatih pengguna akhir sistem serta
pihak lain yang terpengaruh oleh sistem baru.
Beralih ke sistem baru mungkin merupakan proses yang sulit bagi
pengguna karena sistem baru harus diintegrasikan dengan aktivitas
organisasi. Pengguna tidak hanya harus mempelajari bagaimana
menggunakan sistem baru namun juga perubahan cara melakukan
pekerjaan. Sistem baru akan gagal jika pengguna tidak mau atau tidak
mengetahui cara menggunakannya. Beberapa strategi untuk beralih ke
sistem baru yaitu:
1) Parallel strategy : organisasi terus beroperasi dengan sistem lama
bersamaan dengan sistem baru sampai sistem baru dirasa sudah
memadai dan sistem lama dapat dihentikan. 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.
2) Pilot strategy : sistem
baru hanya
diperkenalkan pada
satu bagian organisasi
sebelum diterapkan
pada keseluruhan
organisasi. 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.
3) Phased conversion : 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.
4) 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.
2. Operations
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:
a. Versi pengembangan (development version)
b. Versi pengujian (tets version)
c. 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:
a. Dokumentasi sistem untuk IS specialist yang akan mengoperasikan
dan memelihara (maintain) system
b. Dokumentasi untuk pengguna

3. Maintenance
Pemeliharaan (maintenance) merupakan sebuah proses untuk
melakukan perubahaan setelah sistem tersebut digunakan. Alasan
melakukan pemeliharaan adalah untuk memperbaiki kesalahanyang
terdapat dalam sistem software. Proses maintenance juga bisa dilakukan
untuk bisa beradaptasi terhadap adanya perubahandalam 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 system (enhance the system).
Dalam kenyataanya, proses pemeliharaan (maintenance) ini
memerlukan lebih banyak waktu dan sumber daya daripada tahap
pengembangan / pembangunan sistem. Hal tersebut digambarkan dalam
gambar disamping (Figure 9.5).
Untuk bisa melakukan perubahan dalam sistem, maintenance
programmer pertama-tama harus mempertimbangkan mengenai
beberapa hal yang diantaranya adalah:
a. Program apa yang harus diubah
b. 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:
a. Ketika perubahan dilakukan dalam sistem yang kompleks maka hal
tersebut bisa menimbulkan ripple effect. Jika satu terpengaruh maka
yang satunya juga akan terpengaruh
b. 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
c. 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 disamping.
f. The SDLC Project Team
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:
a. Biasanya secara tradisional berasal dari personel IS
b. Tetapi bisa juga berasal dari unit bisnis
c. Bisa juga gabungan
d. Manajer proyek ini berfungsi sebagai penanggung jawab 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:
a. Mempunyai kemampuan untuk menyelesaikan masalah (problem
solving skill)
b. Mempunyai pengetahuan tentang teknologi informasi yang memadai
c. Memiliki pemahaman mengenai bisnis perusahaan dengan baik

g. Managing an SDLC Project


Kriteria untuk menentukan sebuah
proyek SDLC sukses diantaranya adalah :
a. Ukuran proyek yang bisa di kelola (manageable project size). Proyek
yang dikerjakan sebisa mungkin dapat dikelola dalam artian jika proyek
IS yang dikerjakan scopenya 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 kesuksesanakan lebih dimungkinkan.
b. 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.
c. 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.
h. Kelebihan dan Kekurangan SDLC
Keuntungan penggunaan SDLC diantaranya adalah:
a. Proses SDLC ini sangat terstruktur dan mempunyai proses yang
sistematis
b. Dalam fase definisi seperti yang telah dijelaskan diatas, bahwa proses
SDLC ini memerlukan requirement definition secara keseluruhan
c. Menyajikan milestone yang jelas dengan persetujuan manajemen pada
setiap fase
Sedangkan kelemahan sistem SDLC diantaranya adalah:
a. SDLC ini cenderung memakan waktu yang lama
b. Dan memerlukan komitmen dari seluruh orang yang ada dalam
perusahaan (top-down)

3. 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 purwarupa.
Dalam pendekatan prototype ini memungkinkan pembangunan system
dengan lebih 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 dankurang 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:
1. 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 system
2. Langkah kedua analis system (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.
3. Langkah ketiga berkaitan dengan tanggung jawab 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.
4. 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.
5. 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.
6. Jika prototype tersebut sudah menjadi sistem operasional perusahaan,
dalam langkah keenam ini system builder kemudian melakukan
penyelesaian fase konstruksi dengan caramelakukan perubahan yang
penting untuk meningkatkan efisiensi.
7. Tahap terakhir adalah melakukan penginstallan dari system prototype
tersebut, mengoperasikannya dan melakukan maintenance.
a. Tim Proyek Prototype (The Prototype Project Team)
Tim proyek prototype ini bisa berasal dari perwakilan IS dan user yang
membutuhkan system 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 feed back terhadap prototype yang ada.
b. Keuntungan dan Kekurangan Pendekatan Prototype
Beberapa keuntungan penggunaan pendekatan prototype
diantaranya adalah:
a. Hanya diperlukan identifikasi terhadap kebutuhan dasar perusahaan
untuk memutuskan untuk menggunakan pendekatan prototype
b. Pendekatan ini digunakan untuk mengembangkan sistem yang
mengubah secara radikal cara kerja suatu sistem sehingga user atau
pengguna bisa langsung melakukan evaluasi terhadap system.
c. Dengan menggunakan prototype ini, perusahaan bisa melakukan
eksplorasi atas teknologi baru (berupa prototype itu sendiri)
d. Sistem dapat diuji dengan lebih cepat
e. Biaya dan manfaat dapat langsung diketahui setelah user
menggunakan initial prototype
f. Lebih mudah untuk diterima oleh pengguna
Sedangkan untuk kelemahan penggunaan pendekatan protype adalah
sebagai berikut:
a. Terdapat keterbatasan dalam hal keamanan (security) dan
pengendalian terhadap fitur dalam aplikasi yang digunkan
b. Dokumentasi akhir bisa jadi tidak lengkap
c. Akan sangat sulit untuk mengelola harapan pengguna atas sistem
karena sistem ini merupakan sistem prototype.
4. NEWER APPROACHES
Permintaan terhadap perkembangan sistem aplikasi baru yang lebih
cepat meningkat pada decade terakhir. Pada bagian ini, akan dibahas
mengenai dua sistem baru yang memiliki kecepatan lebih tinggi
dibandingkan dengan SDLC.
1. Rapid Application Development (RAD)
RAD merupakan metode hibrid yang mengkombinasikan aspek
metode SDLC dan prototyping sehingga sistem dapat dihasilkan dengan
lebih cepat. Rapid application development (RAD) atau rapid
prototyping adalah model proses pembangunan perangkat lunak yang
tergolong dalam teknik incremental (bertingkat). RAD menekankan pada
siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat
adalah batasan yang penting untuk model ini. Rapid application
development menggunakan metode iteratif (berulang) dalam
mengembangkan sistem di mana working model (model bekerja) sistem
dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan
kebutuhan (requirement) user dan selanjutnya disingkirkan. Working
model digunakan kadang-kadang saja sebagai basis desain dan
implementasi sistem final.

2. Agile Methodologies
Agile method serupa dengan metode prototyping dan RAD namun
siklus penghantaran kode produk baru lebih singkat dan mengharuskan
kolaborasi antar anggota tim. Fowler (2003) merekomendasikan bahwa
agile methodologies cocok untuk situasi yang dinamis, anggota tim yang
memiliki motivasi kuat dan pelanggan bersedia menjadi anggota tim inti
dan tim inti yang mengembangkan sistem relatif berukuran kecil. Agile
methodologies meliputi berbagai teknik dan metode contohnya extreme
programming dan scrum.
Extreme Programming (XP), merupakan sebuah pendekatan atau
model pengembangan perangkat lunak yang mencoba menyederhanakan
berbagai tahapan dalam proses pengembangan tersebut sehingga
menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding
tetapi meliputi seluruh area pengembangan perangkat lunak. XP
mengambil pendekatan ekstrim dalam iterative development.
Dalam XP, terdapat 5 nilai yang menjadi pondasi yaitu
communication, simplicity, feedback, courage, dan respect.
Komunikasi yang efektif antara pengembang perangkat lunak dan pihak-
pihak yang terlibat sangatlah penting. Dalam XP, desain dijadikan
kebutuhan intermediate. Desain dibuat sesederhana mungkin agar mudah
mengimplementasikan code. Disini dapat terjadi perubahan struktur
desain atau perubahan source code tanpa mengubah fungsi utamanya
(refactoring). Feedback akan diberikan saat peningkatan dan
pengimplementasian perangkat lunak.
SCRUM adalah salah satu metode rekayasa perangkat lunak dengan
menggunakan prinsip-prinsip pendekatan AGILE, yang bertumpu pada
kekuatan kolaborasi tim, incremental product dan proses iterasi untuk
mewujudkan hasil akhir. Di dalam setiap iterasi scrum, semua anggota tim
saling berkolaborasi untuk menyelesaikan setiap incremental product yang
telah direncanakan dan disepakati bersama. Dalam proses, setiap iterasi
juga akan melakukan kegiatan analisis, merencanakan desain dan
selanjutnya program siap untuk dikembangkan. Setelah program selesai,
program juga akan diuji melalui proses testing yang telah direncanakan
oleh tim, sehingga akhirnya program tersebut menjadi sebuah incremental
product yang siap untuk di-deploy dan di-integrasi-kan dengan semua
program yang telah dibuat sebelumnya.
Semua kegiatan diatas akan dilakukan oleh tim dengan konsep self-
organizing, artinya semua anggota tim akan bekerja sama untuk
mengelola kerja mereka sesuai dengan kesepakatan mereka. Mereka
bertanggung jawab untuk menghasilkan incremental product dengan
membagi tugas secara bersama dan berdiskusi tanpa ada hirarki. Seorang
yang berpengalaman testing, sangat dimungkinkan untuk berkonstribusi
ditahap analisa dan desain. Atau seorang programmer akan membantu
aktifitas testing. Secara sederhana, anggota tim akan merencanakan tugas
secara bersama dan melakukannya secara bersama sebagai sebuah
kolaborasi tim.