my joehano

This is default featured post 1 title

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

This is default featured post 2 title

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

This is default featured post 3 title

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

This is default featured post 4 title

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

This is default featured post 5 title

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

03/07/13

Kenapa dianjurkan menggunakan software open source dalam membuat aplikasi ?

Kenapa dianjurkan menggunakan software open source dalam membuat aplikasi ? 

Apa keuntungan dan kerugian menggunakan software open source?


Sebelum menjawab alasan tersebut, tentu ada baiknya jika kita mengetahui apa makna dari open source itu sendiri.
Open source merupakan istilah yang digunakan untuk software yang membuka/membebaskan source codenya untuk dilihat oleh orang lain dan membiarkan orang lain mengetahui cara kerja software tersebut dan sekaligus memperbaiki kelemahan-kelemahan yang ada pada software tersebut. Open source software dapat diperoleh dan digunakan secara gratis tanpa perlu membayar lisensi.
Walaupun dapat diperoleh dengan gratis, banyak software open source yang sudah terbukti kehandalannya karena telah melalui proses perbaikan secara terus menerus. Penerapan pola open source juga dapat menghilangkan pemakaian software komersial secara ilegal dan memungkinkan bangsa Indonesia dikenal karya ciptanya dengan ikut mengembangkan software open source.

Beberapa contoh software open source yang dapat diperoleh secara gratis, yaitu:
• Linux
• Open office
• Dia
• Gimp
• Mozilla Thunderbird
• Gantt Project

Untuk menjawab pertanyaan Kenapa anda dianjurkan menggunakan software open source dalam membuat aplikasi ? 
Tentu jawabannya sangat berkaitan dengan banyaknya keuntungan yang dimiliki oleh software open source. Berikut ini merupakan beberapa keuntungan yang dimiliki software open source yang dapat dijadikan alasan mengapa dianjurkan penggunaannya.

KEUNTUNGAN SOFTWARE OPEN SOURCE

1. Bebas biaya tambahan
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.
2. Legal
Software open source bersifat legal atau resmi.
3. Transfer knowledge.
Open source yang bersifat terbuka dan dapat kita pelajari source codenya bisa kita jadikan referensi, khususnya bagi seseorang yang bergelut dengan dunia IT. Tidak mustahil jika ternyata muncul software yang lebih handal daripada software-software berlisensi.

4. Penyelamatan Devisa Negara
Mengingat software berbayar memiliki nominal harga yang cukup tinggi. Maka software Open Source dapat digunakan sebagai solusi, untuk melakukan penghematan  devisa negara secara signifikan. Kemudian dana tersebut dapat dialokasikan ke usaha-usaha untuk kesejahteraan rakyat.

5. Keamanan Negara / Perusahaan

6. Keamanan Sistem Virus, spyware, trojan, dan berbagai masalah keamanan lainnya, sudah akrab dengan banyak penggunakomputer.

7. Membebaskan dari beban moral pembajakan
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).

KERUGIAN SOFTWARE OPEN SOURCE

Selain memiliki keuntungan, ternyata software open souce juga memiliki kekerugian. Diantaranya adalah:

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

Sumber Referensi :

Apa itu COCOMO?

COCOMO (Constructive Cost Model)



Apa itu COCOMO ?? masih cukup asing kita mendengar istilah COCOMO. COCOMO adalah singkatan dariConstructive Cost Model yang merupakan sebuah kombinasi dari estimasi parameter persamaan dan metode pembobotan. Untuk lebih mengenal lagi tetang COCOMO  mari kita lihat artikel berikut .

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

Pengertian COCOMO

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
Perhitungan paling fundamental dalam COCOMO model adalah penggunaan Effort Equation (Persamaan Usaha) untuk mengestimasi jumlah dari Person-Months yang dibutuhkan untuk pengembangan proyek. 

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.


SOURCE LINE OF CODE
  • Perhitungan COCOMO didasarkan pada estimasi anda pada ukuran proyek dalam Source Line Of Code (SLOC). Pendefinisian SLOC:
  • Hanya jumlah baris kode yang dikirim sebagai bagian dari produk yang disertakan (test drivers dan software pendukung lainnya tidak dihitung).
  • Baris kode dibuat oleh staf proyek (kode yang di-generate oleh aplikasi tidak dihitung).
  • Satu SLOC adalah satu baris kode secara logis.
  • Deklarasi dihitung sebagai SLOC.
  • Komentar tidak dihitung sebagai SLOC.
