KRITERIA MANAGER YANG BAIK

Kriteria Manager yang Baik

DEFINISI MANAJER

Manajer adalah seseorang yang bekerja melalui orang lain dengan mengoordinasikan kegiatan-kegiatan mereka guna mencapai sasaran organisasi.

TINGKATAN MANAJER

Pada organisasi berstruktur tradisional, manajer sering dikelompokkan menjadi:

• Manajer puncak (executive officer), bertugas merencanakan kegiatan dan strategi perusahaan secara umum dan mengarahkan jalannya perusahaan.
• Manajer tingkat menengah (middle management) mencaku semua manajemen yang berada di antara manajer lini pertama dan manajemen puncak dan bertugas sebagai penghubung antara keduanya.
• Manajer lini pertama (first-line management) dikenalpula dengan istilah manajemen operasional, merupakan manajemen tingkatan paling rendah yang bertugas memimpin dan mengawasi karyawan non-manajerial yang terlibat dalam proses produksi.

PERAN MANAJER

Henry Mintzberg, seorang ahli riset ilmu manajemen, mengemukakan bahwa ada sepuluh peran yang dimainkan oleh manajer di tempat kerjanya. Ia kemudian mengelompokan kesepuluh peran itu ke dalam tiga kelompok. Yang pertama adalah peran antar pribadi, yaitu melibatkan orang dan kewajiban lain, yang bersifat seremonial dan simbolis. Peran ini meliputi peran sebagai figur untuk anak buah, pemimpin, dan penghubung. Yang kedua adalah peran informasional, meliputi peran manajer sebagai pemantau dan penyebar informasi, serta peran sebagai juru bicara. Yang ketiga adalah peran pengambilan keputusan, meliputi peran sebagai seorang wirausahawan, pemecah masalah, pembagi sumber daya, dan perunding.

Mintzberg kemudian menyimpulkan bahwa secara garis besar, aktivitas yang dilakukan oleh manajer adalah berinteraksi dengan orang lain.

KRITERIA MANAJER YANG BAIK

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

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

Karakter Pribadinya

1. Memiliki pemahaman yang menyeluruh mengenai teknis pekerjaan dari proyek yang dikelola olehnya.

2. Mampu bertindak sebagai seorang pengambil keputusan yang handal dan bertanggung jawab.

3. Memiliki integritas diri yang baik namun tetap mampu menghadirkan suasana yang mendukung di lingkungan tempat dia bekerja.

4. Asertif

5. Memiliki pengalaman dan keahlian yang memadai dalam mengelola waktu dan manusia.

6. Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola

Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola

1. Memiliki komitmen yang kuat dalam meraih tujuan dan keberhasilan proyek dalam jadwal, anggaran dan prosedur yang dibuat.

2. Pelaksanakan seluruh proses pengembangan proyek IT sesuai dengan anggaran dan waktu yang dapat memuaskan para pengguna/klien.

3. Pernah terlibat dalam proyek yang sejenis.

4. Mampu mengendalikan hasil-hasil proyek dengan melakukan pengukuran dan evaluasi kinerja yang disesuaikan dengan standar dan tujuan yang ingin dicapai dari proyek yang dilaksanakan.

5. Membuat dan melakukan rencana darurat untuk mengantisipasi hal-hal maupun masalah tak terduga.

6. Membuat dan menerapkan keputusan terkait dengan perencanaan.

7. 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.

8. Membangun dan menyesuaikan kegiatan dengan prioritas yang ada serta tenggat waktu yang ditentukan sebelumnya.

9. Memiliki kematangan yang tinggi dalam perencanaan yang baik dalam upaya mengurangi tekanan dan stres sehingga dapat meningkatkan produktifitas kerja tim.

10. Mampu membuat perencanaan dalam jangka panjang dan jangka pendek.

11. Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

1. Memiliki kemampuan dan keahlian berkomunikasi serta manajerial.

2. Mampu menyusun rencana, mengorganisasi, memimpin, memotivasi serta mendelegasikan tugas secara bertanggung jawab kepada setiap anggota tim.

3. Menghormati para anggota tim kerjanya serta mendapat kepercayaan dan penghormatan dari mereka.

4. Berbagi sukses dengan seluruh anggota tim.

5. Mampu menempatkan orang yang tepat di posisi yang sesuai.

6. Memberikan apresiasi yang baik kepada para anggota tim yang bekerja dengan baik.

7. Mampu mempengaruhi pihak-pihak lain yang terkait dengan proyek yang dipimpinnya untuk menerima pendapat-pendapatnya serta melaksanakan rencana-rencana yang disusunnya.

8. Mendelegasikan tugas-tugas namun tetap melakukan pengendalian melekat.

