Rabu, 23 Juli 2014

Kriteria Manajer Proyek yang Baik

Yang dimaksud dengan manager adalah orang atau seseorang yang harus mampu membuat orang-orang dalam organisasi yang berbagai karakteristik, latar belakang budaya, akan tetapi memiliki ciri yang sesuai dengan tujuan (goals) dan teknologi (technology).

Dan tugas seorang manager adalah bagaimana mengintegrasikan berbagai macam variabel (karakteristik, budaya, pendidikan dan lain sebagainya) kedalam suatu tujuan organisasi yang sama dengan cara melakukan mekanisme penyesuaian.

Adapun mekanisme yang diperlukan untuk menyatukan variabel diatas adalah sebagai berikut:

Pengarahan (direction) yang mencakup pembuatan keputusan, kebijaksanaan, supervisi, dan lain-lain.
  • Rancangan organisasi dan pekerjaan.
  • Seleksi, pelatihan, penilaian, dan pengembangan.
  • Sistem komunikasi dan pengendalian.
  • Sistem reward.
Hal tersebut memang tidak mengherankan karena posisi Manajer Proyek memegang peranan kritis dalam keberhasilan sebuah proyek terutama di bidang teknologi informasi. Berikut ini kualifikasi teknis maupun nonteknis yang harus dipenuhi seorang Manajer Proyek yang saya sarikan dari IT Project Management Handbook.

Setidaknya ada 3 (tiga) karakteristik yang dapat digunakan untuk mengukur tingkat kualifikasi seseorang untuk menjadi Manajer Proyek yaitu:

  • Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
  • Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin
  • Karakter Pribadinya

Memiliki pemahaman yang menyeluruh mengenai teknis pekerjaan dari proyek yang dikelola olehnya.
Mampu bertindak sebagai seorang pengambil keputusan yang handal dan bertanggung jawab.
Memiliki integritas diri yang baik namun tetap mampu menghadirkan suasana yang mendukung di lingkungan tempat dia bekerja.

  • Asertif
  • Memiliki pengalaman dan keahlian yang memadai dalam mengelola waktu dan manusia.
  • Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola

http://saiiamilla.wordpress.com/2011/05/13/kriteria-manager-proyek-yang-baik/

Pengertian Cocomo dan Jenis - Jenisnya

COCOMO (Constructive Cost Model )

Constructive Cost Model (COCOMO) Merupakan algoritma estimasi biaya perangkat lunak model yang dikembangkan oleh Barry Boehm. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasal dari data historis dan karakteristik proyek proyek saat ini.

Sejarah Singkat COCOMO
COCOMO pertama kali diterbitkan pada tahun 1981 Barry Boehm W. ’s Book ekonomi Software engineering sebagai model untuk memperkirakan usaha, biaya, dan jadwal untuk proyek-proyek perangkat lunak. Ini menarik pada studi dari 63 proyek di TRW Aerospace mana Barry Boehm adalah Direktur Riset dan Teknologi Perangkat Lunak pada tahun 1981. Penelitian ini memeriksa proyek-proyek ukuran mulai dari 2.000 sampai 100.000 baris kode, dan bahasa pemrograman mulai dari perakitan untuk PL / I. Proyek-proyek ini didasarkan pada model pengembangan perangkat lunak waterfall yang merupakan proses software umum pembangunan di 1981.

Referensi untuk model ini biasanya menyebutnya COCOMO 81. Pada tahun 1997 COCOMO II telah dikembangkan dan akhirnya diterbitkan pada tahun 2000 dalam buku Estimasi Biaya COCOMO II Software dengan COCOMO II. adalah penerus dari COCOMO 81 dan lebih cocok untuk mengestimasi proyek pengembangan perangkat lunak modern. Hal ini memberikan lebih banyak dukungan untuk proses pengembangan perangkat lunak modern, dan basis data proyek diperbarui. Kebutuhan model baru datang sebagai perangkat lunak teknologi pengembangan pindah dari batch processing mainframe dan malam untuk pengembangan desktop, usabilitas kode dan penggunaan komponen software off-the-rak. Artikel ini merujuk pada COCOMO 81.

Pengertian COCOMO
COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasar estimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya faktor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rincian tambahan COCOMO account untuk pengaruh fase proyek individu.

Model Jenis COCOMO 
1. Dasar Cocomo
Dengan menggunakan estimasi parameter persamaan (dibedakan menurut tipe sistem yang berbeda) upaya pengembangan dan pembangunan durasi dihitung berdasarkan perkiraan DSI.

Dengan rincian untuk fase ini diwujudkan dalam persentase. Dalam hubungan ini dibedakan menurut tipe sistem (organik-batch, sebagian bersambung-on-line, embedded-real-time) dan ukuran proyek (kecil, menengah, sedang, besar, sangat besar).

