Minggu, 04 Maret 2012

earn money from internet !

Iseng-iseng gugling gimana caranya dapat $dolar$ dari internet, dan akhirnya nemu di salah satu post. Dimana kita dapat $dolar$ dengan cara "cuman ngebaca article", english siih .. tapi gak apa sekalian belajar english :D

Tiap 1 artikel dihargain $0.06, dan rata-rata tiap artikel yang masuk ke account 20 artikel. Kalo misalnya $0.06 x 20 artikel = $1.2, kalo tiap hari $1.2 x 30 hari = $36 di rupiah in lumayan dapet $36. Toh tiap 1 artikel bisa dihargain $0.08 ..

Btw, disini harus punya paypal, CCD or VC. Cuman yaa itu .. lumayan dapet duid $36 hanya baca artikel aja. Yaaa iseng-iseng berhadiah, daripada online cuman fb-an *pengalamaaan :p

Cek tkp -->
 readbud - get paid to read and rate articles
Readmore »

Minggu, 19 Juni 2011

Model Standar Pengembangan Profesi

Pada matakuliah Etikan dan Profesionalisme TSI kami akan menjelaskan Model Standar Pengembangan Profesi, diantaranya:
  • Jenis dan Deskripsi Profesi IT
  • ACM dan IEEE
Untuk lebih jelasnya, silahkan download disini.

Kelas 4KA03:
Chronika Sitanggang [11107914]
Mizana Chaerunnisa [11107094]
Nurita Safitri [11107267]
Ratih D. Denanda [11107377]
Readmore »

Sabtu, 04 Juni 2011

Prototype


Prototipe adalah pendekatan ke dasain sistem yang mengembangkan model kerja yang disederhanakan dari sistem. Prototipe, atau rancngan awal ini, dapat dengan cepat dan murah untuk dibangun dan diberikan pada para pemakai atau diuji.

Keuntungan dari penggunaan prototipe adalah:
  1. Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan oleh metode ‘spesifikasi tulisan’.
  2. User dapat mempertimbangkan sedikit perubahan selama masih bentuk prototipe.
  3. Memberikan hasil yang lebih akurat dari pada perkiraan sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah dapat diketahui dengan baik.
  4. User merasa puas. Pertama, user dapat mengenal melalui komputer. Dengan melakukan prototipe (dengan analisis yang sudah ada), user belajar mengenai komputer dan aplikasi yang akan dibuatkan untuknya. Kedua, user terlibat langsung dari awal dan memotivasi semangat untuk mendukung analisis selama proyek berlangsung.

Langkah-langkah pembuatan prototipe :
  1. Permintaan bermula dari kebutuhan user.
  2. Bangunlah sistem prototipe untuk menemukan kebutuhan awal yang diminta.
  3. Biarkan user menggunakan prototipe. Analis harus memberikan pelatihan, membantu dan duduk bersama-sama dengan user, khususnya untuk pertama kali. Anjurkan perubahan. User harus melihat fungsi-fungsi dan sifat dari prototipe, lihat bagaimana ia memecahkan masalah bisnis dan mengusulkan perbaikan.
  4. Implementasikan saran-saran perubahan.
  5. Ulangi langkah ketiga sampai user merasa puas.
  6. Merancang dan membangun suatu sistem akhir seperti sebelumnya.

Produk yang baik harus menyediakan 7 bagian, yaitu :
1. Pembuatan menu yang cepat dan mudah.
Pada menu harus terdapat sub menu, formulir, laporan, program protipe, dan menyediakan bantuan secara on-line untuk pemilihan menu dan prompt.

2. Pembuatan tampilan input dan output.
Anda harus dapat mewarnai bentuk tampilan dengan menempatkan kursor pada lokasi yang dituju (mouse merupakan alat yang terbaik untuk melakukannya), ketik nama field, spesifikasikan ketentuan untuk mengedit berdasarkan panjang field, menyertakan alfanumerik, jarak angka-angka yang diperbolehkan, kesalahan dan pesan-pesan bantuan, dan lain-lain.