Model COCOMO 81 didefinisikan dalam bentuk Delivered Source Instruction, yang mana sangat menyerupai SLOC. Perbedaan utama antara DSI dan SLOC adalah sebuah SLOC mungkin merupakan beberapa baris secara fisik. Sebagai contoh, sebuah statement “if-then-else” akan dihitung sebagai satu SLOC, tetapi mungkin dihitung sebagai beberapa DSI.

SCALE DRIVERS

Pada model COCOMO II, beberapa factor terpenting yang berkontribusi pada durasi proyek dan biaya yang dikeluarkan adalah Scale Drivers. Anda mengeset setiap Scale Driver untuk mendeskripsikan proyek anda. Scale Drivers tersebut menentukan eksponen yang digunakan dalam Effort Equation.
Ada 5 Scale Drivers :
  • Precedentedness
  • Development Flexibility
  • Architecture / Risk Resolution
  • Team Cohesion
  • Process Maturity
Catat bahwa Scale Drivers telah menggantikan Development Mode dari COCOMO 81. Dua Scale Drivers yang pertama, Precedentedness dan Development Flexibility sebenamya mendeskripsikan pengaruh yang hampir sama dibanding Development Mode.

COST DRIVERS

COCOMO II memiliki 17 cost drivers. Cost driver tersebut adalah factor pengali yang menentukan usaha yang diperlukan untuk menyelesaikan proyek software anda. Sebagai contoh, jika proyek anda akan mengembangkan software yang mengatur penerbangan pesawat, anda akan mengeset Required Software Reliability (RELY) cost driver menjadi sangat tinggi. Rating tersebut berhubungan dengan effort multiplier 1,26 yang berarti bahwa proyek anda akan membutuhkan usaha lebih sebesar 26% dibanding proyek software pada umumnya. COCOMO II mendefinisikan setiap cost drivers dan effort multiplier yang terhubung dengan setiap rating.

Model COCOMO


Model COCOMO terdiri dari 3 model yaitu :

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

Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
  • Proyek organik (organic modeAdalah proyek dengan ukuran relatif kecil, dengan anggota tim 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 dengan 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)
  •           :  jumlah orang yang diperlukan.  


2. Model COCOMO Lanjut (Intermediate COCOMO) 

Pengembangan model COCOMO adalah dengan menambahkan atribut yang dapat menentukan jumlah biaya dan tenaga dalam pengembangan perangkat lunak, yang dijabarkan dalam kategori dan subkatagori 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) 

3. Model COCOMO II (Complete atau Detailed COCOMO model)


Model COCOMO II, pada awal desainnya terdiri dari 7 bobot pengali yang relevan dan kemudian menjadi 16 yang dapat digunakan pada arsitektur terbarunya. Sama seperti COCOMO Intermediate (COCOMO81), masing-masing sub katagori bisa digunakan untuk aplikasi tertentu pada kondisi very low, low, manual, nominal, high maupun very high. Masing-masing kondisi memiliki nilai bobot tertentu. Nilai yang lebih besar dari 1 menunjukkan usaha pengembangan yang meningkat, sedangkan nilai di bawah 1 menyebabkan usaha yang menurun. Kondisi Laju nominal (1) berarti bobot pengali tidak berpengaruh pada estimasi. Maksud dari bobot yang digunakan dalam COCOMO II, harus dimasukkan dan direfisikan di kemudian hari sebagai detail dari proyek aktual yang ditambahkan dalam database. 

Sumber :
ttp://yayuk05.wordpress.com/2007/11/09/constructive-cost-model-cocomo/
http://www.dashboardcafe.com/index.php?option=com_content&view=article&id=102:dashboard-cocomo&catid=1:beritaterbaru&Itemid=50
http://aduk-udik.blogspot.com/2011/03/cocomo-constructive-cost-model.html

kriteria manajer proyek yang baik

