Kriteria Manager Proyek yang Baik

Manajer Proyek memegang peranan kritis dalam keberhasilan sebuah proyek terutama di bidang teknologi informasi. Setidaknya ada 3 (tiga) karakteristik yang dapat digunakan untuk mengukur tingkat kualifikasi seseorang untuk menjadi seorang Manajer Proyek yaitu:

1. Karakteristik Pribadi
Seperti :

• Memiliki pemahaman menyeluruh mengenai teknis pekerjaan dari proyek yang dikelolanya.
• 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.
• Memiliki pengalaman dan keahlian yang memadai dalam mengelola waktu dan manusia.

2. Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
Seperti :

• Memiliki komitmen yang kuat dalam meraih tujuan dan keberhasilan proyek dalam jadwal, anggaran dan prosedur yang dibuat.
• Pelaksanakan seluruh proses pengembangan proyek IT sesuai dengan anggaran dan waktu yang dapat memuaskan para pengguna/klien.
• Pernah terlibat dalam proyek yang sejenis.
• Mampu mengendalikan hasil-hasil proyek dengan melakukan pengukuran dan evaluasi kinerja yang disesuaikan dengan standar dan tujuan yang ingin dicapai dari proyek yang dilaksanakan.
• Membuat dan melakukan rencana darurat untuk mengantisipasi hal-hal maupun masalah tak terduga.
• Membuat dan menerapkan keputusan terkait dengan perencanaan.
• Memiliki kemauan untuk mendefinisikan ulang tujuan, tanggung jawab dan jadwal selama hal tersebut ditujukan untuk mengembalikan arah tujuan dari pelaksanaan proyek jika terjadi jadwal maupun anggaran yang meleset.
• Membangun dan menyesuaikan kegiatan dengan prioritas yang ada serta tenggat waktu yang ditentukan sebelumnya.
• Memiliki kematangan yang tinggi dalam perencanaan yang baik dalam upaya mengurangi tekanan dan stres sehingga dapat meningkatkan produktifitas kerja tim.
• Mampu membuat perencanaan dalam jangka panjang dan jangka pendek.

3. Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin
Seperti :

• Memiliki kemampuan dan keahlian berkomunikasi serta manajerial.
• Mampu menyusun rencana, mengorganisasi, memimpin, memotivasi serta mendelegasikan tugas secara bertanggung jawab kepada setiap anggota tim.
• Menghormati para anggota tim kerjanya serta mendapat kepercayaan dan penghormatan dari mereka.
• Berbagi sukses dengan seluruh anggota tim.
• Mampu menempatkan orang yang tepat di posisi yang sesuai.
• Memberikan apresiasi yang baik kepada para anggota tim yang bekerja dengan baik.
• Mampu mempengaruhi pihak-pihak lain yang terkait dengan proyek yang dipimpinnya untuk menerima pendapat-pendapatnya serta melaksanakan rencana-rencana yang disusunnya.
• Mendelegasikan tugas-tugas namun tetap melakukan pengendalian melekat.
• Memiliki kepercayaan yang tinggi kepada para profesional terlatih untuk menerima pekerjaan-pekerjaan yang didelegasikan darinya.
• Menjadikan dirinya sebagai bagian yang terintegrasi dengan tim yang dipimpinnya.
• Mampu membangun kedisiplinan secara struktural.
• Mampu mengidentifikasi kelebihan-kelebihan dari masing-masing anggota tim serta memanfaatkannya sebagai kekuatan individual.
• Mendayagunakan setiap elemen pekerjaan untuk menstimulasi rasa hormat dari para personil yang terlibat dan mengembangkan sisi profesionalisme mereka.
• Menyediakan sedikit waktu untuk menerima setiap ide yang dapat meningkatkan kematangan serta pengembangan dirinya.
• Selalu terbuka atas hal-hal yang mendorong kemajuan.
• Memahami secara menyeluruh para anggota tim yang dipimpinnya dan mengembangkan komunikasi efektif di dalamnya.