3. Penyelarasan.
Anda dapat menjelaskan bentuk sebuah laporan yang dicetak dengan mudah. Bagian-bagian untuk merinci pembuatan laporan adalah judul, catatan kaki, field mana yang diletakkan (yang paling baik adalah jika program menampilkan semua field yang dikenal), header kolom, pengelompokkan, pengurutan, serta sub dan grand total. Pada umumnya seseorang harus dapat melaporkan item yang dipilih saja.

4. Software harus menghasilkan sebuah Data Dictionary secara otomatis.
Data Dictionary (DD) menyimpan informasi seperti layar, laporan atau formulir, tetapi yang paling penting DD menyimpan setiap informasi pada setiap field, termasuk panjang field, pengeditan dalam setiap laporan, dan format field yang digunakan.

DD adalah inti dari setiap produk dan sudah seharusnya setiap alat prototipe menggunakan DD untuk mengecek apakah fieldnya digunakan secara konsisten pada setiap tampilan, dan apakah dapat menyimpan pengetikan berulang jika field muncul lebih dari 1 kali.

5. Software harus dapat menyusun database sesuai harapan.
Ketentuan tampilan input, menjelaskan tentang peralatan daftar format. Software harus menyusun database dan selanjutnya mengijinkan user memasukkan data menggunakan formulir input. Produk-produk yang baik mengijinkan user untuk mengoptimalkan database dengan menentukan format dan kunci recordnya.

6. Mencari hasil dengan query on-line secara tepat ke data yang didaftar pada database.
Anda harus mampu melakukan pencarian dengan mudah, penyusunan, pemilihan dan menampilkan record.

7. Apakah yang dibutuhkan meliputi logika yang rumit atau perhitungan yang diperlukan prototipe ?
Walaupun tidak penting, program yang baik mempunyai bentuk struktur sederhana bahasa pemrograman untuk mengijinkan anda melakukan pemrosesan khusus, waktu kejadian, prosedur-prosedur otomatis, dan sebagainya.





Readmore »

Selasa, 17 Mei 2011

Teknik Estimasi pada Proyek Sistem Informasi

Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang estimasi yang pertama dilakukan selama fase definisi, yaitu ketika anda menulis rencana pendahuluan proyek. Hal ini perlu dilakukan, karena anda membutuhkan estimasi untuk proposal. Setelah fase analisis direncanakan ulang, anda harus memeriksa estimasi dan merubah rencana pendahuluan proyek menjadi rencana akhir proyek.
                                                             
Teknik – Teknik Estiminasi
Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu :
1. Keputusan Profesional
Katakanlah bahwa anda merupakan orang yang memiliki pengalaman yang luas dalam membuat program “report generation modules”. Anda melakukannya dengan pendekatan merancang report tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program tersebut. Setelah mempelajari rancangan program selama 5 menit, programmer lalu menutup matanya selama 5 menit (dia tidak tidur, tetapi berhitung), dan kemudian mengatakan “15 hari”. Inilah yang disebut Keputusan Profesional murni. Keuntungan dari teknik ini adalah cepat , dan jika seseorang sudah ahli dalam teknik ini, maka estimasinya pasti akan lebih akurat. Sedangkan kerugian dari teknik ini adalah bahwa anda membutuhkan seorang ahli yang berpengalaman dalam bidang ini, dan beberapa ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat.

2. Sejarah
Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus, yaitu anda harus mengerti tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. Anda dapat membandingkan tuagas yang akan diestimasik dengan tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar anda menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan.

3. Rumus-rumus
Ada beberapa rumus yang digunakan dalam software estimasi. Software yang baik untuk diketahui adalah COCOMO (Referensi 15). COCOMO dapat digunakan untuk memperkirakan biaya proyek, usaha (person months), jadwal, dan jumlah staf untuk masing-masing fase berikut ini :
Preliminary Design - our Analysis Phase
Detailed Design (DD) - our Design Phase
Code and Unit Tes (CUT) - same as ours
System Test - our System Test and Acceptance Phase

