3 Jenis COCOMO
Unknown


Post test estimasi

      COCOMO (Constructive Cost Model) merupakan algortima model estimasi biaya perangkat lunak yang dikembangkan dan diterbitkan oleh Barry Boehm. Cocomo digunakan untuk memperkirakan usaha, biaya dan jadwal untuk proyek-proyek perangkat lunak.

1. Basic COCOMO digunakan untuk menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran program yang. Ukuran Program dinyatakan dalam perkiraan ribuan baris kode sumber ( SLOC )

2. Medium COCOMO digunakan untuk menghitung usaha pengembangan perangkat lunak sebagai fungsi dari ukuran program yang dan satu set “driver biaya” yang mencakup penilaian subjektif dari produk, perangkat keras, personil dan atribut proyek. Ekstensi ini mempertimbangkan satu set empat “driver biaya”, masing-masing dengan sejumlah atribut anak.

3. Detail COCOMO digunakan untuk menggabungkan semua karakteristik versi intermediate dengan penilaian dampak cost driver di setiap langkah (analisis, desain, dll) dari proses rekayasa perangkat lunak.

Model rinci menggunakan pengganda usaha yang berbeda untuk setiap cost driver atribut. Ini Tahap pengganda upaya Sensitif masing-masing untuk menentukan jumlah usaha yang diperlukan untuk menyelesaikan setiap tahap.

Sumber :
http://mawardigayo95.blogspot.co.id/2017/06/estimasi-berdasarkan-sejarah-dan-post.html
0 komentar | edit post
Sejarah Estimasi
Unknown


Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus yaitu harus mengerti tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. sehingga dapat membandingkan tugas yang akan di estimasi dengan tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar dapat menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan. Untuk memprogramnya, mungkin generasi dalam bentuk formulir input, Sebuah laporan, perhitungan rumus-rumus, dan lain-lain.

     Perusahaan atau departemen akan membuat tipe proyek yang sama. Carilah dasar untuk membangun “blocks” dan dokumen yang dibutuhkannya.  lakukan langkah pertama dan bangunlah blocks tersebut dalam bentuk yang siap pakai. dan dapat di duga bahwa sebuah penggunaan ulang ternyata lebih akurat jika dibandingkan dengan penulisan ulang. Dalam membandingkan satu apel dengan apel yang lainnya, tulisakan perbedaannya. Catatan statistik dari IBM dan DEC memperlihatkan bahwa kemungkinan perbandingan antara produksi komputer yang baik dengan yang buruk adalah sebesar 8 : 1.

Sumber :
http://mawardigayo95.blogspot.co.id/2017/06/estimasi-berdasarkan-sejarah-dan-post.html

0 komentar | edit post
Tahapan Uji Pada Fase Pemrograman
Unknown


Langkah 1. Rencana Penggabungan ( Plan The Integration )
Menurut akal sehat anda tidak akan dapat membuat semua program sekaligus dan kemudian membuang semuanya – ini memerlukan rangkaian langkah demi langkah.  Rencanakan urutan dimana anda akan menggabungkannya. Bab 9 ini merinci beberapa metode untuk menggabungkan bagian-bagian tersebut, tetapi anda harus merencanakan urutan penggabungan ini sekarang, karena anda harus menulis program supaya dapat digabungkan. Ini disebut Rencana Tes Sistem ( System Test Plan ) .

Langkah 2. Mendisain Modul ( Design The Module )
Programmer menerima beberapa tingkatan disain dari fase disain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampi mencapai keadaan programmer siap untuk melakukan pemrograman.

Langkah 3. Telusuri Disain Modul    ( Walk Through The Module Design ) 
Telusuri disain dari  masing-masing modul sebelum melakukan pengkodean. Penelusuran ini sangat kecil : hanya programmer yang tepat, supervisor dan mungkin programmer lainnya yang perlu diperhatikan. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.

Langkah 4. Rencana Bagaimana Menguji Modul      ( Plan How To Test The Module )
 Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.

Langkah 5. Kode Setiap Modul ( Code Each Module )
 Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu : • Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listing nya tidak lebih dari 2 halaman. • Satu entry , satu exit . • Referensi secara keseluruhan sedikit. • Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).

 Langkah 6. Menguji Modul ( Test The Module )
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.  
Modul seharusnya diuji dalam dua tahap, yaitu :
• Tahap Pertama disebut pengujian “ White Box ”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.
• Tahap Kedua atau pengujian “ Black Box ” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.

Langkah 7. Menguji Level Terendah dari Integrasi    ( Test The Lowest Levels Of Integration)
Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah “ program stub ” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.
Langkah 8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji ( Save The Results Of All Tests; Submit Finished Modules To Integration )
Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program. Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang.
Software seperti CMS ( Code Management System ) sangat berguna untuk menajemen konfigurasi – menjamin program tetap berjalan sesuai versinya dan mengubah ke source code



Langkah 9. Memulai Dokumentasi User   ( Get Started On The User Documentation )  
Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya. 

Sumber: wsilfi.staff.gunadarma.ac.id/Downloads/.../Pertemuan+09+-+Fase+Pemrograman.pdf


0 komentar | edit post