reffrensi :
1. http://saiiamilla.wordpress.com/2011/05/13/kriteria-manager-proyek-yang-baik/
2. http://macuy-marucuy.blogspot.com/2011/05/kriteria-manager-proyek-yang-baik_18.html
3. http://www.setiabudi.name/archives/990

Pembahasan COCOMO (Constructive Cost Model)

A. Pengertian COCOMO

COCOMO (Constructive Cost Model) merupakan model algoritma estimasi biaya perangkat lunak yang dikembangkan dan diterbitkan oleh Barry Boehm. COCOMO adalah sebuah model untuk memperkirakan usaha, biaya dan jadwal untuk proyek-proyek perangkat lunak. Model ini menggunakan rumus regresi dasar dengan parameter yang berasal dari data historis proyek dan karakteristik proyek saat ini.

B. Sejarah Singkat COCOMO

COCOMO pertama kali diterbitkan pada tahun 1981, Barry W. Boehm’s Book Software Engineering Economics sebagai model untuk memperkirakan usaha, biaya, dan jadwal untuk proyek-proyek perangkat lunak. Pada tahun itu juga diadakan studi 63 proyek di TRW Aerospace yang mana Barry Boehm sebagai direktur riset perangkat lunak dan teknologi. Penellitian ini memeriksa proyek-proyek mulai dari ukuran 2000 sampai 100.000 baris kode, dan bahasa pemrograman mulai dari bahasa rakitan sampai PL/I. Proyek-proyek ini didasarkan pada model pengembangan perangkat lunak waterfall yang merupakan proses pembangunan software di tahun 1981. Referensi untuk model ini biasa disebut COCOMO 81.

Pada tahun 1997, COCOMO II telah dikembangkan dan akhirnya diterbitkan pada tahun 2000 dalam buku Software Cost Estimation with COCOMO II. COCOMO II adalah pengembangan dari COCOMO 81 dan lebih cocok untuk mengestimasi proyek pengembangan perangkat lunak modern, dan basis data proyek yang telah diperbaharui.

C. Jenis-jenis COCOMO

COCOMO terdiri dari tiga bentuk hirarki yang tingkatannya semakin rinci dan akurat. Tingkat pertama, Basic COCOMO baik untuk order awal dan estimasi kasar besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya faktor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Tingkatan yang kedua adalah Intermediate COCOMO yang mengambil Cost Drivers untuk diperhitungkan. Terakhir Detailed COCOMO, catatan tambahan untuk pengaruh fase proyek individu.

1. Basic (COCOMO I 1981)

Menghitung dari estimasi jumlah LOC (Lines of Code). Pengenalan Cocomo ini diawali tahun 70-an akhir. Sang pelopor Boehm, melakukan riset dengan mengambil kasus dari 63 proyek perangkat lunak untuk membuat model matematisnya. Model dasar dari model ini adalah sebuah persamaan sebagai berikut :

[ Effort = (C * size)^M ]

keterangan :

Effort : adalah usaha yang dibutuhkan selama proyek, diukur dalam person-months;

C dan M : adalah konstanta-konstanta yang dihasilkan dalam riset Boehm dan tergantung pada penggolongan besarnya proyek perangkat lunak;

size : adalah estimasi jumlah baris kode yang dibutuhkan untuk implementasi, dalam satuan KLOC (kilo lines of code)

Ukuran program dinyatakan dalam KLOC. Model Cocomo dapat diaplikasikan dalam tiga tingakatan kelas yaitu :

• Proyek Organic (Organic Mode) adalah proyek dengan ukuran relatif kecil, dengan anggota team yang sudah berpengalaman dan mampu bekerja pada permintaan yang relatif fleksibel.
• Proyek Sedang (Semi-Detached Mode) merupakan proyek yang memiliki ukuran dan tingkat kerumitan yang sedang, dan tiap anggota tim memiliki tingkat keahlian yang berbeda.
• Proyek Terintegrasi (Embedded Mode), Proyek yang dibangun denga spesifikasi dan operasi yang ketat.

Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini:

keterangan :