2. Intermediate Cocomo
Persamaan estimasi sekarang mempertimbangkan (terlepas dari DSI) 15 pengaruh faktor-faktor; ini adalah atribut produk (seperti kehandalan perangkat lunak, ukuran database, kompleksitas), komputer atribut-atribut (seperti pembatasan waktu komputasi, pembatasan memori utama), personil atribut ( seperti aplikasi pemrograman dan pengalaman, pengetahuan tentang bahasa pemrograman), dan proyek atribut (seperti lingkungan pengembangan perangkat lunak, tekanan waktu pengembangan). Tingkat pengaruh yang dapat diklasifikasikan sebagai sangat rendah, rendah, normal, tinggi, sangat tinggi, ekstra tinggi; para pengganda dapat dibaca dari tabel yang tersedia.

3. Detil Cocomo
Dalam hal ini adalah rincian untuk fase tidak diwujudkan dalam persentase, tetapi dengan cara faktor-faktor pengaruh dialokasikan untuk fase. Pada saat yang sama, maka dibedakan menurut tiga tingkatan hirarki produk (modul, subsistem, sistem), produk yang berhubungan dengan faktor-faktor pengaruh sekarang dipertimbangkan dalam persamaan estimasi yang sesuai. Selain itu detail cocomo dapat menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengendali biaya pada setiap langkah (analisis, perancangan, dll) dari proses rekayasa PL

http://inarjutex.wordpress.com/2011/05/28/pengertian-cocomo-dan-jenisnya/
http://wartawarga.gunadarma.ac.id/2011/04/cocomo/

Kenapa anda dianjurkan menggunakan software open source dalam membuat aplikasi ? apa Keuntungan dan Kerugiannya ?

Open source adalah sistem pengembangan yang tidak dikoordinasi oleh suatu individu / lembaga pusat, tetapi oleh para pelaku yang bekerja sama dengan memanfaatkan kode sumber (source-code) yang tersebar dan tersedia bebas (biasanya menggunakan fasilitas komunikasi internet). Pola pengembangan ini mengambil model ala bazaar, sehingga pola Open Source ini memiliki ciri bagi komunitasnya yaitu adanya dorongan yang bersumber dari budaya memberi, yang artinya ketika suatu komunitas menggunakan sebuah program Open Source dan telah menerima sebuah manfaat kemudian akan termotivasi untuk menimbulkan sebuah pertanyaan apa yang bisa pengguna berikan balik kepada orang banyak.

Pola Open Source lahir karena kebebasan berkarya, tanpa intervensi berpikir dan mengungkapkan apa yang diinginkan dengan menggunakan pengetahuan dan produk yang cocok. Kebebasan menjadi pertimbangan utama ketika dilepas ke publik. Komunitas yang lain mendapat kebebasan untuk belajar, mengutak-ngatik, merevisi ulang, membenarkan ataupun bahkan menyalahkan, tetapi kebebasan ini juga datang bersama dengan tanggung jawab, bukan bebas tanpa tanggung jawab.

Pembuatan aplikasi dengan software opensource sangat dianjurkan dikarenakan kita dapat menshare source codenya sehingga orang lain bebas untuk mengembangkan source kode tersebut.. Dan hal yang paling penting software yang kita gunakan untuk membuat aplikasi didapatkan secara gratis. Sehingga setiap orang dapat mencoba untuk mengembangkan source kode yang sudah kita buat.

Untuk akses yang digunakan untuk mendapatkan software opensource sangatlah mudah. Media utama yang digunakan adalah internet. Internet untuk saat ini sudah tersebar luas hingga ke plosok. Sehingga para programer yang berada di plosok pun dapat mendapatkan source kode dan softwarenya dengan sangat mudah. Namun dari semua kelebihan yang sudah saya sebutkan diatas tentu masih ada kekurangan yang dimiliki untuk pembuatan aplikasi dengan software open source. Dibawah ini saya jelaskan lebih detail mengeanai aplikasi open source.

Keuntungan Software Open Source

1. Ketersedian source code dan hak untuk memodifikasi
Ini merupakan hal yang penting. Hal ini menyebakan perubahan dan improvisasi pada produk software. Selain itu, hal ini memunculkan kemungkinan untuk meletakan code pada hardware baru, agar dapat diadaptasi pada situasi yang berubah-ubah, dan menjangkau pemahaman bagimana sistem itu bekerja secara detail.

2. Hak untuk mendistribusikan modifikasi dan perbaikan pada code
Hal ini merupakan titik perbedaan Open Source Software dengan Free Software. Pada kenyataannya, hak pendistribusian diakui dan merupakan hal yang umum, ini adalah hal yang berpengaruh bagi sekumpulan developer ( pengembang ) untuk bekerja bersama dalam project Open Source Software.