9. Memiliki kepercayaan yang tinggi kepada para profesional terlatih untuk menerima pekerjaan-pekerjaan yang didelegasikan darinya.

10. Menjadikan dirinya sebagai bagian yang terintegrasi dengan tim yang dipimpinnya.

11. Mampu membangun kedisiplinan secara struktural.

12. Mampu mengidentifikasi kelebihan-kelebihan dari masing-masing anggota tim serta memanfaatkannya sebagai kekuatan individual.

13. Mendayagunakan setiap elemen pekerjaan untuk menstimulasi rasa hormat dari para personil yang terlibat dan mengembangkan sisi profesionalisme mereka.

14. Menyediakan sedikit waktu untuk menerima setiap ide yang dapat meningkatkan kematangan serta pengembangan dirinya.

15. Selalu terbuka atas hal-hal yang mendorong kemajuan.

16. Memahami secara menyeluruh para anggota tim yang dipimpinnya dan mengembangkan komunikasi efektif di dalamnya.

sumber:

http://www.setiabudi.name/archives/990

*- COCOMO -*

   COCOMO atau Constructive Cost Model adalah model algoritma estimasi biaya perangkat lunak yang dikembangkan oleh Barry Boehm pada tahun 1981. Model ini menggunakan dasar regresi formula, dengan parameter yang berasal dari data historis dan karakteristik proyek-proyek saat ini.

Pada tahun 1981, Barry Boehm mendesain COCOMO untuk memberikan estimasi jumlah Person-Months untuk mengembangkan suatu produk software. Referensi pada model ini dikenal dengan nama COCOMO 81.


    Pada tahun 1990, muncul suatu model estimasi baru yang disebut dengan COCOMO II. Secara umum referensi COCOMO sebelum 1995 merujuk pada original COCOMO model yaitu COCOMO 81, kemudian setelah itu merujuk pada COCOMO II.

Model estimasi COCOMO telah digunakan oleh ribuan project manager suatu proyek perangkat lunak, dan berdasarkan pengalaman dari ratusan proyek sebelumnya. Tidak seperti model estimasi biaya yang lain, COCOMO adalah model terbuka, sehingga semua detail dipublikasikan, termasuk :

• Dasar persamaan perkiraan biaya.
• Setiap asumsi yang dibuat dalam model.
• Setiap definisi.
• Biaya yang disertakan dalam perkiraan dinyatakan secara eksplisit

ada 3 jenis cocomo yaitu :

1. Basic COCOMO (COCOMO I 1981)

Menghitung dari estimasi jumlah LOC (Lines of Code). Pengenalan COCOMO ini diawali di akhir tahun 70-an. 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

ket :
effort = usaha yang dibutuhkan selama proyek, diukur dalam person-months;
c dan M = konstanta-konstanta yang dihasilkan dalam riset Boehm dan tergantung pada penggolongan besarnya proyek perangkat lunak
size = estimasi jumlah baris kode yang dibutuhkan untuk implementasi, dalam satuan KLOC (kilo lines of code).

COCOMO berlaku untuk tiga kelas proyek perangkat lunak:

• Organik proyek : “kecil” tim dengan pengalaman “baik” bekerja dengan “kurang dari kaku” persyaratan.
• Semi-terpisah proyek : “sedang” tim dengan pengalaman bekerja dicampur dengan campuran persyaratan kaku kaku dan kurang dari.
• Embedded proyek : dikembangkan dalam satu set “ketat” kendala (hardware, software, operasional).

2. Intermediate COCOMO (COCOMO II 1999)

Menghitung dari besarnya program dan cost drivers (faktor-faktor yang berpengaruh langsung kepada proyek), seperti: perangkat keras, personal, dan atribut-atribut proyek lainnya. Selain itu pada jenis ini, COCOMO mempergunakan data-data historis dari proyek-proyek yang pernah menggunakan COCOMO I, dan terdaftar pengelolaan proyeknya dalam COCOMO database. yang dijabarkan dalam kategori dan sub-kategori sebagai berikut :

a. Atribut produk (product attributes) :

1. Reliabilitas perangkat lunak yang diperlukan (RELY)
2. Ukuran basis data aplikasi (DATA)
3. Kompleksitas produk (CPLX)

b. Atribut perangkat keras (computer attributes)

1. Waktu eksekusi program ketika dijalankan (TIME)
2. Memori yang dipakai (STOR)
3. Kecepatan mesin virtual (VIRT)
4. Waktu yang diperlukan untuk mengeksekusi perintah (TURN)

c. Atribut sumber daya manusia (personnel attributes)

1. Kemampuan analisis (ACAP)
2. Kemampuan ahli perangkat lunak (PCAP)
3. Pengalaman membuat aplikasi (AEXP)
4. Pengalaman penggunaan mesin virtual (VEXP)
5. Pengalaman dalam menggunakan bahasa pemrograman (LEXP)