• E : besarnya usaha (orang-bulan)
• D : lama waktu pengerjaan (bulan)
• KLOC : estimasi jumlah baris kode (ribuan)
• P : jumlah orang yang diperlukan.

2. COCOMO Menengah (Intermediet COCOMO)

Intermediate COCOMO menghitung usaha pengembangan perangkat lunak sebagai fungsi ukuran program dan sekumpulan “cost drivers” yang mencakup penilaian subjektif produk, perangkat keras, personil dan atribut proyek. Ekstensi ini mempertimbangkan satu set empat “cost drivers”, masing-masing dengan sejumlah atribut anak:

• Atribut produk (product attributes)

o Perangkat lunak yang disyaratkan reliabilitas (RELY)

o Ukuran database aplikasi (DATA)

o Kompleksitas produk (CPLX)

• Hardware atribut (computer attibutes)

o Run-time kinerja kendala (TIME)

o Memori kendala (STOR)

o Volatilitas lingkungan mesin virtual (VIRT)

o Diperlukan waktu pembalikan haluan (TURN)

• Personil atribut (personnel attributes)

o Analis kemampuan (ACAP)

o Kemampuan rekayasa perangkat lunak (PCAP)

o Aplikasi pengalaman (AEXP)

o Mesin virtual pengalaman (VEXP)

o Bahasa pemrograman pengalaman (LEXP)

• Proyek atribut

o Penggunaan perangkat lunak (MODP)

o Penerapan metode rekayasa perangkat lunak (TOOL)

o Diperlukan jadwal pengembangan (SCED)

3. COCOMO Detil (Detailed COCOMO)

Detil COCOMO menggabungkan semua karakteristik versi intermediate dengan penilaian dampak cost driver di setiap langkah (analisis, desain, dll) dari proses rekayasa perangkat lunak 1. model rinci kegunaan yang berbeda upaya pengali untuk setiap driver biaya atribut tersebut Sensitif pengganda Tahap upaya masing-masing untuk menentukan jumlah usaha yang dibutuhkan untuk menyelesaikan setiap tahap. Pada COCOMO detail, upaya dihitung sebagai fungsi dari ukuran program dan satu set driver biaya yang diberikan sesuai dengan tiap tahap siklus hidup rekayasa perangkat lunak.

Sumber :

http://en.wikipedia.org/wiki/COCOMO

http://jigokushoujoblog.wordpress.com/2011/04/13/cocomo-constructive-cost-model/

Keuntungan dan kerugian software OpenSource

A. Keuntungan

1. Banyak tenaga yang terlibat

Kegiatan Open Source biasanya melibatkan banyak orang. Memobilitas banyak orang dengan biaya rendah (bahkan gratis) merupakan salah satu kelebihan open source. Kasus Linux, programmer yang terlibat dalam pengembangan Linux mencapai ribuan orang. Bayangkan jika mereka harus digaji sebagaimana layaknya programmer yang bekerja di perusahaan yang khusus mengembangkan software untuk dijual. Kumpulan skill ini memiliki nilai yang berlipat-lipat tidak sekedar penambahan saja.
Untuk menentukan kesalahan (bugs) dalam software diperlukan usaha yang luar biasa, menentukan sumber kesalahan ini merupakan salah satu hal yang tersulit dan mahal. Dengan opensource Kegiatan debugging dapat dilakukan secara paralel. meskipun koding masih merupakan aktivitas yang sendiri-sendiri (solitary), akan tetapi nilai tambah yang lebih besar datang dari pemikiran banyak programmer atau komunitas.

2. Peningkatan Kualitas
Adanya peer review meningkatkan kualitas, reliabilitas, menurunkan biaya dan meningkatkan pilihan (choice). adanya banyak pilihan dari beberapa programmer membuat pilihan jatuh kepada implementasi yang lebih baik. Contoh nyata dari hal ini adalah web server Apache yang mendominasi pasar server web.