Ada 3 tipe penginputan dengan COCOMO
pertama, pemasukan biaya bulanan dari staf. Baik staf yang berkedudukan sebagai programer, analis, designer, test staff, administrasi dan technical writer. Gambar 13.1 menunjukkan sebuah layar penginputan yang digunakan untuk tipe ke dua dari penginputan. Faktor-faktor ini mencirikan level keseluruhan dari kelengkapan software yang ada, ukuran dan kemampuan dari komputer yang digunakan untuk pengembangan, kemampuan menampung dan pengalaman staf, dan juga pemrograman praktis serta alat-alat yang digunakan.
 
The factors are :
1 - Very Low 2 - Low 3 - Nominal 4 - High 5 - Very High
Gambar 13.1 Tampilan dengan menggunakan software COCOMO
Pada hal ini, Anda mungkin akan merasa bahwa COCOMO akan melakukan pendugaan yang baik, sejak software iniselalu tepat menentukan proyek yang lama. Tetapi, kesulitannya yaitu setiap akhir dari penggunaan software ini COCOMO selalu menanyakan nomor garis yang terdapat pada kode sumber (LOSC). Pada saat itu, Anda telah memiliki pengetahuan yang cukup mengenai sistem untuk memperkirakan LOSC dengan teliti, Anda tidak memerlukan beberapa rumus. Namun, Anda hanya memperkirakan keseluruhan proyek dengan teliti. Titik fungsi rumus-rumus. Pendekatan COCOMO dapat diperbaiki oleh produk-produk yang menghitung LOSC, yang diberikan fungsi-fungsi dari sebuah produk tersebut dan hasilnya dimasukkan ke dalam rumus-rumus COCOMO. Salah satu produknya adalah Before You Leap (BYL) oleh Gordon Group. Gambar 13.2 adalah tampilan dari BYL yang digunakan cepat untuk titik fungsi seperti bahasa yang digunakan. Hasil-hasil yang diberikan oleh BYL seperti keseluruhan dari COCOMO, kecuali hasil akhirnya akan ditampilkan dalam grafik-grafik, seperti pie chart atau diagram batang.
Gambar 13.2 BYL Function Point Analysis Screen
Harga produk yang lain tergantung pada perkiraan-perkiraan dari asosiasi komputer. CA – Estimasi memperbolehkan Anda untuk memberikan biaya, upaya, jadwal dan susunan staf di dalam COCOMO, tetapi beberapa penambahan disarankan atas permintaan hardware-nya (oriented IBM), rata-rata analisa keuangan, analisa resiko dan biaya pemeliharaan untuk single maupun keseluruhan proyek lingkungannya. CA- Estimasi dapat dimasukkan ke sistem pengembangan peralatan dan bentuk aslinya. Itu dapat diperkirakan untuk menarik pembelian dalam bentuk eceran atau bungkusan. Bentuk-bentuk dari faktor pemasukan ke dalam CA – Estimasi adalah terdaftar dalam gambar 13.3. Catatan dari ini lebih lengkap dan lebih berpengalaman dari pada COCOMO.

 
Gambar 13.3 Tabel dari input/output CA-Estimasi

Program Estimasi
Pendekatan satu rumus yang telah berhasil untuk fase estimasi perhitungan program adalah kemiripan sebuah pendekatan fungsi point. Dalam hal ini akan dijelaskan mengenai pemahaman bagaimana semua rumus itu bekerja. Jika Anda melakukan latihan untuk tingkat pemrograman, Anda akan lebih mengerti dari tingkat-tingkat yang lain. Pada dasarnya ada 2 faktor yang mempengaruhi lamanya waktu dari sebuah tugas , kerumitan dari tugas (C) dan produktivitas dari seseorang yang memperagakannya. Produktivitas dari seorang tergantung pada lamanya pengalaman seseorang (G) dalam bidang tersebut dan pengetahuan dari pekerjaan yang khusus(J). Rumus ini dapat digambarkan sebagai berikut :
D = C x ( G x J ) (Rumus 1)
Dimana :
D adalah lamanya waktu
C adalah faktor kompleksitas kesulitan
G adalah faktor pengalaman
J adalah faktor pengetahuan pekerjaan