d. Atribut proyek (project attributes)

1. Penggunaan sistem pemrograman modern(MODP)
2. Penggunaan perangkat lunak (TOOL)
3. Jadwal pengembangan yang diperlukan (SCED)

COCOMO II EFFORT EQUATION

Model COCOMO II ini membuat estimasi dari usaha yang dibutuhkan (diukur dari Person-Month) berdasarkan keutamaan dalam estimasi anda akan ukuran proyek perangkat lunak (yang diukur dalam ribuan SLOC atau KSLOC) :

Effort = 2,94 * EAF * (KSLOC)E

ket:
EAF = Effort Adjustment Factor yang berasal dari Cost Drivers adalah produk dari effort multipliers yang terhubung pada masing-masing cost drivers untuk proyek.
E = Eksponen yang berasal dari Scale Drivers.

COCOMO II SCHEDULE EQUATION

COCOMO II Schedule Equation memprediksi jumlah bulan yang dibutuhkan untuk menyelesaikan proyek perangkat lunak anda. Durasi dari proyek berdasarkan pada usaha yang diprediksi oleh effort equation :

Duration = 3,67 * (Effort)SE

Dimana :
Effort = usaha dari COCOMO II effort equation.
SE = eksponen scheduled equation yang berasal dari Scale Drivers.

COCOMO II memiliki 3 model berbeda, yakni:


a) The Application Composition Model
Sesuai untuk pembangunan proyek dengan tools GUI-builder yang modern. Berdasar pada Object Points baru.


b) The Early Design Model
Model ini dapat digunakan untuk mendapat estimasi kasar biaya dan durasi dari suatu proyek sebelum menentukan arsitektur keseluruhan proyek tersebut. Model ini menggunakan sekumpulan kecil cost driver baru dan persamaan estimasi baru. Berdasar pada Unadjusted Function Points atau KSLOC.


c) The Post-Architecture Model
Ini adalah model COCOMO II yang paling detail. Digunakannya setelah membentuk arsitektur proyek secara menyeluruh. Model ini memiliki cost driver baru, aturan penghitungan baris yang baru, dan persamaan baru.

3. Advance COCOMO

Memperhitungkan semua karakteristik dari intermediate di atas dan cost drivers dari setiap fase (analisis, desain, implementasi, dsb) dalam siklus hidup pengembangan perangkat lunak. 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 rinci, upaya dihitung sebagai fungsi dari ukuran program dan satu set driver biaya yang diberikan sesuai dengan tiap tahap siklus hidup rekayasa perangkat lunak. Fase yang digunakan dalam COCOMO rinci perencanaan kebutuhan dan perancangan perangkat lunak, perancangan detil, kode dan menguji unit, dan pengujian integrasi.

Referensi :

• http://rpl07.wordpress.com/2007/06/20/cocomo-constructive-cost-model-oleh-dommy-5105-100-163/
• http://ethownside.blogspot.com/2012/04/constructive-cost-model-cocomo.html
• http://pu2tgoclo.blogspot.com/2011/04/apa-itu-cocomo-dan-apa-saja-jenis.html

OPEN SOURCE

  Dalam Bahasa Indonesia, open source adalah kode terbuka. Kode yang dimaksud adalah kode program (perintah-perintah) yang diketikkan berdasarkan logika yang benar).  Suatu program dengan lisensi open source, berarti program tersebut membuka kode programnya bagi siapa saja yang ingin mempelajarinya. Caranya dengan menyertakan kode program bersama dengan distribusi paket program yang sudajh jadi (hasil kompilasi).

  Open source berdasarkan kebebasan user dalam menggunakan pendistribusian dan  lainnya sertasoftware gratis (tanpa biaya). Feature utama dari karakteristik open source adalah kebebasan user untuk: 

>. Menggunakan software sesuai keinginannya 

>. Memiliki software yang tersedia sesuai kebutuhan 

>. Mendistribusikan software kepada user lainnya. 

Open source merupakan implementasi software dalam bentuk source code yang dapat dibaca. Beberapa contohnya adalah web server (apache), Bahasa pemrograman (perl, PHP), sistem operasi (Linux, OpenBSD), pembuat portal (phpnuke, postnuke, mambo), e-learning management system (Moddle, Claroline), dll.

Keuntungan  :