3. Menjamin Masa Depan Software
Konsep open source menjamin masa depan (future) dari software. Dalam konsep closed-source, software sangat bergantung kepada programmer atau perusahaan. Bagaimana jika programmer tersebut bekerja atau pindah ke perusahaan lain? hal ini tentunya akan merepotkan perusahaan pembuat software tersebut. Di sisi pembeli juga ada masalah, bagaimana jika perusahaan tersebut gulung tikar? Nilai closed-source software akan cenderung menjadi nol jika perusahaan tersebut bangkrut. Dengan kata lain, “the price a consumer will pay” dibatasi oleh “expected future value of vendor service”. Open source tidak memiliki masalah tersebut.


B. Kerugian

1. Support Berbayar dan Langka
Satu keyakinan bahwa software open source tidak akan ada masalah adalah keliru, hal ini merupakan sebuah bencana jika program opensource sudah digunakan untuk semua infrastruktur yang besar, dan ketika software menemui hole atau bug yang tidak ada yang paham. Maka langkah yang mungkin ditempuh adalah : searching problem solving di forum-forum, tanya sana sini. Jika tidak ketemu juga, kita bisa-bisa harus menganggarkan dana yang tidak sedikit untuk mendatangkan jasa konsultan dari pakar opensource tersebut.
Karena sebenarnya opensource adalah sebuah model bisnis yang berbeda dari software berbayar di awal dan dibatasi sebuah aturan lisensi. Mungkin untuk skala kecil, tidak akan merasakan impack yang diakibatkan. Namun jika sudah melibatkan sistem yang sudah ada, data-data penting, kadang-kadang manajemen biasanya tidak akan ambil pusing, mending mencari yang berbayar sedikit mahal diawal, tetapi ada jaminan support dan problem solving yang akuntabel dari vendor. Daripada mengorbankan data-data dan infrastruktur yang sudah terinstall hanya karena berorientasi penghematan dana di awal.

2. Versi Betha, Stabil dan unstabil.
Open source sangat erat kaitannya dengan versi dan kestabilan kualitas softwarenya. Hal ini merupakan celah besar yang ditinggalkan baik disengaja ataupun tidak disengaja. Kepastian stabil dan tidak stabil kadang menjadi keraguan pilihan para petinggi IT untuk memilih software opensource.
Bayangkan saja, versi software opensource yang terinstall di server statusnya masih unstable, bisa dibayangkan bila terjadi apa-apa dan patch-nya harus menunggu orang yang sukarela untuk memperbaiki masalah yang terjadi tersebut.

Sumber :
http://rijaljuarez.blogspot.com/2010/05/kekurangan-dan-kelebihan-open-source.html

Middleware TeLematika

Middleware (Pengantar Telematika)

Beberapa Pendekatan Pengembangan Sistem :

Pendekatan Berkembang (evolutionary approach)

Pendekatan yang menerapkan teknologi canggih hanya untuk aplikasi-aplikasi yang memerlukan saja dan terus dikembangkan untuk periode berikutnya mengikuti kebutuhan dan teknologi yang ada.

Pendekatan Moduler (modular approach)

Pendekatan dengan memecah sistem komplek menjadi modul yang sederhana, sehingga sistem lebih mudah dipahami dan dikembangkan, tepat waktu, mudah dipelihara (ciri terstruktur)

Pendekatan Sistem (systems approach)

Memperhatikan sistem informasi sebagai satu kesatuan terintegrasi untuk masing-masing kegiatan/aplikasinya dan menekankan sasaran organisasi secara global.

Pendekatan Klasik (classical approach)

disebut juga dengan Pendekatan Tradisional (traditional approach) atau Pendekatan Konvensional (conventional approach). Metodologi Pendekatan Klasik mengembangkan sistem dengan mengikuti tahapan-tahapan pada System Life Cycle. Pendekatan ini menekankan bahwa pengembangan akan berhasil bila mengikuti tahapan pada System Life Cycle.

Lompatan jauh (great loop approach)

Pendekatan yang menerapkan perubahan menyeluruh secara serentak menggunakan teknologi canggih, sehingga mengandung resiko tinggi, terlalu mahal, sulit dikembangkan karena terlalu komplek.