Sumber:
iwayan.info/Lecture/PengelProySI_S1/BukuAjar/PPSI_BAB13.pdf
www.matabumi.com/cerita/cocomo

http://docs.google.com/viewer?a=v&q=cache:Zz8bM5aKeO8J:wsilfi.staff.gunadarma.ac.id/Downloads/files/20200/Pertemuan%2B10%2B-%2BEstimasi.pdf+%22teknik+estimasi%22&hl=id&gl=id&pid=bl&srcid=ADGEESgXOMQBNqGqaw4pLWuTIL9RYEbyM4bEr-Y6FrgDTCDb3csWteQ5W2Ed8AFPjLEPrFinLY46qQZP1ObpL8zhQlB7r1-TOlW-Vz_UJuMze-FRQVsxCvu43_dC0rjV2BJH5xvToK0S&sig=AHIEtbT8efZfAuTdlRa-JXGocptqE8DzWg&pli=1
Readmore »

Minggu, 10 April 2011

Fase dalam Pemrograman

Pemrograman adalah Rangkaian kegiatan atau perintah untuk dieksekusi oleh komputer. Program merupakan kumpulan instruction set yang akan dijalankan oleh pemroses, yaitu berupa software. Bagaimana sebuah sistem komputer berpikir diatur oleh program ini. Program inilah yang mengendalikan semua aktifitas yang ada pada pemroses. Program berisi konstruksi logika yang dibuat oleh manusia, dan sudah diterjemahkan ke dalam bahasa mesin sesuai dengan format yang ada pada instruction set.
Aktifitas pada fase ini adalah menulis program. Kejadian pentingnya adalah menguji program, rencana tes sistem, dan paling tidak mulai pada dokumentasi user.

Berikut langkah-langkah dalam pemrograman:
1.      Rencana Penggabungan (Plan The Integration)
2.      Mendisain Modul (Design The Module)
3.      Telusuri Disain Modul (Walk Through The Module Design)
4.      Rencana Bagaimana Menguji Modul (Plan How To Test The Module)
5.      Kode Setiap Modul (Code Each Module)
6.      Menguji Modul (Test The Module)
7.      Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)
8.      Menyimpan Semua Hasil Pengujian; Penggabungan Modul-Modul yang telah Diuji (Save The Results of All Tests; Submit Finished Module to Integration)
9.      Memulai Dokumentasi User (Get Started on The User Documentation)

Fase Pemrograman  
1. Rencana Penggabungan (Plan The Integration)
Merincikan beberapa metode untuk menggabungkan bagian-bagian tersebut dan harus merencanakan urutan penggabungannya agar program tersebut dapat digabungkan.

2. Mendisain Modul (Design The Module)
Programmer menerima beberapa tingkatan disain dari fase disain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah hingga mencapai keadaan siap untuk melakukan pemrograman, hal ini disebut sebagai disain modul.
Adapun pertimbangan lainnya:
·         Jika pemecahan modul yang dihasilkan adalah sangat penting yang memerlukan prioritas seperti adanya respon, user-friendly, atau konsistensi, perancang bisa melanjutkan ke tingkat yang lebih rendah.
·         Tingkat pemecahan dari disain dinyatakan dengan kontak.
·         Jika programmer tidak mengetahui pada waktu disain, pengetahuan programmer tingkat menengah dapat diasumsikan, dan disain dapat diambil alih oleh programmer tingkat menengah yang dapat mengatasinya.
Tetapi programmer tidak senang menerima disain yang terlalu rinci, yang programnya adalah menerjemahkan bahasa Inggris sederhana, seperti pernyataan secara harafiah ke dalam bahasa pemrograman.