3. Hak untuk menggunakan software
Ini merupakan kombinasi dari hak pendistribusian, menjamin ( jika software cukup berguna ) beberapa user yang mana membantu dalam menciptakan pasar untuk mendukung dan berlangganan software. Hal ini juga membantu dalam improvisasi kualitas dari produk dan improvisasi secara fungsi. Selain itu akan menyebabkan sejumlah user untuk mencoba produk dan mungkin menggunakannya secara reguler.

Kerugian Software Open Source.

1. Tidak ada garansi dari pengembangan
Biasanya terjadi ketika sebuah project dimulai tanpa dukungan yang kuat dari satu atau beberapa perusahaan, memunculkan celah awal ketika sumber code masih mentah dan pengembangan dasar masih dalam pembangunan.

2. Masalah yang berhubungan dengan intelektual property
Pada saat ini, beberapa negara menerima software dan algoritma yang dipatentkan. Hal ini sangat sulit untuk diketahui jika beberapa motede utama untuk menyelesaikan masalah software di patenkan sehingga beberapa komunitas dapat dianggap bersalah dalam pelanggaran intelektual property.

3. Kesulitan dalam mengetahui status project
Tidak banyak iklan bagi open source software, biasanya beberapa project secara tidak langsung ditangani oleh perusahaan yang mampu berinvestasi dan melakukan marketing.


http://alvinjunizar.blogspot.com/2013/04/kenapa-anda-dianjurkan-menggunakan.html

Jumat, 17 Januari 2014

Analisis Kinerja Sistem ( POSTEST KENDALI DAN AUDIT SI )

Pengendalian TI didefinisikan sebagai suatu pernyataan hasil yang diinginkan atau maksud yang dicapai oleh prosedur pengendalian implementasi dalam kegiatan TI khusus. 
Terdapat 15 area pengendalian, sebut dan jelaskan.

Area Pengendalian ada 15 yaitu :
  1. Integritas Sistem
  2. Manajemen Sumber Daya (Perencanaan Kapasitas)
  3. Pengendalian Perubahan S/W Aplikasi dan S/W sistem
  4. Backup dan Recovery
  5. Contigency Planning
  6. System S/W Support
  7. Dokumentasi
  8. Pelatihan atau Training
  9. Administrasi
  10. Pengendalian Lingkungan dan Keamanan Fisik
  11. Operasi
  12. Telekomunikasi
  13. Program Libraries
  14. Application Support (SDLC)
  15. Pengendalian Mikrokomputer
Berikut ini adalah penjelasan masing-masing area pengendalian :
Integritas Sistem
  • Ketersediaan dan kesinambungan sistem komputer untuk user.
  • Kelengkapan, Keakuratan, Otorisasi, serta proses yang auditable.
  • Persetujuan dari user atas kinerja sistem yang di inginkan.
Manajemen Sumber Daya
  • Faktor-faktor yang melengkapi integritas sistem.
  • Yaitu meyakini kelangsungan (ongoing) H/W, S/W, SO, S/W aplikasi, dan komunikasi jaringan komputer.
Pengendalian Perubahan S/W Aplikasi dan S/W sistem
  • Menentukan adanya keterlibatan dan persetujuan user dalam hal adanya perubahan terhadap s/w aplikasi dan s/w sistem.
  • Setiap pengembangan dan perbaikan aplikasi harus melalui proses formal dan didokumentasikan serta telah melalui tahapan-tahapan pengembangan sistem yang dibakukan dan disetujui.
Backup dan Recovery
  • Demi kelangsungan usaha, harus tersedia data processing disaster recovery planning (rencana pemulihan data dan pusat sistem informasi apabila terjadi kehancuran),
  • Baik berupa backup dan pemulihan normal, maupun rencana contingency untuk kerusakan pusat SI (lokasi gedung, peralatanya, SDM-nya maupun manualnya).
Contigency Planning
  • Perencanaan yang komprehenshif di dalam mengantisipasi terjadinya ancaman terhadap fasilitas pemrosesan SI.
  • Dimana sebagian besar komponen utama dari disaster recovery plan telah dirumuskan dengan jelas, telah di koordinasikan dan disetujui, seperti critical application systems, identifikasi peralatan dan fasilitas penunjang H/W, sistem S/W dan sebagainya.
System S/W Support
  • Pengukuran pengendalian dalam pengembangan, penggunaan, dan pemeliharaan dari S/W SO, biasanya lebih canggih dan lebih cepat perputarannya dibandingkan dengan S/W aplikasiDengan ketergantungan yang lebih besar kepada staf teknik untuk integritas fungsionalnya.
  • Pengukuran kendali pengamanan aplikasi individu maupun pengamanan logika sistem secara menyeluruh (systemwide logical security).
