COCOMO (Constructive Cost Model )
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
Constructive Cost Model (COCOMO) Merupakan algoritma estimasi biaya perangkat lunak model yang dikembangkan oleh Barry Boehm. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasaldari data historis dan karakteristik proyek-proyek saat ini. COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasarestimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya factor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rinciantambahan COCOMO account untuk pengaruh fase proyek individu.
Model Jenis COCOMO Ada tiga model cocomo, diantaranya ialah:
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 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) merupakan proyek yang dibangun dengan spesifikasi dan operasi yang ketat
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.
Sumber :
1. http://haryanto.staff.gunadarma.ac.id/Downloads/files/16705/estimas1.pdf
2. http://kur2003.if.itb.ac.id/file/Manajemen%20Proyek.pdf
3. http://iwayan.info/Lecture/PengelProySI_S1/BukuAjar/PPSI_BAB13.pdf
4. http://www.dicyt.gub.uy/pdt/files/6.2.1_-_cocomo_model.pdf
5. http://ririndisini.wordpress.com/2011/04/13/cocomo/
Sabtu, 16 April 2011
COCOMO
COCOMO (Constructive Cost Model )
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
Constructive Cost Model (COCOMO) Merupakan algoritma estimasi biaya perangkat lunak model yang dikembangkan oleh Barry Boehm. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasaldari data historis dan karakteristik proyek-proyek saat ini. COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasarestimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya factor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rinciantambahan COCOMO account untuk pengaruh fase proyek individu.
Model Jenis COCOMO Ada tiga model cocomo, diantaranya ialah:
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 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) merupakan proyek yang dibangun dengan spesifikasi dan operasi yang ketat
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.
Sumber :
1. http://haryanto.staff.gunadarma.ac.id/Downloads/files/16705/estimas1.pdf
2. http://kur2003.if.itb.ac.id/file/Manajemen%20Proyek.pdf
3. http://iwayan.info/Lecture/PengelProySI_S1/BukuAjar/PPSI_BAB13.pdf
4. http://www.dicyt.gub.uy/pdt/files/6.2.1_-_cocomo_model.pdf
5. http://ririndisini.wordpress.com/2011/04/13/cocomo/
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
Constructive Cost Model (COCOMO) Merupakan algoritma estimasi biaya perangkat lunak model yang dikembangkan oleh Barry Boehm. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasaldari data historis dan karakteristik proyek-proyek saat ini. COCOMO terdiri dari tiga bentuk hirarki semakin rinci dan akurat. Tingkat pertama, Basic COCOMO adalah baik untuk cepat, order awal, kasarestimasi besarnya biaya perangkat lunak, namun akurasinya terbatas karena kurangnya factor untuk memperhitungkan perbedaan atribut proyek (Cost Drivers). Intermediate COCOMO mengambil Driver Biaya ini diperhitungkan dan Rinciantambahan COCOMO account untuk pengaruh fase proyek individu.
Model Jenis COCOMO Ada tiga model cocomo, diantaranya ialah:
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 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) merupakan proyek yang dibangun dengan spesifikasi dan operasi yang ketat
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.
Sumber :
1. http://haryanto.staff.gunadarma.ac.id/Downloads/files/16705/estimas1.pdf
2. http://kur2003.if.itb.ac.id/file/Manajemen%20Proyek.pdf
3. http://iwayan.info/Lecture/PengelProySI_S1/BukuAjar/PPSI_BAB13.pdf
4. http://www.dicyt.gub.uy/pdt/files/6.2.1_-_cocomo_model.pdf
5. http://ririndisini.wordpress.com/2011/04/13/cocomo/
Sabtu, 19 Maret 2011
Keuntungan dan Kerugian Software Open Source
Tulisan “Pengolahan Proyek Sistem Informasi” oleh: Nurul Indah W.A
Menurut David Wheeler, secara umum program yang dinamakan free software (perangkat lunak bebas) atau open source software (perangkat lunak sumber terbuka) adalah program yang lisensinya memberi kebebasan kepada pengguna menjalankan program untuk apa saja, mempelajari dan memodifikasi program, dan mendistribusikan penggandaan program asli atau yang sudah dimodifikasi tanpa harus membayar royalti kepada pengembang sebelumnya.
Open Source Software" (OSS), menurut Esther Dyson (1998), didefinisikan sebagai perangkat lunak yang dikembangkan secara gotong-royong tanpa koordinasi resmi, menggunakan kode program (source code) yang tersedia secara bebas, serta didistribusikan melalui internet.
OSS identik dengan Free Software. Perlu digarisbawahi, definisi free disini bukan berarti gratis, namun free disini berarti bebas. Bebas ini dijabarkan menjadi empat buah, yaitu:
1. Kebebasan untuk menjalankan programnya untuk tujuan apa saja.
2. Kebebasan untuk mempelajari bagaimana program itu bekerja serta dapat disesuaikan dengan kebutuhan anda. Akses pada kode program merupakan suatu prasyarat.
3. Kebebasan untuk menyebarluaskan kembali hasil salinan perangkat lunak tersebut sehingga dapat membantu sesama.
4. Kebebasan untuk meningkatkan kinerja program, dan dapat menyebarkannya ke khalayak umum sehingga semua menikmati keuntungannya. Akses pada kode program merupakan suatu prasyarat juga.
Motivasi dari penggunaan dan pengembangan open source software beraneka ragam, mulai dari filosofi dan alasan etika sampai pada masalah praktis. Biasanya, keuntungan yang dirasa pertama dari model open source adalah fakta bahwa ketersediaan open source diciptakan secara gratis atau dengan biaya yang rendah.
Keutungan Open Source Software:
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. 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. Padahal dengan menggunakan open source biaya itu bisa ditekan seminimal mungkin.
2. 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).
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.
Kerugian Open Source Software:
a. 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.
b. 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.
c. 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 :
• majalah kompas
• http://www.cyberkomputer.com/Komputer/pengenalan-dan-manfaat-menggunakan-open-source
Menurut David Wheeler, secara umum program yang dinamakan free software (perangkat lunak bebas) atau open source software (perangkat lunak sumber terbuka) adalah program yang lisensinya memberi kebebasan kepada pengguna menjalankan program untuk apa saja, mempelajari dan memodifikasi program, dan mendistribusikan penggandaan program asli atau yang sudah dimodifikasi tanpa harus membayar royalti kepada pengembang sebelumnya.
Open Source Software" (OSS), menurut Esther Dyson (1998), didefinisikan sebagai perangkat lunak yang dikembangkan secara gotong-royong tanpa koordinasi resmi, menggunakan kode program (source code) yang tersedia secara bebas, serta didistribusikan melalui internet.
OSS identik dengan Free Software. Perlu digarisbawahi, definisi free disini bukan berarti gratis, namun free disini berarti bebas. Bebas ini dijabarkan menjadi empat buah, yaitu:
1. Kebebasan untuk menjalankan programnya untuk tujuan apa saja.
2. Kebebasan untuk mempelajari bagaimana program itu bekerja serta dapat disesuaikan dengan kebutuhan anda. Akses pada kode program merupakan suatu prasyarat.
3. Kebebasan untuk menyebarluaskan kembali hasil salinan perangkat lunak tersebut sehingga dapat membantu sesama.
4. Kebebasan untuk meningkatkan kinerja program, dan dapat menyebarkannya ke khalayak umum sehingga semua menikmati keuntungannya. Akses pada kode program merupakan suatu prasyarat juga.
Motivasi dari penggunaan dan pengembangan open source software beraneka ragam, mulai dari filosofi dan alasan etika sampai pada masalah praktis. Biasanya, keuntungan yang dirasa pertama dari model open source adalah fakta bahwa ketersediaan open source diciptakan secara gratis atau dengan biaya yang rendah.
Keutungan Open Source Software:
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. 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. Padahal dengan menggunakan open source biaya itu bisa ditekan seminimal mungkin.
2. 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).
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.
Kerugian Open Source Software:
a. 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.
b. 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.
c. 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 :
• majalah kompas
• http://www.cyberkomputer.com/Komputer/pengenalan-dan-manfaat-menggunakan-open-source
Minggu, 28 November 2010
AKS_4KA04_11107278_Nurul Indah W.A
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.
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.
Senin, 15 November 2010
Senin, 25 Oktober 2010
Tugas SPK
| Contoh Kasus yang diselesaikan | ||||
| Suatu pabrik perakitan radio menghasilkan dua tipe radio, yaitu HiFi-1 dan HiFi-2 pada fasilitas | ||||
| perakitan yang sama. Lini perakitan terdiri dari 3 stasiun kerja. Waktu perakitan masing-masing | ||||
| tipe pada masing-masing stasiun kerja adalah sebagai berikut : | ||||
| Stasiun kerja Waktu perakitan per unit (menit) | ||||
| HiFi-1 HiFi-2 | ||||
| 1 6 4 | ||||
| 2 5 5 | ||||
| 3 4 6 | ||||
| Waktu kerja masing-masing stasiun kerja adalah 8 jam per hari. | ||||
| Masing-masing stasiun kerja membutuhkan perawatan harian selama 10%, 14% dan 12% dari | ||||
| total waktu kerja (8 jam) secara berturut-turut untuk stasiun kerja 1,2 dan 3. | ||||
| Formulasikan permasalahan ini kedalam model matematiknya ! | ||||
| Solusi : | ||||
| Alternatif keputusan adalah : radio tipe HiFi-1 (x1) dan radio tipe HiFi-2 (x2). | ||||
| Tujuannya adalah memaksimumkan jumlah radio HiFi-1 dan HiFi-2 yang diproduksi. | ||||
| Sumber daya pembatas adalah : jam kerja masing-masing stasiun kerja dikurangi dengan waktu | ||||
| yang dibutuhkan untuk perawatan. | ||||
| Waktu produktif masing-masing stasiun kerja oleh karenanya adalah : | ||||
| Stasiun 1 : 480 menit – 48 menit = 432 menit | ||||
| Stasiun 2 : 480 menit – 67.2 menit = 412.8 menit | ||||
| Stasiun 3 : 480 menit – 57.6 menit = 422.4 menit. | ||||
| Model umum pemrograman linier : | ||||
| Maksimumkan z = x1 + x2 | ||||
| Kendala : | ||||
| 6x1 + 4x2 ≤ 432 | ||||
| 5x1 + 5x2 ≤ 412.8 | ||||
| 4x1 + 6x2 ≤ 422.4 | ||||
| x1, x2 ≥ 0 | ||||
| Substitusi: | ||||
| 6x1 + 4x2 ≤ 432 |x5| 30x1 + 20x2 = 2160 | ||||
| 5x1 + 5x2 ≤ 412,8 |x4| 20x1 + 20x2 = 1651,2 | ||||
| 10x1 | = 508,8 | |||
| X1 = 50,88 | ||||
| 4x1 + 6x2 ≤ 422,4 |x5| 20x1 + 30x2 = 2112 | ||||
| 5x1 + 5x2 ≤ 412,8 |x4| 20x1 + 20x2 = 1651,2 | ||||
| 10x2 = 460,8 | ||||
| X2 = 46,08 | ||||
| Z = x1 + x2 | ||||
| = 50,88 + 46,08 | ||||
| = 96,96 | ||||
Langganan:
Postingan (Atom)