• Open source membebaskan kita dari biaya lisensi karena ia bersifat GNU/GPL (General Public License) yang justru membolehkan kita untuk menggunakan, mempelajari dan memodifikasi serta menyebarluaskan untuk umum. Apalagi untuk sebuah perusahaan besar yang juga menggunakan resource besar. Penggunaan software yang terlalu banyak pasti juga akan menambah biaaya/cost yang besar hanya untuk membeli software
• Dengan menggunakan open source kita dapat mengurangi tingkat pembajakan software berlisensi yang bisa merugikan vendor software dan merupakan beban moral bagi para pengguna software bajakan (crack).
• Open source yang bersifat terbuka dan dapat kita pelajari source codenya bisa kita jadikan referensi, khususnya bagi seseorang yang bergelut dengan dunia IT.
• Adanya hak untuk mendistribusikan modifikasi dan perbaikan pada code.
• Ketersediaan source code dan hak untuk memodifikasi
• Tidak disandera vendor.
  Open source menggunakan format data terbuka, sehingga data menjadi transparan dan bisa dengan bebas diproses di sistem komputer yang berbeda-beda, sambil tetap menjaga keamananya. Dengan demikian, konsumen tidak lagi terikat pada kemauan vendor untuk dapat menggunakan data-datanya.
• Banyaknya tenaga (SDM) untuk mengerjakan proyek.
  Proyek open source biasanya menarik banyak developer, misalnya: pengembangan web serverApache menarik ribuan orang untuk ikut mengembangkan dan memantau.
• Kesalahan (bugs, error) lebih cepat ditemukan dan diperbaiki.
  Hal ini dikarenakan jumlah developer-nya sangat banyak dan tidak dibatasi. Visual inspection (eye-balling) merupakan salah satu metodologi pencarian bugs yang paling efektif. Selain itu, source code tersedia membuat setiap orang dapat mengusulkan perbaikan tanpa harus menunggu dari vendor. 

Kerugian:

• Tidak adanya proteksi terhadap HaKI.
  Kebanyakan orang masih menganggap bahwa open source merupakan aset yang harus dijaga kerahasiannya. Hal ini dikaitkan dengan besarnya usaha yang sudah dikeluarkan untuk membuat produk tersebut. Karena sifatnya dapat di-abuse oleh orang-orang untuk mencuri ide dan karya orang lain.
• Kesulitan dalam mengetahui status project.
• Tidak ada garansi dari pengembangan.
• Limitasi modifikasi oleh orang – orang tertentu yang membuat atau memodifikasi sebelumnya.
• Untuk beberapa platform, contohnya JAVA yang memiliki prinsip satu tulis dan bisa dijalankan dimana saja, akan tetapi ada beberapa hal dari JAVA yang tidak competible dengan platformlainnya. Contohnya J2SE yang  SWT – AWT bridge-nya belum bisa dijalankan di platform Mac OS. 
• Open Source digunakan secara sharing, dapat menimbulkan resiko kurangnya diferensiasi antara satu software dengan yang lain, apabila kebetulan menggunakan beberapa Open Source yang sama.

http://redvchiahack3r.blogspot.com/2012/01/pengenalan-dan-manfaat-menggunakan-open.html
http://id.wikipedia.org/wiki/

TOP DOWN DESIGN

Top - Down Design

Top down design adalah cara sebuah programmer untuk mempermudah memecahkan masalah, yaitu dengan cara menyusun program yang alurnya dari atas ke bawah. Tujuan dari Top - Down design adalah untuk memecah masalah yang besar dan cukup ruwet, menjadi masalah yang lebih kecil atau lebih supaya bisa dipecahkan secara sederhana dan juga cepat.

perancangan top down adalah suatu metode perancangan algoritma yang dimulai dengan memecah utama menjadi beberapa sub masalah, dan jika  perlu memecah masalah lagi setiap submasalah menjadi submasalah dan seterusnya ,

Top-down pemrograman memiliki manfaat sebagai berikut:

• Ini berfokus pada desain modular dengan memisahkan pekerjaan tingkat rendah dari objek tingkat tinggi. Desain modular memastikan mandiri pembangunan.
• Karena setiap modul diproses secara terpisah, programer mendapatkan cukup waktu untuk proses, sehingga menyebabkan kesalahan operasi lebih sedikit
• Proyek menjadi sangat dioptimalkan sebagai setiap pengembang menerapkan pengetahuan sendiri dan pengalaman untuk modul individu.
• Karena programmer masing-masing mendapat bagian yang terlibat dalam, waktu yang dibutuhkan untuk menyelesaikan proyek ini relatif kurang

Langkah - langkah dalam menyusun top - down design   :

1. Dekomposisi masalah utama menjadi utama submasalah - submasalah secara tepat.
2. Periksa bahwa setiap submasalah dipecahkan secara tepat.
3. Pemecahan dari setiap submasalah digabungkan dengan cara tertentu hingga masalah utama terpecahkan.
4. Ulangi langkah satu sampai tiga sampai submasalah dibagi menjadi submasalah yang sederhana dan dapat dipecahkan dengan program yang cukup singkat.