makalah pembangunan sistem informasi
Post on 04-Aug-2015
432 Views
Preview:
TRANSCRIPT
MAKALAH
PEMBANGUNAN SISTEM INFORMASI
Makalah ini disusun untuk memenuhi tugas mata kuliah Analisis Perancangan Sistem Informasi
Dosen pengampu Sigit Pramudyo MT
Di susun oleh:
Gilar Imam Ariyadi 10660002
Purnomo 10660011
Donny Andika P 10660021
Isrul Muhaeri H 10660039
Arif Hidayat 10660046
UNIVERSITAS ISLAM NEGERI SUNAN KALIJAGA
YOGYAKARTA
BAB I
PENDAHULUAN
Setelah tujuan ditetapka banyak rute tujuan tersebut dan banyak mode transportasi.
Anda dapat mengambil jalan super besar, jalan raya atau jalan belakang, atau anda dapat
terbang. Menentukan rute yang baik tergantung padatujuan dan prioritas anda.
Sejauh ini, kita telah mendiskripsikan satu set dasar fase-fase yang mengisi
metodologi FAST kita. Dulu metodologi “satu cocok untuk semua” adalah biasa untuk
kebanyakan proyek; sekarang ada berbagai macam proyek, teknologi dan strategi
pengembangan. Satu ukuran tidak dapat digunakan pad semua proyek. Seperti banyak
metodologi kontemporer, FAST menyediakan rute-rute dan setrategi-setrategi alternatif untuk
mengakomodasi type proyek , tujuan teknologi, keterampilan pengembangan,dan paradigma
pengembangan yang berbeda.
BABII
RUMUSAN MASALAH
1. Apa saja jenis pendekatan pembangunan sistem informasi?
2. Jelaskan tiap tahap pembangunan?
Rute dan Strategi Alternatif
Ada banyak rute untuk mencapai tujuan yang telah ditetapkan. Bisa lewat jalan super
besar, jalan raya atau terbang. Pada bagian ini akan mendeskripsikan beberapa rute dan
strategi FAST.
- Metodologi dan rute dapat mendukung opsi apakah membangun solusi perangkat
lunak sendiri atau membeli.
- Metodologi mungkin sangat preskriptif.
- Metodologi dapat dikarakteristikan sebagai model-driven.
- Metodologi model-driven dengan cepat bergerak ke fokus pada teknologi berorientasi
objek yang digunakan untuk mengkontruksi kebanyakan sistem .
- Pendekatan-pendekatan yang product-driven cenderung menekankan baik prototyping
cepat atau menuliskan kode program secepat mungkin.
1. Strategi Pengembangan Model-Driven
Satu pendekatan tertua yang paling banyak digunakan untuk menganalisis dan
mendesain sistem informasi disarankan pada pemodelan sistem. Model sistem adalah
gambar sebuah sistem yang mewakili realitas yang di harapkan. Model-driven
development sebuah strategi pengembangan sistem yang menekankan pembuatan gambar
model-model sistem untuk membantu visualisasi dan analisis masalah, mendefinisikan
persyaratan bisnis, dan mendesain sistem informasi.
Rute pengembangan
model-driven untuk FAST dapat
di ilustrasikan sebagai berikut:
1. Model-model sistem mungkin ada dari proyek yang menciptakan sistem saat ini.
2. Sebelumnya perlu dipelajari bahwa penting untuk menentukan ruang lingkup untuk
sebuah proyek. Salah satu cara paling sederhana untuk berkomunikasi adalah dengan
model gambar yang menunjukan definisi lingkup.
3. Beberapa teknik pemodelan sistem memerlukan model-model yang ada yang ekstensif
untuk mengidentifikasikan masalah dan kesempatan untuk perbaikan sistem.
4. Pernyataan persyaratan adalah salah satu produk jadi terpenting dari pengembangan
sistem.
5. Kebanyakan teknik model-driven mensyaratkan bahwaanalis mendokumentasikan
persyaratan bisnis dengan model-model sistem logis.
6. Sebagai hasil fase analisis keputusan, analisis mungkin menghasilkan model-model
yang mengilustrasikan arsitektur aplikasi.
7. Banyak teknik model-drivenyang mensyaratkan bahwa analis mengembangkan
model-model yang mengilustrasikan spesifikasi desain fisik. Model fisik menunjukan
tidak hanya apakah sebuah sistem itu atauapa yang dilakukan tapi bagaimana sistem
itu diimplementasikan dengan teknologi.
8. Sistem-sistem informasi baru harus dijalin dalam struktur proses bisnis organisasi,
akibatnya analis dan pengguna mungkin mengembangkan model-model proses bisnis
yang didesain ulang.
9. Kontruksi menerjemahkan model-model sistem fisik kedalam perangkat lunak.
10. Akhirnya sistem operasional mungkin memasukan model-model yang
mengilustrasikan aliran dan prosedur.
Ringkasnya, model sistem dapat dihasilkan sebagai bagian dari produk jadi dari
kebanyakan fase. Pendekatan yang model-driven menekankan pemodelan sistem. Ada
beberapa teknik model-driven yang berbeda terutama dalam arti tipe-tipe model yang
mensyaratkan analis sistem untuk menggambar dan memvalidasi.
Pemodelam Proses ditemukan dalam analisis terstruktur dan metodologi desain pada
tahun 1978. Blok-blok pembangun sistem informasi berisi beberapa fokus yang mungkin :
pengetahuan, proses, dan antar muka. Prosesm modeling teknik berpusat pada proses yang
dipopulerkan teknik metodologi analisis dan desain terstruktur yang menggunakan model
persyaratan bisnis untuk memperoleh desain perangkat lunakefektif untuk sebuah sistem.
Pemodelan Data sebuak teknik berpusat pada data yang digunakan untuk
memodelkan persyaratan data bisnis dan mendesaian seistem database yang memenuhi
persyaratan tersebut.
Pemodelan Objek adalah hasil dari kemajuan teknis. Kebanyakan bahasa
pemrograman dan metode didasarkan pada munculnya teknologi projek.
2. Strategi Pngembangan Aplikasi Cepat/ rapid application developent (RAD)
RAD yaitu sebuah strategi pembangunan sistem yang menekankan kecepatan
pengembangan melalui keterlibatan pengguna yang ekstensif dalam konstruksi, cepat,
berulang dan bertambah serangkaian prototype/ prototipe bekrja sebuah sistem yang pada
skhirnya berkembang kedalam sistem final (sebuah versi).
Gagasan-gagasan dasar RAD adalah:
Lebih aktif melibatkan para pengguna sistem dalam aktivitas analisis, desain,
konstruksi.
Mengorganisasikan pengembangan sistem kedalam rangkaian seminar yang intensif
dan berfokus bersama dengan para Pemilik, pengguna, analisis, desainer, dan
pembangun sistem.
Mengakselerasi fase-fase analisis dan desain persyaratan melalui pendekatan
kontruksi berulang.
Memperpendek waktu yang diperlukan sebelum para pengguna mulai melihat sebuah
sistem yang bekerja.
Sebuah prototype berkembang menjadi sistem informasi final. Rute RAD untuk
FAST diilustrasikan pada gambar dibawah ini.Berikut keterangan:
1. Penekanan pada pengurangan waktu dalam pengembangan aplikasi dan sistem; oleh
sebab itu, Fase analisis masalah awal, analisis persyaratan, dan analisis keputusan
dikonsolidasikan dan diakselerasi. Setelah analisis awal diatas pendekatan RAD
berulang melalui “siklus” fase-fase yangpaling baik.
2. Spesifikasi desain fisik dan Logis biasanya secara signifikan dipendekan dan
diakselerasi. Pada tiap pengulangan dalam siklus hanya beberapa spesifikasi yang
akan dipertimbangkan.
3. Beberapa proses mungkin harus didesain ulang untuk merefleksikan integrasi aplikasi
perangkat lunak yang berkembang.
4. Aplikasi yang telah selesai akan berasal dari pengulangan final dalam siklus.
5. Setelah tiap prototipe atau subsistem yang berfungsi dikontruksi dan diuji,para
pengguna sistem diberi kesempatan untuk “mengalami” bekerja dengan prototipe
tersebut.
6. para analis dan desainer sistem akan meninjau kembali arsitektur dan desain aplikasi
untuk menyediakan umpan balik teknis dan pengarahan untuk pengulangan
selanjutnya dalam siklus RAD.
7. Berdasarkan umpan balik tersebut, para analis sistem akan mengidentifikasi tujuan
perbaikan sistem disempurnakan dan atau persyaratan bisnis.
8. Berdasarka umpan balik tersebut, para analis sistem dan desainer sistem akan
mengidentifikasi arsitektur aplikasi disempurnakan dan perubahan desain.
9. Pada akhirnya, sistem tersebut akan dianggap bernilai untuk diimplementasikan. Versi
selanjutnya dari sistem ini mungkin akan berulang dalam siklus RAD.
Meskipun bukan sebuah persyaratan RAD yang kaku, namun durasi perulangan
prototype dapat dibatasi dengan sebuah teknik timeboxing.
3. Strategi Implementasi Paket Aplikasi Komersial
Solusi komersial terakhir adalah enterprise resource planning. Solusi ERP
menyediakan semua aplikasi sistem informasi inti untuk keseluruhan bisnis. Rute
metodologi FAST untuk integrasi paket aplikasi komersial sebenarnya tidak ditunjukan
untuk Proyek ERP.
Gagasan dasar dibalik rute implementasi paket aplikasi komersial adalah
- Solusi-solusi perangkat lunak yang dipaket harus diseleksi untuk memenuhi
kebutuhan
- Solusi perangkat lunak yang dipaket tidak hanya mahal dibeli tapi juga mahal
diimplementasikan.
- Paket perangkat lunak biasanya harus dikostumasi dan diintegrasi kedalam bisnis.
- Paket perangkatlunak jarang memenuhi semua persyaratan bisnis untuk memuaskan
pelanggan.
Rute implementasi paket aplikasi komersial diilustrasikan gambar berikut:
1. Keputusan untuk membeli paket ditentukan dalam fase analisis masalah.
2. Analisis masalah termasuk penelitian pasar teknologi awal untuk untuk
mengidentifikasi solusi paket apa yang sudah ada dalam perangkat lunak.
3. Setelah mengidentifikasi, persyaratan tersebut harus dikomunikasikan pada vendor
perangkat lunak yang menawarkan solusi aplikasi yang berfungsi.
4. Vendor menyerahkan proposal atau penetapan untuk solusi aplikasi mereka.
5. Sebuah kontrak dan pesanan dinegosiasikan dengan vendor pemenang untuk
perangkat lunak dan mungkin juga layanan yang diperlukan untuk menginstal dan
merawat perangkat tersebut.
6. Vendor menyediakan perangkat lunak dan dokumentasi aplikasi komersial titik tolak.
7. Ketika paket aplikasi dibeli, organisasi tersebut harus selalu mengubah proses dan
praktik bisnisnya untuk bekerja secara efisian.
8. Paket aplikasi jarang memenuhi semua persyaratan bisnis setelah instalasi. Umumnya
gap analisis harus dilakukan untuk memenuhi persyaratan bisnis mana yang tidak
dipenuhi.
9. Aplikasi komersial titik tolak diinstal dan diuji. Perubahan-perubahan yang di izinkan
berdasarkan opsi, pilihan, parameter diselesaikan dan diuji.
10. Perubahan apapun pada perangkat lunak add-on didesain dan dikontruksikan untuk
memenuhi persyaratan bisnis tambahan.
4. Strategi hibrid
Sebuah strategi yang umum diterapkan pada kedua rute model-driven dan
pengembangan aplikasi cepat adalah strategi incremental (bertambah), dan tiap tahap
mengimplementasikan sebuah versi sistem final dengan menggunakan rute RAD atau
variasi-variasi lain pada rute mengkin saja terjadi. Tahapan-tahapan :
1. Ada lebih dari satu iteration.
2. Tiap-tiap iteration menghasilkan sebuah versi sistem final.
3. Versi sistem final tiap iteration dijadikan satu dan diseleksi selama fase definisi
lingkup dan dinegosiasikan sebagai bagian pernyataan kerja.
4. Dari hasil diatas dapat diperoleh sistem operasi dan pemeliharaan.
5. Perawatan sistem
Perawatan sistem ditujukan untuk memandu proyek-proyek sepanjang operasi dan
tahap dukungan siklus hidup mereka. Disini titik mulai perawatan sistem tergantung pada
masalah untuk dipecahan dan semua rute pada akhirnya berujung pada penempatan sebuah
sistem baruke dalam operasi. Tahapan-tahapan :
1. Proyek perawatan dipicu oleh kombinasi pengguna dan umpan balik teknis.
Umpan balik semacam itu dapat mengidentifikasi masalah, kesempatan, dan
perintah baru.
2. Proyek perawatan tersebut diawali oleh permintaan perubahan sistem yang
mengidentifikasi masalah, kesempatan atau perintah.
3. Perbaikan yang termudah adalah dengan bug perangkat lunak(error). Proyek
semacam itu umumnya langsung ke fase kontruksi ulang dan dipecahan dengan
relatif cepat.
4. Kadang-kadang cacat desain dalam sistem terlihat setelah implementasi. Untuk
proyek perawatan ini, fase desain fisik dan integrasi perlu dikunjungi ulang,
diikuti oleh fase konstruksi dan pengiriman.Dalam hal ini proses bisnis hanya
perlu didesain ulang.
5. Persyaratan teknis baru mungkin mendikte perubahan. Untuk proyek ini fase
analisi keputusan mungkin perlu dikunjungi lagi untuk menentukan resiko dan
kepraktisan konversi database operasional yang ada ke versi yang baru. Akan
berlanjut ke fase desain fisik, konstruksi, dan pengiriman bila perlu.
6. Bisnis secara konstan berubah. Salah satu pemicu yang paling umum untuk
proyek reengineering adalah persyaratan bisnis baru. Fase analisis persyaratan
harus dikunjungi lagidengan fokus impak persyaratan baru tersebut pada sistem
yang ada. Berlanjut ke fase desai logis, analisis keputusan, desain fisik,
konstruksi, dan pengiriman.
7. Selagi bisnis berubah, masalah bisnis baru, kesempatan, dan batasan yang
signifikan dapat dijumpai. Pekerjaan dimulai dengan fase analisis masalah dan
berlanjut ke fase-fase berikutnya.
8. Hasil final tipe proyek perawatan adalah sistem bisnis operasional yang diperbarui
yang mengirimkan nilai perbaikan pada para pengguna dan pemilik sistem.
BAB VI
DAFTAR PUSTAKA
Whitten, J.L.Bentley.L.D.Dittman.K.C.”System Analysis and Desaign Method”,Mc
Grawtlill,2000.
top related