3. Telusuri Disain Modul (Walk Through The Module Design)
Pada fase ini, dianjurkan untuk menelusuri disain dari masing-masing modul sebelum melakukan pengkodean. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.

4. Rencana Bagaimana Menguji Modul (Plan How to Test The Module)
Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan dan cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.

5. Kode Setiap Modul (Code Each Module)
Standar pengkodean akan ditetapkan pada saat disain sistem. Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :
    Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya tidak lebih dari 2 halaman.
    Satu entry, satu exit.
    Referensi secara keseluruhan sedikit.
    Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).

6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logic dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.
Modul seharusnya diuji dalam dua tahap, yaitu:
·         Tahap Pertama disebut pengujian “White Box”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.
·         Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.

7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels of Integration)
Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah “program stub” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.

8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-Modul yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)
Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program.
Pimpinan proyek biasanya menguasai atau mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang. Software seperti CMS (Code Management System) sangat berguna untuk menajemen konfigurasi – menjamin program tetap berjalan sesuai versinya dan mengubah ke source code.


9. Memulai Dokumentasi User (Get Started On The User Documentation)
Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya. Dokumen-dokumen berikut mungkin harus ditulis :
Tuntunan Pemakai (User’s Guide)
Dokumen ini dapat ditulis oleh programmer, penulis teknis atau bahkan user sendiri. Tampilkan kembali FS yang mempunyai bagian rinci mengenai menu, layar, form, dan user interface lainnya.
USER’S GUIDE yang baik adalah terbagi dalam bagian-bagian yang menunjukkan tingkatan user yang berbeda-beda. Sebagai contoh, dalam USER’S GUIDE sistem ABC, harus ada bagian yang disebut “Registrar’s Functions” atau “Warehouse Functions” atau lainnya. Materinya harus disesuaikan agar user dapat menggunakan secara normal. Hal ini membuat USER’S GUIDE berguna untuk mempelajari sistem.
Tuntunan Pemeliharaan (Maintenance Guide)
Bagaimana anda menemukan programmer untuk merinci dokumen dari program mereka untuk pemeliharaan berikutnya ? Kebanyakan Manajer proyek mengalami kesulitan dalam hal berikut : programmer enggan untuk melakukan dokumentasi sebelum program ditulis; dan beruntunglah menemukannya setelah semuanya selesai dikerjakan. Programmer berpikir bahwa pemeliharaan memerlukan penjelasan secara rinci dari logika pemrograman. Sangat membosankan untuk menulisnya dan sebenarnya tidak perlu. Berikut ini adalah solusi sederhana tentang hal tersebut : lebih baik merinci spesifikasi disain tingkat modul secara struktur, mendokumentasikan sendiri kode, dirasa cukup untuk pemeliharaan sistem.
MAINTENANCE GUIDE akan berisi spesifikasi disain, listing program dan penjelasan bagaimana semuanya disesuaikan, bagaimana mengubah pendekatan, dan bagaimana menghubungkan dan menguji semuanya.
Tuntunan Operator atau Tuntunan Manajer Sistem (Operator’s Guide or System Manager’s Guide)
Sama seperti USER’S GUIDE untuk orang-orang yang menghidupkan sistem di pagi hari, mematikannya, melakukan backup, menangani permasalahan utama, melakukan perhitungan, dsb. Dokumentasi yang disediakan oleh perusahaan hardware dan sistem operasi mungkin cukup – hanya prosedur untuk software tertentu yang harus ditulis ulang.
Dokumentasi Pelatihan (Training Documentation)
Jika anda akan memberikan kursus bagaimana menggunakan sistem, rencanakan apakah materi pelatihan akan diperlukan. USER’S GUIDE yang baik harusnya menambahkan hal ini. Anda mungkin harus membuat bantuan pelatihan, seperti transaparansi, buku latihan, pengujian, dan sebagainya.



Sumber: http://wsilfi.staff.gunadarma.ac.id/Downloads/files/20196/Pertemuan+09+-+Fase+Pemrograman.pdf
Readmore »