kriteria manajer proyek yang baik 
Ketika datang saatnya untuk menjadi seorang pemimpin, dibutuhkan keahlian khusus untuk mengelola dan mengatur suatu organisasi. Pemimpin harus memberikan yang terbaik kepada organisasinya, tidak peduli akan perbedaan antara setiap anggotanya. Konsep tersebut pun berlaku untuk manajemen proyek. Untuk menjadi manajer proyek yang baik harus memiliki beberapa kriteria yang baik pula. Employment Status Indicator (ESI) International telah menyusun daftar tanggapan dari sumber yang berbeda untuk membuat gambaran suatu kriteria manajer proyek yang baik. Berikut ini adalah 10 kriteria teratas yang disusun oleh ESI.
1.       Menginspirasi dengan Visi Bersama
Semua orang perlu memiliki visi yang sama untuk menyelesaikan suatu proyek. Manajer proyek yang baik membantu semua anggota tim agar mereka merasa seperti memiliki kepentingan yang sama dalam sebuah proyek, dan memberdayakan semua orang untuk berbagi dan mengalami visi kelompok. Warren Bennis, pelopor studi Kepemimpinan, mengatakan tentang jenis pemimpin yang visioner: "Mereka menawarkan kesempatan kepada orang-orang untuk menciptakan visi mereka sendiri, untuk mengeksplorasi apa visi tersebut berarti untuk pekerjaan dan kehidupan mereka, dan untuk membayangkan masa depan mereka sebagai bagian dari organisasi."
2.       Kominukator yang Baik
Kemampuan untuk berkomunikasi dengan orang-orang di semua tingkatan hampir selalu disebut sebagai keterampilan yang paling penting kedua oleh manajer proyek dan anggota tim. Kepemimpinan proyek panggilan untuk komunikasi yang jelas tentang tujuan, tanggung jawab, kinerja, harapan dan umpan balik. Ada banyak nilai yang ditempatkan pada keterbukaan dan keterusterangan. Pemimpin proyek juga merupakan penghubung terhadap tim untuk organisasi yang lebih baik. Pemimpin harus memiliki kemampuan untuk secara efektif bernegosiasi dan menggunakan persuasi bila diperlukan untuk memastikan keberhasilan tim dan proyek. Melalui komunikasi yang efektif, pimpinan proyek mendukung prestasi individu dan tim dengan menciptakan pedoman yang jelas untuk mencapai hasil dan untuk kemajuan karir anggota tim.
3.       Integritas
Salah satu hal yang paling penting bagi pemimpin proyek adalah tindakan, dan bukan sekedar kata-kata. Kepemimpinan yang baik menuntut komitmen, dan demonstrasi dari etika. Membuat standar perilaku etis bagi diri sendiri dan hidup dengan standar tersebut, serta memberi penghargaan bagi yang memberikan contoh praktek-praktek tersebut, adalah tanggung jawab pimpinan proyek. Kepemimpinan termotivasi oleh kepentingan diri sendiri, bukan untuk melayani kesejahteraan tim.
4.       Antusiasme
Pemimpin negatif dapat menjadi nyata perangkap untuk keberhasilan proyek dan efektivitas keseluruhan tim. Manajer proyek yang baik memiliki keuletan pada langkah mereka dan sikap percaya diri yang menetapkan kecepatan untuk seluruh tim mereka. Memiliki energi yang baik  sangat penting untuk menetapkan contoh positif dan sikap untuk tim. Manajer proyek yang berkomitmen positif dan memiliki tujuan bahkan ketika melakukan kesalahan akan membantu mengilhami orang lain untuk tidak menjadi negatif ketika proyek mengalami keterlambatan atau halangan.
5.       Empati
Empati dan simpati adalah dua hal yang berbeda. Simpati biasanya diproyeksikan, sedangkan empati berarti benar-benar memahami bagaimana orang lain merasakan sesuatu, terutama ketika datang ke hal-hal yang melibatkan kehidupan di luar pekerjaan. Kadang-kadang empati perlu ditunjukkan kepada anggota tim yang sedang berjuang untuk mengatasi masalah karena bisa saja terdapat masalah pribadi yang mungkin dapat mempengaruhi pekerjaan mereka. Dengan demikian, seorang manajer proyek yang kuat akan berempati dengan masalah anggota tim tanpa menunjukkan penyesalan. Memastikan anggota tim dapat tetap produktif pada proyek, tanpa memperburuk masalah pribadi mereka.
6.       Kompetensi
Anggota tim perlu merasa seperti manajer proyek mereka memiliki beberapa tingkat keahlian dalam subyek proyek. Dengan demikian, pemimpin proyek harus memiliki kemampuan untuk memimpin tim mereka dengan keahlian teknis jika suatu saat terjadi masalah teknis yang tidak dapat diatasi oleh tim. Hal ini tidak berarti seorang manajer proyek pada proyek pengembangan perangkat lunak membutuhkan kemampuan untuk membuka Visual Studio dan mulai coding di console, namun itu tidak berarti bahwa manajer proyek memahami implikasi dari tantangan teknis yang berbeda. Pemimpin yang dianggap sebagai kompeten oleh rekan-rekan mereka memiliki kemampuan untuk menginspirasi, mengaktifkan, dan mendorong.
7.       Mendelegasikan Tugas
Kepercayaan adalah bagian terbesar dari manajemen proyek yang efektif, dan berapa banyak manajer proyek percaya tim mereka sering ditunjukkan melalui seberapa besar tanggung jawab mereka bersedia untuk mendelegasikan. Manajer proyek yang baik memahami tingkat pengawasan setiap kebutuhan anggota tim untuk tugas dari masing-masing anggota. Menetapkan tugas yang tepat untuk orang yang tepat dan mempercayai mereka untuk memanfaatkan yang terbaik dari kemampuan mereka adalah kunci dari karakteristik manajer proyek yang baik.
8.       Stay Cool walaupun dalam Under Pressure
Dalam dunia yang sempurna, setiap proyek akan selesai tepat waktu, sesuai anggaran, dan pada lingkupnya. Sayangnya, kita tidak hidup di dunia yang sempurna. Ketika keadaan menjadi sulit, manajer proyek yang baik bisa tetap menjaga sikapnya untuk tenang. Bennis Waran menyatakan: " Keluar dari ketidakpastian dan kekacauan perubahan, pemimpin bangkit dan mengartikulasikan gambaran baru masa depan yang menarik proyek bersama" Singkatnya, semakin banyak manajer proyek tampak "stres", semakin banyak tim dan klien akan stres juga. Manajer proyek yang baik akan tetap dingin di bawah tekanan.
9.       Keterampilan Team Building
Sebuah pembangun tim terbaik dapat didefinisikan sebagai orang yang kuat yang memberikan substansi yang memegang tim bersama-sama dalam tujuan yang sama menuju tujuan yang tepat. Agar sebuah tim berkembang dari sekelompok orang asing ke unit kohesif tunggal, pemimpin harus memahami proses dan dinamika yang diperlukan untuk transformasi ini. Dia juga harus tahu gaya kepemimpinan yang sesuai untuk digunakan selama setiap tahap pengembangan tim. Pemimpin juga harus memiliki pemahaman tentang pemain tim yang berbeda gaya dan cara memanfaatkan masing-masing pada waktu yang tepat, untuk masalah yang dihadapi.
10.   Tahu Bagaimana Memecahkan Masalah
Manajer proyek yang baik memecahkan masalah dengan berbagi tanggung jawab dengan para ahli di tim mereka. Mirip dengan item nomor 6 di atas tentang kompetensi, bahkan manajer proyek yang baik tidak akan memiliki solusi untuk setiap masalah yang muncul, hanya saja tidak mungkin. Namun, manajer proyek yang baik akan memahami bagaimana untuk mengatur jalur menuju solusi. Hal ini berarti meningkatkan pengetahuan para anggota tim dan para pemangku kepentingan yang memiliki pengetahuan ahli untuk membantu, dan menetapkan rencana untuk memecahkan masalah yang sulit dengan memanfaatkan pengalaman tim. Sebagian besar karakteristik tersebut di atas mengikat satu sama lain, dan jika seorang manajer proyek yang baik akan menampilkan satu atau dua dari kriteria ini maka kemungkinan mereka dapat bekerja untuk menjadi lebih baik.

sumber referensi :
http://www.projectsmart.co.uk/pdf/top-10-qualities-of-a-project-manager.pdf
http://www.recruiter.com/i/10-things-that-make-a-good-project-manager-great/

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites