Pages

This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Kamis, 29 Oktober 2009

Notasi DAD Fisik







Selasa, 20 Oktober 2009

Matriks Analisis Kelayakan



Matriks Sistem Kandidat

Analisis Sebab-Akibat

Pernyataan Masalah

Jumat, 16 Oktober 2009

Desain Ulang Proses Bisnis

Salah satu aplikasi paling menarik dari metode-metode analisis sistem adalah business process redesign (BPR). Ketertarikan pada BPR dikendalikan oleh penemuan bahwa kebanyakan sistem informasi dan aplikasi saat ini hanya mengotomatisasi proses-proses bisnis yang ada dan tidak efisien. Birokrasi terotomatisasi tetap birokrasi; otomatisasi tidak selalu menyumbang nilai ke bisnis, dan kenyataannya mungkin mengurangi nilai dari bisnis.
Beberapa proyek BPR fokus pada semua proses bisnis tanpa memperdulikan otomatisasi mereka. Tiap proses bisnis dipelajari dan dianalisis secara mendalam untuk mencari bottleneck, nilai pengembalian, dan kesempatan-kesempatan untuk penghapusan atau penyingkatan. Setelah proses-proses bisnis didesain ulang, kebanyakan proyek BPR diakhiri dengan memeriksa bagaimana teknologi informasi mungkin paling baik diterapkan pada proses-proses bisnis yang diperbaiki. Hal ini dapat menciptakan sistem informasi dan proyek-proyek pengembangan aplikasi baru untuk mengimplementasikan atau mendukung proses-proses bisnis.

Selasa, 06 Oktober 2009

Paket Aplikasi Komersial


Keunggulan COTS:
  • Sistem baru dapat diimplementasikan lebih cepat karena pemrograman ekstensif tidak diperlukan
  • Banyak bisnis tidak mampu menyediakan staf dan keahlian yang diperlukan untuk membangun solusi sendiri
  • Vendor aplikasi menyebarkan biaya pengembangan pada semua pelanggan yang membeli perangkat lunak mereka
  • Vendor aplikasi menerima tanggung jawab perbaikan sistem yang signifikan dan koreksi error.

Kelemahan COTS:
  • Implementasi COTS (Commercial Off-The-Shelf) yang berhasil bergantung pada keberhasilan jangka panjang dan kelangsungan hidup vendor aplikasi
  • Sebuah sistem yang dibeli jarang merefleksikan solusi yang ideal bahwa bisnis dapat meraih keberhasilan dengan sistem yang dikembangkan in-house yang dapat disesuaikan untuk harapan-harapan manajemen dan para pengguna yang tepat
  • Adanya penolakan pada perubahan proses-proses bisnis untuk beradaptasi pada perangkat lunak.

Jumat, 25 September 2009

Rapid Application Development


Rapid Application Development (RAD):
  • Lebih aktif melibatkan para pengguna sistem dalam aktivitas analisis, desain, dan konstruksi
  • Mengakselerasi fase-fase analisis dan desain persyaratan melalui pendekatan konstruksi berulang
  • Memperpendek waktu yang diperlukan sebelum para pengguna mulai melihat sebuah sistem yang bekerja
  • Prinsip dasar di balik prototyping adalah para pengguna mengetahui apa yang mereka inginkan ketika mereka melihatnya bekerja.
Keunggulan RAD:
  1. Berguna untuk proyek-proyek tempat persyaratan-persyaratan pengguna tidak pasti dan tidak tepat
  2. Mendorong pengguna aktif dan partisipasi manajemen
  3. Proyek-proyek memiliki visibilitas dan dukungan lebih tinggi
  4. Para pengguna dan manajemen melihat solusi-solusi yang berbasis perangkat lunak dan bekerja lebih cepat daripada pengembangan yang model-driven
  5. Error dan penghilangan cenderung untuk dideteksi lebih awal dalam prototype daripada dalam model sistem
  6. Pengujian dan pelatihan adalah produk tambahan alami dari pendekatan prototyping yang mendasar
  7. Pendekatan berulang adalah proses yang “alami” karena perubahan adalah faktor yang diharapkan selama pengembangan.
Kelemahan RAD:
  1. RAD mendorong mentalitas “mengkode, mengimplementasi, dan memperbaiki” yang meningkatkan biaya seumur hidup yang diperlukan untuk mengoperasikan, mendukung, dan merawat sistem
  2. Prototype-prototype RAD dapat dengan mudah memecahkan masalah-masalah yang salah karena analisis masalah disingkat atau diabaikan
  3. Prototype berbasis RAD mungkin membuat para analis minder untuk mempertimbangkan alternatif-alternatif teknis lain yang lebih bernilai
  4. Kadang-kadang lebih baik membuang sebuah prototype, tapi para stakeholder sering enggan melakukannya karena menganggapnya sebagai hilangnya waktu dan usaha dalam produk saat ini
  5. Penekanan pada kecepatan dapat berdampak buruk terhadap kualitas yang disebabkan jalan-jalan pintas yang disarankan dengan buruk melalui metodologi tersebut.

Model-Driven Development


Model-driven development menekankan pembuatan gambar model-model sistem untuk membantu visualisasi dan analisis masalah, mendefinisikan persyaratan bisnis, dan mendesain sistem informasi. Model sistem adalah gambar sebuah sistem yang mewakili realitas atau realitas yang diharapkan.
Keunggulan model-driven:
  1. Spesifikasi persyaratan lebih menyeluruh dan didokumentasikan dengan baik
  2. Persyaratan bisnis dan desain sistem lebih mudah divalidasi dengan gambar daripada dengan kata-kata
  3. Lebih mudah mengidentifikasi, mengkonseptualkan, dan menganalisis solusi-solusi teknis alternatif
  4. Spesifikasi desain cenderung solid, stabil, dapat beradaptasi, dan fleksibel karena berbasis model dan dianalisis lebih menyeluruh sebelum dibangun
  5. Sistem dapat dikonstruksikan dengan lebih tepat pertama kali saat dibangun dari spesifikasi berbasis model yang menyeluruh dan jelas.
Kelemahan model-driven:
  1. Banyak memakan waktu
  2. Model tersebut dapat sebagus pemahaman para pengguna akan persyaratan tersebut
  3. Model bukanlah perangkat lunak
  4. Tidak fleksibel.

Kamis, 10 September 2009

Kerangka Pemecahan Masalah PIECES


James Wetherbe mengembangkan kerangka PIECES (Performance, Information, Economics, Control, Efficiency, Service) untuk mengelompokkan masalah (problems), kesempatan (opportunities), dan perintah (directives).

PERFORMANCE
A. Produksi – jumlah kerja selama periode waktu tertentu
B. Waktu respons – penundaan rata-rata antara transaksi atau permintaan dengan respons ke transaksi atau permintaan tersebut

INFORMATION (dan Data)
A. Output
1. Kurangnya informasi
2. Kurangnya informasi yang diperlukan
3. Kurangnya informasi yang relevan
4. Terlalu banyak informasi – “kelebihan informasi”
5. Informasi yang tidak dalam format yang berguna
6. Infomasi yang tidak akurat
7. Informasi yang sulit untuk diproduksi
8. Infomasi yang tidak tepat waktunya untuk penggunaan selanjutnya
B. Input
1. Data tidak di-capture
2. Data tidak di-capture pada waktunya untuk berguna
3. Data tidak di-capture secara akurat – terdapat error
4. Data sulit di-capture
5. Data di-capture secara berlebihan – data yang sama di-capture lebih dari sekali
6. Terlalu banyak data di-capture
7. Data ilegal di-capture
C. Data tersimpan
1. Data disimpan secara berlebihan dalam banyak file dan/atau database
2. Item-item data sama memiliki nilai-nilai berbeda dalam file-file berbeda (integrasi data yang jelek)
3. Data tersimpan tidak akurat
4. Data tidak aman dari kecelakaan atau vandalisme
5. Data tidak diorganisasikan dengan baik
6. Data tidak fleksibel – tidak mudah untuk memenuhi kebutuhan informasi baru dari data tersimpan
7. Data tidak dapat diakses

ECONOMICS
A. Biaya
1. Biaya tidak diketahui
2. Biaya tidak dapat dilacak ke sumber
3. Biaya terlalu tinggi
B. Keuntungan
1. Pasar-pasar baru dapat dieksplorasi
2. Pemasaran saat ini dapat diperbaiki
3. Pesanan-pesanan dapat ditingkatkan

CONTROL (dan Keamanan)
A. Keamanan atau kontrol terlalu lemah
1. Input data tidak diedit dengan cukup
2. Kejahatan (misalnya, penggelapan atau pencurian) terhadap data
3. Etika dilanggar pada data atau informasi – mengacu pada data atau informasi yang mencapai orang-orang yang tidak mempunyai wewenang
4. Data disimpan secara berlebihan, tidak konsisten dalam file-file atau database-database yang berbeda
5. Peraturan atau panduan privasi data dilanggar (atau dapat dilanggar)
6. Error pemrosesan terjadi (oleh manusia, mesin, atau perangkat lunak)
7. Error pembuatan keputusan terjadi
B. Kontrol atau keamanan berlebihan
1. Red tape (prosedur) birokratis memperlambat sistem
2. Pengendalian menganggu para pelanggan atau karyawan
3. Pengendalian berlebihan menyebabkan penundaan pemrosesan

EFFICIENCY
A. Orang, mesin, atau komputer membuang waktu
1. Data secara berlebihan di-input atau disalin
2. Data secara berlebihan diproses
3. Informasi secara berlebihan dihasilkan
B. Orang, mesin, atau komputer membuang material dan persediaan
C. Usaha yang dibutuhkan untuk tugas-tugas terlalu berlebihan
D. Material yang dibutuhkan untuk tugas-tugas terlalu berlebihan

SERVICE
A. Sistem menghasilkan produk yang tidak akurat
B. Sistem menghasilkan produk yang tidak konsisten
C. Sistem menghasilkan produk yang tidak dapat dipercaya
D. Sistem tidak mudah dipelajari
E. Sistem tidak mudah digunakan
F. Sistem canggung untuk digunakan
G. Sistem tidak fleksibel pada situasi baru atau tidak umum
H. Sistem tidak fleksibel untuk berubah
I. Sistem tidak kompatibel dengan sistem-sistem lain

Rabu, 19 Agustus 2009

Metodologi Pengembangan Sistem FAST


Metodologi pengembangan sistem (system development methodology) adalah proses pengembangan sistem yang sangat formal dan akurat yang mendefinisikan sekumpulan aktivitas, metode, praktek-praktek terbaik, penyampaian, dan alat terotomasi yang digunakan oleh pengembang sistem dan manajer proyek untuk mengembangkan dan memelihara sistem dan software informasi.

Salah satu metodologi pengembangan sistem yang umum dipakai adalah metodologi FAST (Framework for the Application of Systems Technique).

Metodologi FAST terdiri dari fase-fase berikut:

1. Scope Definition (Definisi Lingkup)
Pada tahap ini dilakukan pengumpulan informasi yang akan diteliti tingkat feasibility dan ruang lingkup proyek yaitu dengan menggunakan kerangka PIECES (Performance, Information, Economics, Control, Efficiency, Service). Hal ini dilakukan untuk menemukan inti dari masalah-masalah yang ada (problems), kesempatan untuk meningkatkan kinerja organisasi (opportunity), dan kebutuhan-kebutuhan baru yang dibebankan oleh pihak manajemen atau pemerintah (directives).

2. Problem Analysis (Analisis Permasalahan)
Pada tahap ini akan diteliti masalah-masalah yang muncul pada sistem yang ada sebelumnya. Dalam hal ini project charter yang dihasilkan dari tahapan preliminary investigation adalah kunci utamanya. Hasil dari tahapan ini adalah peningkatan performa sistem yang akan memberikan keuntungan dari segi bisnis perusahaan. Hasil lain dari tahapan ini adalah sebuah laporan yang menerangkan tentang problems, causes, effects, dan solution benefits.

3. Requirements Analysis (Analisis Kebutuhan)
Pada tahap ini akan dilakukan pengurutan prioritas dari kebutuhan-kebutuhan bisnis yang ada. Tujuan dari tahapan ini adalah mengidentifikasi data, proses dan antarmuka yang diinginkan pengguna dari sistem yang baru.

4. Logical Design (Desain Logis)
Tujuan dari tahapan ini adalah mentransformasikan kebutuhan-kebutuhan bisnis dari fase requirements analysis kepada sistem model yang akan dibangun nantinya. Dengan kata lain pada fase ini akan menjawab pertanyaan-pertanyaan seputar penggunaan teknologi (data, process, interface) yang menjamin usability, reliability, completeness, performance, dan quality yang akan dibangun di dalam sistem.

5. Decision Analysis (Analisis Keputusan)
Pada tahap ini akan akan dipertimbangkan beberapa kandidat dari perangkat lunak dan keras yang nantinya akan dipilih dan dipakai dalam implementasi sistem sebagai solusi atas problems dan requirements yang sudah didefinisikan pada tahapan-tahapan sebelumnya.

6. Physical Design (Desain Logis)
Tujuan dari tahapan ini adalah mentransformasikan kebutuhan bisnis yang direpresentasikan sebagai logical design menjadi physical design yang nantinya akan dijadikan sebagai acuan dalam membuat sistem yang akan dikembangkan. Jika di dalam logical design tergantung kepada berbagai solusi teknis, maka physical design merepresentasikan solusi teknis yang lebih spesifik.

7. Construction and Testing
Setelah membuat physical design, maka akan dimulai untuk mengkonstruksi dan melakukan tahap uji coba terhadap sistem yang memenuhi kebutuhan-kebutuhan bisnis dan spesifikasi desain. Basis data, program aplikasi, dan antarmuka akan mulai dibangun pada tahap ini. Setelah dilakukan uji coba terhadap keseluruhan sistem, maka sistem siap untuk diimplementasikan.

8. Installation and Delivery
Pada tahap ini akan dioperasikan sistem yang telah dibangun. Tahapan ini akan dimulai dengan men-deploy software hingga memberikan pelatihan kepada user mengenai penggunaan sistem yang telah dibangun.