Rabu, 25 Mei 2011
Jumat, 20 Mei 2011
Macam-Macam Kriteria Manager Proyek yang Baik
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 dan teknologi. 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 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:
Karakter Pribadinya
Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin
Karakter Pribadi yang Harus Dimiliki Seorang Manager Proyek
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 Tim yang Dipimpin
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.
Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
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.
Skill yang Dibutuhkan Manager Proyek:
Shtub (1994) menggambarkan diagram kemampuan yang penting untuk dimiliki oleh seorang manajer proyek. Diantaranya adalah:
Problem Solving, kemampuan manajer dalam menyelesaikan masalah secara efektif dan efisien.
Budgeting and Cost Skills, Kemampuan dalam hal membuat anggaran biaya proyek, analisis kelayakan investasi agar keuangan proyek dapat berjalan optimal sesuai dengan keinginan penyedia dana.
Schedulling and Time Management Skills, kemampuan untuk menjadwalkan proyek. Disini manajer proyek dituntut untuk dapat mengelola waktu secara baik agar proyek dapat selesai tepat waktu seperti yang diharapkan. Untuk mengelola waktu ini manajer proyek harus mendefinisikan aktivitas-aktivitas yang diperlukan, misalnya dengan teknik WBS atau Work Breakdown Structure. Selain itu manajer proyek harus mampu memperkirakan waktu bagi setiap aktivitas secara realistis. Hal ini memerlukan kordinasi dengan tim proyek untuk menentukan estimasi berapa alam aktivitas tersebut dilakukan. Kemudian, manajer proyek harus mengatur waktu peringatan untuk mengindikasikan tanggal-tanggal kritis selama proyek berlangsung.
Technical Skills, Kemampuan teknis melingkupi pengetahuan dan pengalaman dalam hal proyek itu sendiri, dengan mengetahui prosedur-prosedur dan mekanisme proyek. Kemampuan teknis biasanya di dapat dari penimbaan ilmu khusus di bangku formal, misalnya Institut Manajemen Proyek, dan sebagainya.
Leadership Skills, Kepemimpinan menjadi salah satu peranan penting yang dimiliki oleh seorang manajer proyek. Apa yang dilakukan oleh manajer proyek menendakan bagaimana seharusnya orang lain atau timnya bekerja. Dengan ini manajer proyek dapat mempengaruhi bagaimana orang lain dapat bertindak dan bereaksi terhadap isu-isu proyek.
Resource Management and Human Relationship Skills, Pemakaian sumber daya adalah masalah utama bagi para manajer proyek. Manajer proyek perlu memahami akibat dari kegagalan dalam mengelola sumber daya, oleh karena itu perlu kehati-hatian dalam menempatkan sumberdaya yang ada dan menjadwalkannya. Hal ini membutuhkan kemampuan untuk membangun jaringan social dengan orang-orang yang terlibat di dalam proyek, seperti para stakeholder. Seorang manajer proyek yang efektif harus mampu untuk menempatkan diri dalam memberikan keterbukaan dan persahabatan dengan pihak lain, salah satunya dengan menjadi pendengar yang baik.
Communication Skills, Perencanaan sebuah proyek akan menjadi tidak berguna ketika tidak ada komunikasi yang efektif antara manajer proyek dengan timnya. Setiap anggota tim harus mengetahui tanggung jawab mereka. Kadang, jadwal perencanaan yang sudah dibuat secara sempurna oleh manajer proyek tidak dijalankan oleh timnya, tim lebih memilih bekerja dengan aturan mereka sendiri. Hal ini dikarenakan sang manajer tidak memberikan penjelasan atau mempresentasikan prosedur yang diinginkan dalam menjalankan proyek.
Negotiating Skills, Untuk memperoleh simpati dan dukungan dari manajemen atas, kemampuan negosiasi dititik beratkan disini. Tapi, manajer proyek harus memahami kepentingan manajemen atas sehingga dengan pemahaman ini manajer proyek dapat melakukan bargaining dengan pemikiran yang tenang dan jernih untuk memperoleh apa yang diinginkan. Selain kemampuan komunikasi yang baik, negosiasi juga memerlukan strategi dalam menarik dukungan manajemen atas atau sponsor mereka, bagaimanapun, pihak yang bernegosiasi harus dapat melihat loyalitas sang manajer terhadap mereka, baru kemudian akan muncul kepercayaan.
Marketing, Contracting, Customer Relationship Skills, Kemampuan menjual tidak hanya dimiliki oleh marketer saja, akan tetapi manajer proyek harus memiliki kemampuan untuk memasarkan hasil proyeknya, karena akan sangat tragis ketika sebuah proyek yang sukses secara implementatif, tetapi outputnya tidak dibutuhkan oleh para penggunanya. Bagaimanapun apa yang akan dikatakan sang manajer proyek kepada pelanggannya akan lebih berpengaruh daripada yang mengatakan hanya bagian marketing. Selain itu, kedekatan dengan konsumen sangat diperlukan. Sang manajer perlu responsive terhadap perubahan kebutuhan dan persyaratan pelanggan untuk memenuhi kebutuhan mereka. Sekali lagi, kemampuan komunikasi sangat berperan penting disini. Dalam konsep TQM, kunci utama untuk mengidentifikasi kebutuhan pelanggan adalah komunikasi secara terus-menerus antar pelanggan maupun antar tim proyek (Tjiptono&Diana, 2003).
Kompetensi yang Harus Dimiliki Manajer Proyek:
* Kompetensi Pencapaian Bisnis
* Kompetensi Pemecahan Masalah
* Kompetensi Pengaruh
* Kompetensi Manajemen diri dan orang lain
Sumber :
http://www.lintasberita.com/Lifestyle/Relations/kriteria-manager-proyek-yang-baik
http://nayay.wordpress.com/2010/03/08/manager-proyek/
http://saiiamilla.wordpress.com/2011/05/13/kriteria-manager-proyek-yang-baik/
*Pengarahan 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:
Karakter Pribadinya
Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin
Karakter Pribadi yang Harus Dimiliki Seorang Manager Proyek
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 Tim yang Dipimpin
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.
Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
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.
Skill yang Dibutuhkan Manager Proyek:
Shtub (1994) menggambarkan diagram kemampuan yang penting untuk dimiliki oleh seorang manajer proyek. Diantaranya adalah:
Problem Solving, kemampuan manajer dalam menyelesaikan masalah secara efektif dan efisien.
Budgeting and Cost Skills, Kemampuan dalam hal membuat anggaran biaya proyek, analisis kelayakan investasi agar keuangan proyek dapat berjalan optimal sesuai dengan keinginan penyedia dana.
Schedulling and Time Management Skills, kemampuan untuk menjadwalkan proyek. Disini manajer proyek dituntut untuk dapat mengelola waktu secara baik agar proyek dapat selesai tepat waktu seperti yang diharapkan. Untuk mengelola waktu ini manajer proyek harus mendefinisikan aktivitas-aktivitas yang diperlukan, misalnya dengan teknik WBS atau Work Breakdown Structure. Selain itu manajer proyek harus mampu memperkirakan waktu bagi setiap aktivitas secara realistis. Hal ini memerlukan kordinasi dengan tim proyek untuk menentukan estimasi berapa alam aktivitas tersebut dilakukan. Kemudian, manajer proyek harus mengatur waktu peringatan untuk mengindikasikan tanggal-tanggal kritis selama proyek berlangsung.
Technical Skills, Kemampuan teknis melingkupi pengetahuan dan pengalaman dalam hal proyek itu sendiri, dengan mengetahui prosedur-prosedur dan mekanisme proyek. Kemampuan teknis biasanya di dapat dari penimbaan ilmu khusus di bangku formal, misalnya Institut Manajemen Proyek, dan sebagainya.
Leadership Skills, Kepemimpinan menjadi salah satu peranan penting yang dimiliki oleh seorang manajer proyek. Apa yang dilakukan oleh manajer proyek menendakan bagaimana seharusnya orang lain atau timnya bekerja. Dengan ini manajer proyek dapat mempengaruhi bagaimana orang lain dapat bertindak dan bereaksi terhadap isu-isu proyek.
Resource Management and Human Relationship Skills, Pemakaian sumber daya adalah masalah utama bagi para manajer proyek. Manajer proyek perlu memahami akibat dari kegagalan dalam mengelola sumber daya, oleh karena itu perlu kehati-hatian dalam menempatkan sumberdaya yang ada dan menjadwalkannya. Hal ini membutuhkan kemampuan untuk membangun jaringan social dengan orang-orang yang terlibat di dalam proyek, seperti para stakeholder. Seorang manajer proyek yang efektif harus mampu untuk menempatkan diri dalam memberikan keterbukaan dan persahabatan dengan pihak lain, salah satunya dengan menjadi pendengar yang baik.
Communication Skills, Perencanaan sebuah proyek akan menjadi tidak berguna ketika tidak ada komunikasi yang efektif antara manajer proyek dengan timnya. Setiap anggota tim harus mengetahui tanggung jawab mereka. Kadang, jadwal perencanaan yang sudah dibuat secara sempurna oleh manajer proyek tidak dijalankan oleh timnya, tim lebih memilih bekerja dengan aturan mereka sendiri. Hal ini dikarenakan sang manajer tidak memberikan penjelasan atau mempresentasikan prosedur yang diinginkan dalam menjalankan proyek.
Negotiating Skills, Untuk memperoleh simpati dan dukungan dari manajemen atas, kemampuan negosiasi dititik beratkan disini. Tapi, manajer proyek harus memahami kepentingan manajemen atas sehingga dengan pemahaman ini manajer proyek dapat melakukan bargaining dengan pemikiran yang tenang dan jernih untuk memperoleh apa yang diinginkan. Selain kemampuan komunikasi yang baik, negosiasi juga memerlukan strategi dalam menarik dukungan manajemen atas atau sponsor mereka, bagaimanapun, pihak yang bernegosiasi harus dapat melihat loyalitas sang manajer terhadap mereka, baru kemudian akan muncul kepercayaan.
Marketing, Contracting, Customer Relationship Skills, Kemampuan menjual tidak hanya dimiliki oleh marketer saja, akan tetapi manajer proyek harus memiliki kemampuan untuk memasarkan hasil proyeknya, karena akan sangat tragis ketika sebuah proyek yang sukses secara implementatif, tetapi outputnya tidak dibutuhkan oleh para penggunanya. Bagaimanapun apa yang akan dikatakan sang manajer proyek kepada pelanggannya akan lebih berpengaruh daripada yang mengatakan hanya bagian marketing. Selain itu, kedekatan dengan konsumen sangat diperlukan. Sang manajer perlu responsive terhadap perubahan kebutuhan dan persyaratan pelanggan untuk memenuhi kebutuhan mereka. Sekali lagi, kemampuan komunikasi sangat berperan penting disini. Dalam konsep TQM, kunci utama untuk mengidentifikasi kebutuhan pelanggan adalah komunikasi secara terus-menerus antar pelanggan maupun antar tim proyek (Tjiptono&Diana, 2003).
Kompetensi yang Harus Dimiliki Manajer Proyek:
* Kompetensi Pencapaian Bisnis
* Kompetensi Pemecahan Masalah
* Kompetensi Pengaruh
* Kompetensi Manajemen diri dan orang lain
Sumber :
http://www.lintasberita.com/Lifestyle/Relations/kriteria-manager-proyek-yang-baik
http://nayay.wordpress.com/2010/03/08/manager-proyek/
http://saiiamilla.wordpress.com/2011/05/13/kriteria-manager-proyek-yang-baik/
Selasa, 19 April 2011
COCOMO (Constructive Cost Model)
COCOMO (Constructive Cost Model) dikembangkan pada tahun 1981, oleh Barry Boehm memperkenalkan hirarki model estimasi PL dengan nama COCOMO, Barry Boehm mendesain COCOMO untuk memberikan estimasi / perkiraan 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, setelah itu merujuk pada COCOMO II.
COCOMO II diset sebagai siklus hidup software modern. Orgininal COCOMO model sudah sangat berhasil, tetapi tidak sesuai dengan praktek pengembangan software yang lebih baru sebagaimana dengan software tradisional. COCOMO II menargetkan proyek software pada tahun 1990an sampai 2000an dan akan terus berkembang dalam beberapa tahun ke depan.
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
Ada tiga model cocomo, 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).
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.
Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
* Proyek organik(organic mode) Adalah 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
--------------------------------------------------
Sumber
http://farizzuko.blogspot.com/2011/04/cocomo-constructive-cost-model.html
http://rayawaji.blogspot.com/2010/01/cocomo.html
http://www.ardikirafuda.co.cc/2010/01/cocomo-constructive-cost-model.html
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, setelah itu merujuk pada COCOMO II.
COCOMO II diset sebagai siklus hidup software modern. Orgininal COCOMO model sudah sangat berhasil, tetapi tidak sesuai dengan praktek pengembangan software yang lebih baru sebagaimana dengan software tradisional. COCOMO II menargetkan proyek software pada tahun 1990an sampai 2000an dan akan terus berkembang dalam beberapa tahun ke depan.
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
Ada tiga model cocomo, 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).
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.
Model COCOMO dapat diaplikasikan dalam tiga tingkatan kelas:
* Proyek organik(organic mode) Adalah 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
--------------------------------------------------
Sumber
http://farizzuko.blogspot.com/2011/04/cocomo-constructive-cost-model.html
http://rayawaji.blogspot.com/2010/01/cocomo.html
http://www.ardikirafuda.co.cc/2010/01/cocomo-constructive-cost-model.html
Senin, 21 Maret 2011
Mengapa harus dianjurkan menggunakan software open source dalam membuat aplikasi ??
PENGERTIAN OPEN SOURCE
Open Source adalah sebuah sistem baru dalam mendistribusikan software kepada pengguna dengan memberikan program dan source code nya secara gratis! Bahkan pengguna dapat mempelajari dan melakukan modifikasi untuk membuat software tersebut sesuai dengan kebutuhan mereka. Richard M. Stallman,pendiri Free Software Foundation -sebuah organisasi yang mendukung Open Source,mengeluarkan sebuah lisensi software untuk Open Source yang dinamakan GPL (GNU Public License). Lisensi inilah yang saat ini paling banyak digunakan untuk mendistribusikan software Open Source. Selain GPL, masih banyak lisensi software lainnya yang dikembangkan oleh komunitas Open Source.
Berikut adalah keuntungan software Open Source:
Sisi pengguna:
* Gratis
* Pengguna dapat terlibat dalam pengembangan program karena memiliki
* source code nya
* Respon yang baik dari pemakai sehingga bug dapat ditemukan dan
* diperbaiki dengan lebih cepat.
Sisi developer:
* Seluruh komunitas mau dan dapat membantu untuk membuat software
* menjadi lebih baik
* Tidak ada biaya iklan dan perawatan program
* Sebagai sarana untuk memperkenalkan konsep
Linux adalah sebuah contoh yang bagus. Banyak sistem operasi yang berusaha meniru kisah sukses Linux, tetapi Linux tetap yang paling sukses hingga saat ini. Aspek positif dari Open Source adalah penerimaan yang luas untuk software yang benar-benar bagus.
Selain itu keuntungan dari opensource yaitu:
• Meningkatnya reliabilitas. Oleh karena kode sumber untuk program-program open source tersedia secara bebas maka program yang dibuat oleh seseorang ataupun sesuatu organisasi akan mendapatkan review dari rekan-rekannya ataupun pihak-pihak lain. Hal ini mengakibatkan program-program open source mempunyai reliabilitas yang lebih tinggi dibandingkan dengan program-program closed source (proprietary). Reliabilitas yang tinggi ini tentu saja menguntungkan bagi pihak customer karena ia dapat memperoleh program-program yang dapat diandalkan dalam melakukan tugas-tugas yang diberikan kepadanya.
• Meningkatnya keamanan. Selain itu dengan tersedianya kode sumber maka segala kesalahan yang terdapat dalam program, misalnya kesalahan logika ataupun kesalahan pengkodean, dapat segera diperbaiki tanpa perlu menunggu waktu yang lama, karena seseorang yang menemukan kesalahan tersebut dapat saja segera memperbaikinya dan mengirimkan perbaikan tersebut ke Internet atau bila ia tidak mampu memperbaikinya ia dapat memberitahu pihak-pihak lain. Sebagai contoh, suatu kesalahan dalam Linux umumnya segera diperbaiki dalam kurun waktu kurang dari satu hari, bahkan dalam beberapa jam sejak dikeluarkan. Namun demikian, software yang didistribusikan secara open source tidak menjamin bahwa software tersebut aman.
• Selain itu dengan tersedianya kode sumber maka customer akan merasa lebih nyaman, lebih yakin karena ia tidak membeli kucing dalam karung. Bagaimanakah perasaan Anda bila mobil yang Anda beli tidak dapat dilihat mesinnya ataupun bagian-bagian dalam lainnya ?
Berikut ini adalah beberapa alasan orang membuat software open source :
• Kebutuhan. Software-software open source biasanya dikembangkan karena kebutuhan si pembuatnya. Dalam papernya yang berjudul “The Cathedral and the Bazaar” [Eri00], Eric S. Raymond, menjelaskan secara rinci bagaimana ia mengembangkan software fetchmail, yang disebabkan oleh tiadanya software yang sesuai dengan kebutuhannya. Pengembangan fetchmail juga dimaksudkan untuk menguji beberapa buah teori dalam rekayasa perangkat lunak yang didasarkan pada pengamatannya terhadap Linux.
• Kepuasan. Banyak programer mengembangkan software karena mereka mencintainya dan hal tersebut merupakan pengungkapan intelektualitas mereka. Tanpa melakukan pengkodean, programer merasa dirinya tidak lengkap sebagai manusia.
• Popularitas. Tidak dapat dipungkiri lagi bahwa beberapa orang membuat software open source demi popularitas. Dengan makin banyaknya software yang ditulisnya maka seseorang akan merasa lebih dihargai oleh sejawatnya.
• Uang. Dengan menulis software-software open source maka seseorang dapat meningkatkan nilai dirinya bila nanti direkrut oleh perusahaan-perusahaan. Selain itu, bila software yang dikembangkannya banyak dibutuhkan oleh perusahaan-perusahaan, pembuat software tersebut dapat saja mendirikan sebuah perusahaan untuk memberikan pelayanan bagi perusahaan. Contoh hal ini adalah Eric Allman yang mendirikan perusahaan Sendmail Inc. untuk memberikan pelayanan tambahan bagi mereka yang menggunakan Sendmail.
Permasalahan Open Source
Pengembangan software berbasiskan open source selain memberikan beberapa buah keuntungan sebagaimana yang telah disebutkan di bagian terdahulu artikel juga memiliki beberapa permasalahan sebagai berikut :
• Dengan banyaknya orang yang terlibat dalam pembuatan proyek software tidak menjamin bahwa proyek akan selesai dengan lebih cepat. Ada kemungkinan proyek bahkan tidak dapat terlaksana. Hal ini disebabkan dengan semakin banyaknya orang maka perbedaan akan sering terjadi, oleh karena itu diperlukan seorang pemimpin yang mampu bekerja sama dengan rekan-rekannya yang lain untuk membuat suatu arahan yang jelas tentang proyek.
• Menurut Alan Cox dalam papernya “Cathedrals, Bazaars and the Town Council” [Ala98], permasalahan akan muncul ketika tibanya banyak orang yang tidak paham dan mereka mulai mengemukakan opininya, bukan memberikan kodenya. Mereka berdebat tentang hal-hal yang tidak berguna. Hal ini tentu saja akan sangat merugikan karena perdebatan tersebut tidak akan menghasilkan apa-apa.
• Konflik di antara para pengembang. Terkadang dalam model open source sebagaimana juga terjadi dalam model pengembangan ilmiah, terjadi konflik antara para pengembang. Hal ini dapat terjadi bila satu atau beberapa pengembang merasa tidak puas dengan pengembang lainnya, baik dalam hal pencapaian ataupun masalah-masalah teknis dalam proyek yang sedang mereka kerjakan. Bilamana hal ini telah terjadi dapat mengakibatkan tertundanya proyek yang sedang mereka kerjakan, bahkan tidak tertutup kemungkinan proyek tersebut menjadi gagal.
• Pemilihan software. Umumnya software-software yang dikembangkan disebabkan karena menarik minat pengembang baik secara langsung maupun tidak langsung. Dengan adanya kecendrungan model open source yang dimulai oleh seorang individu maka pengembangannya akan lebih bersifat developer oriented, yang berarti software yang lebih kompleks, namun belum tentu lebih bermanfaat. Pengembang akan membuat software-software yang terlihat menyenangkan, seperti membuat themes untuk GNOME, KDE maupun editor, dibandingkan dengan membuat aplikasi-aplikasi yang dianggap membosankan seperti Office Suites. Tanpa adanya insentif lain maka akan banyak proyek mati karena pengembang awal telah kehilangan minat dan tidak ada yang meneruskan.
• Fragmentasi. Dengan tersedianya kode sumber untuk setiap aplikasi, maka seseorang dapat saja merubah sebagian kode sumber asli dan mengeluarkan aplikasi yang sama dengan nama baru atau mengeluarkan aplikasi sama dengan versi baru.
• Ketergantungan pada satu orang pemimpin. Proyek-proyek open source biasanya dimulai oleh satu atau beberapa orang, sehingga ketergantungan menjadi sangat tinggi. Dengan berlalunya waktu, para pemimpin tersebut mungkin menjadi bosan, burn-out, dipekerjakan oleh organisasi lain. Akibatnya proyek-proyek yang mereka tangani dapat menjadi tertunda atau bahkan mungkin hilang.
• Penjiplakan. Dengan tersedianya kode sumber bagi setiap software, tidak tertutup kemungkinan ada pihak-pihak yang memanfaatkan hal tersebut demi kepentingan dirinya, misalnya saja seorang mahasiswa ilmu komputer mendapat tugas untuk membuat suatu program, ia kemudian mencarinya di Internet dan mendapatkan versi open sourcenya. Lalu ia memodifikasi sedikit program tersebut dan menyerahkan pada dosennya untuk dinilai. Bila dosen tidak waspada maka program tersebut akan lolos dan si mahasiswa akan mendapat nilai dengan mudah dan tidak adil bagi mahasiswa yang membuatnya sendiri.
SUMBER LINKNYA :
http://wartawarga.gunadarma.ac.id/2010/06/open-source-31/
http://tedi.heriyanto.net/papers/pengembangan.html
Open Source adalah sebuah sistem baru dalam mendistribusikan software kepada pengguna dengan memberikan program dan source code nya secara gratis! Bahkan pengguna dapat mempelajari dan melakukan modifikasi untuk membuat software tersebut sesuai dengan kebutuhan mereka. Richard M. Stallman,pendiri Free Software Foundation -sebuah organisasi yang mendukung Open Source,mengeluarkan sebuah lisensi software untuk Open Source yang dinamakan GPL (GNU Public License). Lisensi inilah yang saat ini paling banyak digunakan untuk mendistribusikan software Open Source. Selain GPL, masih banyak lisensi software lainnya yang dikembangkan oleh komunitas Open Source.
Berikut adalah keuntungan software Open Source:
Sisi pengguna:
* Gratis
* Pengguna dapat terlibat dalam pengembangan program karena memiliki
* source code nya
* Respon yang baik dari pemakai sehingga bug dapat ditemukan dan
* diperbaiki dengan lebih cepat.
Sisi developer:
* Seluruh komunitas mau dan dapat membantu untuk membuat software
* menjadi lebih baik
* Tidak ada biaya iklan dan perawatan program
* Sebagai sarana untuk memperkenalkan konsep
Linux adalah sebuah contoh yang bagus. Banyak sistem operasi yang berusaha meniru kisah sukses Linux, tetapi Linux tetap yang paling sukses hingga saat ini. Aspek positif dari Open Source adalah penerimaan yang luas untuk software yang benar-benar bagus.
Selain itu keuntungan dari opensource yaitu:
• Meningkatnya reliabilitas. Oleh karena kode sumber untuk program-program open source tersedia secara bebas maka program yang dibuat oleh seseorang ataupun sesuatu organisasi akan mendapatkan review dari rekan-rekannya ataupun pihak-pihak lain. Hal ini mengakibatkan program-program open source mempunyai reliabilitas yang lebih tinggi dibandingkan dengan program-program closed source (proprietary). Reliabilitas yang tinggi ini tentu saja menguntungkan bagi pihak customer karena ia dapat memperoleh program-program yang dapat diandalkan dalam melakukan tugas-tugas yang diberikan kepadanya.
• Meningkatnya keamanan. Selain itu dengan tersedianya kode sumber maka segala kesalahan yang terdapat dalam program, misalnya kesalahan logika ataupun kesalahan pengkodean, dapat segera diperbaiki tanpa perlu menunggu waktu yang lama, karena seseorang yang menemukan kesalahan tersebut dapat saja segera memperbaikinya dan mengirimkan perbaikan tersebut ke Internet atau bila ia tidak mampu memperbaikinya ia dapat memberitahu pihak-pihak lain. Sebagai contoh, suatu kesalahan dalam Linux umumnya segera diperbaiki dalam kurun waktu kurang dari satu hari, bahkan dalam beberapa jam sejak dikeluarkan. Namun demikian, software yang didistribusikan secara open source tidak menjamin bahwa software tersebut aman.
• Selain itu dengan tersedianya kode sumber maka customer akan merasa lebih nyaman, lebih yakin karena ia tidak membeli kucing dalam karung. Bagaimanakah perasaan Anda bila mobil yang Anda beli tidak dapat dilihat mesinnya ataupun bagian-bagian dalam lainnya ?
Berikut ini adalah beberapa alasan orang membuat software open source :
• Kebutuhan. Software-software open source biasanya dikembangkan karena kebutuhan si pembuatnya. Dalam papernya yang berjudul “The Cathedral and the Bazaar” [Eri00], Eric S. Raymond, menjelaskan secara rinci bagaimana ia mengembangkan software fetchmail, yang disebabkan oleh tiadanya software yang sesuai dengan kebutuhannya. Pengembangan fetchmail juga dimaksudkan untuk menguji beberapa buah teori dalam rekayasa perangkat lunak yang didasarkan pada pengamatannya terhadap Linux.
• Kepuasan. Banyak programer mengembangkan software karena mereka mencintainya dan hal tersebut merupakan pengungkapan intelektualitas mereka. Tanpa melakukan pengkodean, programer merasa dirinya tidak lengkap sebagai manusia.
• Popularitas. Tidak dapat dipungkiri lagi bahwa beberapa orang membuat software open source demi popularitas. Dengan makin banyaknya software yang ditulisnya maka seseorang akan merasa lebih dihargai oleh sejawatnya.
• Uang. Dengan menulis software-software open source maka seseorang dapat meningkatkan nilai dirinya bila nanti direkrut oleh perusahaan-perusahaan. Selain itu, bila software yang dikembangkannya banyak dibutuhkan oleh perusahaan-perusahaan, pembuat software tersebut dapat saja mendirikan sebuah perusahaan untuk memberikan pelayanan bagi perusahaan. Contoh hal ini adalah Eric Allman yang mendirikan perusahaan Sendmail Inc. untuk memberikan pelayanan tambahan bagi mereka yang menggunakan Sendmail.
Permasalahan Open Source
Pengembangan software berbasiskan open source selain memberikan beberapa buah keuntungan sebagaimana yang telah disebutkan di bagian terdahulu artikel juga memiliki beberapa permasalahan sebagai berikut :
• Dengan banyaknya orang yang terlibat dalam pembuatan proyek software tidak menjamin bahwa proyek akan selesai dengan lebih cepat. Ada kemungkinan proyek bahkan tidak dapat terlaksana. Hal ini disebabkan dengan semakin banyaknya orang maka perbedaan akan sering terjadi, oleh karena itu diperlukan seorang pemimpin yang mampu bekerja sama dengan rekan-rekannya yang lain untuk membuat suatu arahan yang jelas tentang proyek.
• Menurut Alan Cox dalam papernya “Cathedrals, Bazaars and the Town Council” [Ala98], permasalahan akan muncul ketika tibanya banyak orang yang tidak paham dan mereka mulai mengemukakan opininya, bukan memberikan kodenya. Mereka berdebat tentang hal-hal yang tidak berguna. Hal ini tentu saja akan sangat merugikan karena perdebatan tersebut tidak akan menghasilkan apa-apa.
• Konflik di antara para pengembang. Terkadang dalam model open source sebagaimana juga terjadi dalam model pengembangan ilmiah, terjadi konflik antara para pengembang. Hal ini dapat terjadi bila satu atau beberapa pengembang merasa tidak puas dengan pengembang lainnya, baik dalam hal pencapaian ataupun masalah-masalah teknis dalam proyek yang sedang mereka kerjakan. Bilamana hal ini telah terjadi dapat mengakibatkan tertundanya proyek yang sedang mereka kerjakan, bahkan tidak tertutup kemungkinan proyek tersebut menjadi gagal.
• Pemilihan software. Umumnya software-software yang dikembangkan disebabkan karena menarik minat pengembang baik secara langsung maupun tidak langsung. Dengan adanya kecendrungan model open source yang dimulai oleh seorang individu maka pengembangannya akan lebih bersifat developer oriented, yang berarti software yang lebih kompleks, namun belum tentu lebih bermanfaat. Pengembang akan membuat software-software yang terlihat menyenangkan, seperti membuat themes untuk GNOME, KDE maupun editor, dibandingkan dengan membuat aplikasi-aplikasi yang dianggap membosankan seperti Office Suites. Tanpa adanya insentif lain maka akan banyak proyek mati karena pengembang awal telah kehilangan minat dan tidak ada yang meneruskan.
• Fragmentasi. Dengan tersedianya kode sumber untuk setiap aplikasi, maka seseorang dapat saja merubah sebagian kode sumber asli dan mengeluarkan aplikasi yang sama dengan nama baru atau mengeluarkan aplikasi sama dengan versi baru.
• Ketergantungan pada satu orang pemimpin. Proyek-proyek open source biasanya dimulai oleh satu atau beberapa orang, sehingga ketergantungan menjadi sangat tinggi. Dengan berlalunya waktu, para pemimpin tersebut mungkin menjadi bosan, burn-out, dipekerjakan oleh organisasi lain. Akibatnya proyek-proyek yang mereka tangani dapat menjadi tertunda atau bahkan mungkin hilang.
• Penjiplakan. Dengan tersedianya kode sumber bagi setiap software, tidak tertutup kemungkinan ada pihak-pihak yang memanfaatkan hal tersebut demi kepentingan dirinya, misalnya saja seorang mahasiswa ilmu komputer mendapat tugas untuk membuat suatu program, ia kemudian mencarinya di Internet dan mendapatkan versi open sourcenya. Lalu ia memodifikasi sedikit program tersebut dan menyerahkan pada dosennya untuk dinilai. Bila dosen tidak waspada maka program tersebut akan lolos dan si mahasiswa akan mendapat nilai dengan mudah dan tidak adil bagi mahasiswa yang membuatnya sendiri.
SUMBER LINKNYA :
http://wartawarga.gunadarma.ac.id/2010/06/open-source-31/
http://tedi.heriyanto.net/papers/pengembangan.html
Jumat, 11 Februari 2011
Lyric Ishikawa Marie - 7 days / pro. by AILI ( OST Shibuhara Girl )
7 days / pro. by AILI
Lyrics & Music: AILI
spicy sugar feeling...
I'm walking the wide way
SANGURASU shite
Akai IYAFUON kara
Kikoeru Pop Rock.
twenty-four a day Nani ka kangaete bakari
Ano hito no koto ya ashita kiru fuku no koto
Monday, Tuesday, Wednesday,
Nani ka tarinakute
Thursday, Friday, Saturday, Sunday
Nani ka sagashite iru
1&2,3
PANPUSU, NEKKURESU, PIASU, Who the less
4,5,6,7
Love and Dream Love and Dream
Love and Dream Love and Dream
WATASHi rashiku Warau tame ni
Love and Dream Love and Dream
Love and Dream Love and Dream
Kanau you ni Yume wo mitai
spicy sugar feeling...
Passed yesterday...
Risou ni michita
Kokoro no katasumi
Mujun ga umoreru
I don't wanna cry no more. Namida kakusu koto mo
Gomakasu koto sae Umaku natte kitashi
Monday, Tuesday, Wednesday,
Takai HIIRU haite
Thursday, Friday, Saturday, Sunday
Amai kaori tsukete
1&2,3
KURACCHI BAGGU, BURESURETTO, JAKETTO, Who the next
4,5,6,7
Love and Dream Love and Dream
Love and Dream Love and Dream
WATASHi rashiku Warau tame ni
Love and Dream Love and Dream
Love and Dream Love and Dream
Kanau you ni Yume wo mitai
spicy sugar feeling...
Hey Hito no nami wo Kuguri nuke
Hey Toomawari demo Ii kara
Seven days a week. Three sixty-five a year
Day and Night Day and Night
Any time or plae, any place or time.
Love and Dream Love and Dream
Any time or plae, any place or time.
Love and Dream Love and Dream
Love and Dream Love and Dream
WATASHi rashiku Warau tame ni
Love and Dream Love and Dream
Love and Dream Love and Dream
Kanau you ni Yume wo mitai
Love and Dream Love and Dream
Love and Dream Love and Dream
Hibiku Yureru Eien ni Hikaru
Love and Dream Love and Dream
Love and Dream Love and Dream
Tsuki no Naka de KOKORO Utau
spicy sugar feeling
------------------------------
Note :
(INA ver.)
Bagi yang punya alamat Link MP3 nya..tolong kasih tahu y...karena saya sendiri sedikit susah untuk mencarinya....LOL
(ENG ver.)
For those who have MP3 Link address it .. please tell y. .. because I own a little difficult to find it .... LOL
(JAP ver.)
誰MP3リンクアドレスをお持ちの方は、.. yを教えてください...私は少し難しいを見つけるために所有しているので.... LOLを
Lyrics & Music: AILI
spicy sugar feeling...
I'm walking the wide way
SANGURASU shite
Akai IYAFUON kara
Kikoeru Pop Rock.
twenty-four a day Nani ka kangaete bakari
Ano hito no koto ya ashita kiru fuku no koto
Monday, Tuesday, Wednesday,
Nani ka tarinakute
Thursday, Friday, Saturday, Sunday
Nani ka sagashite iru
1&2,3
PANPUSU, NEKKURESU, PIASU, Who the less
4,5,6,7
Love and Dream Love and Dream
Love and Dream Love and Dream
WATASHi rashiku Warau tame ni
Love and Dream Love and Dream
Love and Dream Love and Dream
Kanau you ni Yume wo mitai
spicy sugar feeling...
Passed yesterday...
Risou ni michita
Kokoro no katasumi
Mujun ga umoreru
I don't wanna cry no more. Namida kakusu koto mo
Gomakasu koto sae Umaku natte kitashi
Monday, Tuesday, Wednesday,
Takai HIIRU haite
Thursday, Friday, Saturday, Sunday
Amai kaori tsukete
1&2,3
KURACCHI BAGGU, BURESURETTO, JAKETTO, Who the next
4,5,6,7
Love and Dream Love and Dream
Love and Dream Love and Dream
WATASHi rashiku Warau tame ni
Love and Dream Love and Dream
Love and Dream Love and Dream
Kanau you ni Yume wo mitai
spicy sugar feeling...
Hey Hito no nami wo Kuguri nuke
Hey Toomawari demo Ii kara
Seven days a week. Three sixty-five a year
Day and Night Day and Night
Any time or plae, any place or time.
Love and Dream Love and Dream
Any time or plae, any place or time.
Love and Dream Love and Dream
Love and Dream Love and Dream
WATASHi rashiku Warau tame ni
Love and Dream Love and Dream
Love and Dream Love and Dream
Kanau you ni Yume wo mitai
Love and Dream Love and Dream
Love and Dream Love and Dream
Hibiku Yureru Eien ni Hikaru
Love and Dream Love and Dream
Love and Dream Love and Dream
Tsuki no Naka de KOKORO Utau
spicy sugar feeling
------------------------------
Note :
(INA ver.)
Bagi yang punya alamat Link MP3 nya..tolong kasih tahu y...karena saya sendiri sedikit susah untuk mencarinya....LOL
(ENG ver.)
For those who have MP3 Link address it .. please tell y. .. because I own a little difficult to find it .... LOL
(JAP ver.)
誰MP3リンクアドレスをお持ちの方は、.. yを教えてください...私は少し難しいを見つけるために所有しているので.... LOLを
Minggu, 19 Desember 2010
Senin, 29 November 2010
Pendekatan Pengembangan Sistem
Dipandang dari metodologi yang digunakan:
* Pendekatan Klasik (Clasical approach), Disebut juga pengembangan tradisional / konvensional adalah pengembangan sistem dengan mengikuti tahapan pada system life cycle. Pendekatan ini menekankan bahwa pengembangan sistem akan berhasil bila mengikuti tahapan pada system life cycle. Tetapi pada kenyataannya pendekatan klasik tidak cukup digunakan untuk mengembangkan suatu sistem informasi yang sukses dan akan timbul beberapa permasalahan diantaranya adalah :
1. Pengembangan perangkat lunak menjadi sulit
2. Biaya perawatan atau pemeliharaan sistem menjadi lebih mahal
3. Kemungkinan kesalahan sistem besar
4. Keberhasilan sistem kurang terjamin
5. Masalah dalam penerapan sistem
* Pendekatan Terstruktur (structured approach), Pendekatan ini dimulai pada awal tahun 1970, dan dilengkapi dengan alat-alat (tools) dan teknik-teknik (techniques) yg dibutuhkan dalam pengembangan sistem.
Dipandang dari sasaran yang dicapai :
* Pendekatan Sepotong (piecerneal approach), Pendekatan yg menekankan pada suatu kegiatan / aplikasi tertentu.
* Pendekatan Sistem (systems approach), Pendekatan yg menekankan pada sistem informasi sebagai satu kesatuan terintegrasi
Dipandang dari cara menentukan kebutuhan dari Sistem :
* Pendekatan Bawah Naik (Bottom Up Approach), Pendekatan dari level bawah organisasi, yaitu level operasional dimana transaksi dilakukan. Pendekatan ini dimulai dari perumusan kebutuhan untuk menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan informasi berdasarkan transaksi tsb. (merupakan ciri-ciri dari pendekatan klasik disebut juga data analysis).
* Pendekatan Atas Turun, Dimulai dari level atas yaitu level perencanaan strategi. Pendekatan ini dimulai dengan mendefinisikan sarasan dan kebijaksanaan organisasi , kemudian dilakukan analisis kebutuhan informasi , lalu proses turun ke pemrosesan transaksi (merupakan ciri-ciri dari pendekatan terstruktur disebut juga decision analysis )
Dipandang dari cara mengembangkannya :
* Pendekatan Sistem menyeluruh, Pendekatan yg mengembangkan sistem serentak secara menyeluruh(merupakan ciri -ciri pendekatan klasik )
* Pendekatan Moduler, Pendekatan yg berusaha memecah sistem yg rumit menjadi beberapa bagian / modul yg sederhana (merupakan ciri -ciri pendekatan terstruktur).
Dipandang dari teknologi yg digunakan :
* Pendekatan Lompatan jauh (great loop approach), Pendekatan yg menerapkan perubahan menyeluruh secara serentak penggunaan teknologi canggih. Perubahan ini banyak mengandung resiko, juga memerlukan investasi yg besar.
* Pendekatan Berkembang (evolutionary approach), Pendekatan yg menerapkan perubahan canggih hanya untuk aplikasi yg memerlukan saja, dan akan terus berkembang.
* Pendekatan Klasik (Clasical approach), Disebut juga pengembangan tradisional / konvensional adalah pengembangan sistem dengan mengikuti tahapan pada system life cycle. Pendekatan ini menekankan bahwa pengembangan sistem akan berhasil bila mengikuti tahapan pada system life cycle. Tetapi pada kenyataannya pendekatan klasik tidak cukup digunakan untuk mengembangkan suatu sistem informasi yang sukses dan akan timbul beberapa permasalahan diantaranya adalah :
1. Pengembangan perangkat lunak menjadi sulit
2. Biaya perawatan atau pemeliharaan sistem menjadi lebih mahal
3. Kemungkinan kesalahan sistem besar
4. Keberhasilan sistem kurang terjamin
5. Masalah dalam penerapan sistem
* Pendekatan Terstruktur (structured approach), Pendekatan ini dimulai pada awal tahun 1970, dan dilengkapi dengan alat-alat (tools) dan teknik-teknik (techniques) yg dibutuhkan dalam pengembangan sistem.
Dipandang dari sasaran yang dicapai :
* Pendekatan Sepotong (piecerneal approach), Pendekatan yg menekankan pada suatu kegiatan / aplikasi tertentu.
* Pendekatan Sistem (systems approach), Pendekatan yg menekankan pada sistem informasi sebagai satu kesatuan terintegrasi
Dipandang dari cara menentukan kebutuhan dari Sistem :
* Pendekatan Bawah Naik (Bottom Up Approach), Pendekatan dari level bawah organisasi, yaitu level operasional dimana transaksi dilakukan. Pendekatan ini dimulai dari perumusan kebutuhan untuk menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan informasi berdasarkan transaksi tsb. (merupakan ciri-ciri dari pendekatan klasik disebut juga data analysis).
* Pendekatan Atas Turun, Dimulai dari level atas yaitu level perencanaan strategi. Pendekatan ini dimulai dengan mendefinisikan sarasan dan kebijaksanaan organisasi , kemudian dilakukan analisis kebutuhan informasi , lalu proses turun ke pemrosesan transaksi (merupakan ciri-ciri dari pendekatan terstruktur disebut juga decision analysis )
Dipandang dari cara mengembangkannya :
* Pendekatan Sistem menyeluruh, Pendekatan yg mengembangkan sistem serentak secara menyeluruh(merupakan ciri -ciri pendekatan klasik )
* Pendekatan Moduler, Pendekatan yg berusaha memecah sistem yg rumit menjadi beberapa bagian / modul yg sederhana (merupakan ciri -ciri pendekatan terstruktur).
Dipandang dari teknologi yg digunakan :
* Pendekatan Lompatan jauh (great loop approach), Pendekatan yg menerapkan perubahan menyeluruh secara serentak penggunaan teknologi canggih. Perubahan ini banyak mengandung resiko, juga memerlukan investasi yg besar.
* Pendekatan Berkembang (evolutionary approach), Pendekatan yg menerapkan perubahan canggih hanya untuk aplikasi yg memerlukan saja, dan akan terus berkembang.
Langganan:
Postingan (Atom)