Dokumentasi
  • Integritas dan ketersediaan dokumen operasi, pengembangan aplikasi, user dan S/W sistem.
  • Diantaranya dokumentasi program dan sistem, buku pedoman operasi dan schedule operasi.
  • Untuk setiap aplikasi sebaiknya tersedia dokumentasi untuk tiap jenjang user.
Pelatihan atau Training
  • Adanya penjenjagan berdasarkan kemampuan untuk seluruh lapisan manajemen dan staf, dalam hal penguasaannya atas aplikasi-aplikasi dan kemampuan teknisnya.
  • Serta rencana pelatihan yang berkesinambungan.
Administrasi
  • Struktur organisasi dan bagannya, rencana strategis, tanggungjawab fungsional, job description, sejalan dengan metoda job accounting dan/atau charge out yang digunakan.
  • Termasuk didalamnya pengukuran atas proses pengadaan dan persetujuan untuk semua sumber daya SI.
Pengendalian Lingkungan dan Keamanan Fisik
  • Listrik, peyejuk udara, penerang ruangan, pengaturan kelembaban, serta kendali akses ke sumber daya informasi.
  • Pencegahan kebakaran, ketersediaan sumber listrik cadangan.
  • Juga pengendalian dan backup sarana telekomunikasi.
Operasi
  • Diprogram untuk merespon permintaan/keperluan SO.
  • Review atas kelompok SO berdasarkan job schedulling, review yang terus-menerus terhadap operator, retensi terhadap console log message, dokumentasi untuk run/restore/backup atas seluruh aplikasi.
  • Daftar personel, dan nomor telepon yang harus dihubungi jika muncul masalah SO, penerapan sistem sift dan rotasi serta pengambilan cuti untuk setiap operator.
Telekomunikasi
  • Review terhadap logical and physical access controls.
  • Metodologi pengacakan (encryption) terhadap aplikasi electronic data interchange (EDI).
  • Adanya supervisi yang berkesinambungan terhadap jaringan komputer dan komitmen untuk ketersediaan jaringan tersebut dan juga redundansi saluran telekomunikasi.
Program Libraries
  • Terdapat pemisahan dan prosedur pengendalian formal untuk application source code dan compiled production program code dengan yang disimpan di application test libraries development.
  • Terdapat review atas prosedur quality assurance.
Application Support
  • Bahwa proses tetap dapat berlangsung walaupun terjadi kegagalan sistem.
  • Sejalan dengan kesinambungan proses untuk inisiasi sistem baru, manajemen proyek, proses pengujian yang menyeluruh antara user dan staf SI.
  • Adanya review baik formal maupun informal terhadap tingkat kepuasan atas SDLC yang digunakan.
Microcomputer Controls
  • Pembatasan yang ketat dalam pengadaan, pengembangan aplikasi, dokumentasi atas aplikasi produksi maupun aplikasi dengan misi yang kritis, sekuriti logika, dan fisik terhadap microcomputer yang dimiliki.
  • Serta pembuatan daftar inventaris atas H/W, S/W, serta legalitas dari S/W untuk menghindari tuntutan pelanggaran hak cipta.
http://nurulaisyah2.wordpress.com/


Analisis Kinerja Sistem ( PRETEST KENDALI DAN AUDIT SI )

Pengendalian internal telah mengalami perubahan dari konsep 'ketersediaan pengendalian' ke konsep 'proses pencapaian tujuan'.
Apakah maksud dari konsep 'Proses Pencapaian Tujuan' tersebut?

Konsep Proses Pencapaian Tujuan adalah sebuah proses yang sudah dikembangkan oleh pihak IT yang ditugaskan kepada pihak pimpinan untuk mengambil tindakan dan semakin mendekatkan diri dengan konsumen untuk bisa mengerti tentang keadaan pasar.

Konsep ini tidak sepenuhnya dikerjakan oleh pimpinan, namun beberapa diantaranya dikerjakan oleh organisasi dan digerakkan sesuai dengan keahlian para pekerjanya masing - masing.

Untuk menjaga keseimbangan setiap pekerjaan, dibutuhkan seorang manager untuk mengawasi dan menjaga keseimbangan tersebut, manager berperan sebagai 'konduktur' dalam setiap organisasi.

Seorang manager tidak harus menguasai setiap bidang yang dimiliki oleh para pekerjanya, ia hanya harus mampu untuk mengendalikan setiap situasi yang ada pada pekerjaan yang dikerjakan oleh para karyawannya, seperti misalnya mengatur tempo dan mengendalikan keadaan.