Kekurangan PI kelompok kami adalah tidak adanya peta
dari toko cuci sepatu. Setelah kami analisa lalu kami buat peta yang merujuk
tepat ke lokasi dari toko cuci sepatu. Ini akan membuat pelanggan tau lokasi
dan bisa mengikuti peta yang telah disediakan.
Kamis, 22 Juni 2017
Kelebihan dan Kekurangan dari PI Kelompok Kami
Kelebihan
Kelompok kami membuat sebuah website untuk sebagai
media pemasaran dan promosi dari toko cuci sepatu. Hal ini membuat toko cuci
sepatu bisa disebar luaskan ke orang banyak dan orang pun bisa mengetahui harga
untuk mencuci sepatu di toko ini.
Kekurangan
Kekurangan yang ada di website ini tidak adanya peta
yang merujuk ke lokasi toko cuci sepatu. Walaupun ada alamat tetapi hal ini
akan membuat bingung pengunjung website yang tidak tahu lokasi sekitar toko.
Selasa, 13 Juni 2017
3 Jenis COCOMO
1. BASIC COCOMO (COCOMO I 1981)
Menghitung dari estimasi jumlah LOC (Lines of Code). Pengenalan COCOMO ini diawali di akhir tahun 70-an. Sang pelopor, Boehm, melakukan riset dengan mengambil kasus dari 63 proyek perangkat lunak untuk membuat model matematisnya. Model dasar dari model ini adalah sebuah persamaan sebagai berikut :
effort = C * size^M
ket : effort = usaha yang dibutuhkan selama proyek, diukur dalam person-months; c dan M = konstanta-konstanta yang dihasilkan dalam riset Boehm dan tergantung pada penggolongan besarnya proyek perangkat lunak;
size = estimasi jumlah baris kode yang dibutuhkan untuk implementasi, dalam satuan KLOC (kilo lines of code).
2. INTERMEDIATE (COCOMO II 1999)
Menghitung dari besarnya program dan “cost drivers” (faktor-faktor yangberpengaruh langsung kepada proyek), seperti: perangkat keras, personal, danatribut-atribut proyek lainnya. Selain itu pada jenis ini, COCOMO mempergunakan data-data historis dari proyek-proyek yang pernah menggunakan COCOMO I, dan terdaftar pengelolaan proyeknya dalam COCOMO database. yang dijabarkan dalam kategori dan sub-kategori sebagai berikut :
Menghitung dari estimasi jumlah LOC (Lines of Code). Pengenalan COCOMO ini diawali di akhir tahun 70-an. Sang pelopor, Boehm, melakukan riset dengan mengambil kasus dari 63 proyek perangkat lunak untuk membuat model matematisnya. Model dasar dari model ini adalah sebuah persamaan sebagai berikut :
effort = C * size^M
ket : effort = usaha yang dibutuhkan selama proyek, diukur dalam person-months; c dan M = konstanta-konstanta yang dihasilkan dalam riset Boehm dan tergantung pada penggolongan besarnya proyek perangkat lunak;
size = estimasi jumlah baris kode yang dibutuhkan untuk implementasi, dalam satuan KLOC (kilo lines of code).
2. INTERMEDIATE (COCOMO II 1999)
Menghitung dari besarnya program dan “cost drivers” (faktor-faktor yangberpengaruh langsung kepada proyek), seperti: perangkat keras, personal, danatribut-atribut proyek lainnya. Selain itu pada jenis ini, COCOMO mempergunakan data-data historis dari proyek-proyek yang pernah menggunakan COCOMO I, dan terdaftar pengelolaan proyeknya dalam COCOMO database. yang dijabarkan dalam kategori dan sub-kategori sebagai berikut :
a. Atribut produk (product attributes) :
• Reliabilitas perangkat lunak yang diperlukan (RELY)
• Ukuran basis data aplikasi (DATA)
• Kompleksitas produk (CPLX)
• Reliabilitas perangkat lunak yang diperlukan (RELY)
• Ukuran basis data aplikasi (DATA)
• Kompleksitas produk (CPLX)
b. Atribut perangkat keras (computer attributes)
• Waktu eksekusi program ketika dijalankan (TIME)
• Memori yang dipakai (STOR)
• Kecepatan mesin virtual (VIRT)
• Waktu yang diperlukan untuk mengeksekusi perintah (TURN)
• Waktu eksekusi program ketika dijalankan (TIME)
• Memori yang dipakai (STOR)
• Kecepatan mesin virtual (VIRT)
• Waktu yang diperlukan untuk mengeksekusi perintah (TURN)
c. Atribut sumber daya manusia (personnel attributes)
• Kemampuan analisis (ACAP)
• Kemampuan ahli perangkat lunak (PCAP)
• Pengalaman membuat aplikasi (AEXP)
• Pengalaman penggunaan mesin virtual (VEXP)
• Pengalaman dalam menggunakan bahasa pemrograman (LEXP)
• Kemampuan analisis (ACAP)
• Kemampuan ahli perangkat lunak (PCAP)
• Pengalaman membuat aplikasi (AEXP)
• Pengalaman penggunaan mesin virtual (VEXP)
• Pengalaman dalam menggunakan bahasa pemrograman (LEXP)
d. Atribut proyek (project attributes)
• Penggunaan sistem pemrograman modern(MODP)
• Penggunaan perangkat lunak (TOOL)
• Jadwal pengembangan yang diperlukan (SCED)
• Penggunaan sistem pemrograman modern(MODP)
• Penggunaan perangkat lunak (TOOL)
• Jadwal pengembangan yang diperlukan (SCED)
Model-model COCOMO II adalah :
• COCOMO II EFFORT EQUATION
Model COCOMO II ini membuat estimasi dari usaha yang dibutuhkan (diukur dari Person-Month) berdasarkan keutamaan dalam estimasi anda akan ukuran proyek perangkat lunak (yang diukur dalam ribuan SLOC atau KSLOC) :
Effort = 2,94 * EAF * (KSLOC)E
ket: EAF = Effort Adjustment Factor yang berasal dari Cost Drivers adalah produk dari effort multipliers yang terhubung pada masing-masing cost drivers untuk proyek. E = Eksponen yang berasal dari Scale Drivers.
• COCOMO II SCHEDULE EQUATION
COCOMO II Schedule Equation memprediksi jumlah bulan yang dibutuhkan untuk menyelesaikan proyek perangkat lunak anda. Durasi dari proyek berdasarkan pada usaha yang diprediksi oleh effort equation :
Duration = 3,67 * (Effort)SE
Dimana : Effort = usaha dari COCOMO II effort equation. SE = eksponen scheduled equation yang berasal dari Scale Drivers.
COCOMO II memiliki 3 model berbeda, yakni:
1. The Application Composition Model Sesuai untuk pembangunan proyek dengan tools GUI-builder yang modern. Berdasar pada Object Points baru.
2. The Early Design Model : Model ini dapat digunakan untuk mendapat estimasi kasar biaya dan durasi dari suatu proyek sebelum menentukan arsitektur keseluruhan proyek tersebut. Model ini menggunakan sekumpulan kecil cost driver baru dan persamaan estimasi baru. Berdasar pada Unadjusted Function Points atau KSLOC.
3. The Post-Architecture Model Ini adalah model COCOMO II yang paling detail. Digunakannya setelah membentuk arsitektur proyek secara menyeluruh. Model ini memiliki cost driver baru, aturan penghitungan baris yang baru, dan persamaan baru.
3. ADVANCE COCOMO
Memperhitungkan semua karakteristik dari intermediate di atas dan cost drivers dari setiap fase (analisis, desain, implementasi, dsb) dalam siklus hidup pengembangan perangkat lunak. Model rinci kegunaan yang berbeda upaya pengali untuk setiap driver biaya atribut tersebut. Sensitif pengganda tahap upaya masing-masing untuk menentukan jumlah usaha yang dibutuhkan untuk menyelesaikan setiap tahap.
Pada COCOMO rinci, upaya dihitung sebagai fungsi dari ukuran program dan satu set driver biaya yang diberikan sesuai dengan tiap tahap siklus hidup rekayasa perangkat lunak. Fase yang digunakan dalam COCOMO rinci perencanaan kebutuhan dan perancangan perangkat lunak, perancangan detil, kode dan menguji unit, dan pengujian integrasi. COCOMO berlaku untuk tiga kelas proyek perangkat lunak:
• Organik proyek : “kecil” tim dengan pengalaman “baik” bekerja dengan “kurang dari kaku” persyaratan.
• Semi-terpisah proyek : “sedang” tim dengan pengalaman bekerja dicampur dengan campuran persyaratan kaku kaku dan kurang dari.
• Embedded proyek : dikembangkan dalam satu set “ketat” kendala (hardware, software, operasional).
• COCOMO II EFFORT EQUATION
Model COCOMO II ini membuat estimasi dari usaha yang dibutuhkan (diukur dari Person-Month) berdasarkan keutamaan dalam estimasi anda akan ukuran proyek perangkat lunak (yang diukur dalam ribuan SLOC atau KSLOC) :
Effort = 2,94 * EAF * (KSLOC)E
ket: EAF = Effort Adjustment Factor yang berasal dari Cost Drivers adalah produk dari effort multipliers yang terhubung pada masing-masing cost drivers untuk proyek. E = Eksponen yang berasal dari Scale Drivers.
• COCOMO II SCHEDULE EQUATION
COCOMO II Schedule Equation memprediksi jumlah bulan yang dibutuhkan untuk menyelesaikan proyek perangkat lunak anda. Durasi dari proyek berdasarkan pada usaha yang diprediksi oleh effort equation :
Duration = 3,67 * (Effort)SE
Dimana : Effort = usaha dari COCOMO II effort equation. SE = eksponen scheduled equation yang berasal dari Scale Drivers.
COCOMO II memiliki 3 model berbeda, yakni:
1. The Application Composition Model Sesuai untuk pembangunan proyek dengan tools GUI-builder yang modern. Berdasar pada Object Points baru.
2. The Early Design Model : Model ini dapat digunakan untuk mendapat estimasi kasar biaya dan durasi dari suatu proyek sebelum menentukan arsitektur keseluruhan proyek tersebut. Model ini menggunakan sekumpulan kecil cost driver baru dan persamaan estimasi baru. Berdasar pada Unadjusted Function Points atau KSLOC.
3. The Post-Architecture Model Ini adalah model COCOMO II yang paling detail. Digunakannya setelah membentuk arsitektur proyek secara menyeluruh. Model ini memiliki cost driver baru, aturan penghitungan baris yang baru, dan persamaan baru.
3. ADVANCE COCOMO
Memperhitungkan semua karakteristik dari intermediate di atas dan cost drivers dari setiap fase (analisis, desain, implementasi, dsb) dalam siklus hidup pengembangan perangkat lunak. Model rinci kegunaan yang berbeda upaya pengali untuk setiap driver biaya atribut tersebut. Sensitif pengganda tahap upaya masing-masing untuk menentukan jumlah usaha yang dibutuhkan untuk menyelesaikan setiap tahap.
Pada COCOMO rinci, upaya dihitung sebagai fungsi dari ukuran program dan satu set driver biaya yang diberikan sesuai dengan tiap tahap siklus hidup rekayasa perangkat lunak. Fase yang digunakan dalam COCOMO rinci perencanaan kebutuhan dan perancangan perangkat lunak, perancangan detil, kode dan menguji unit, dan pengujian integrasi. COCOMO berlaku untuk tiga kelas proyek perangkat lunak:
• Organik proyek : “kecil” tim dengan pengalaman “baik” bekerja dengan “kurang dari kaku” persyaratan.
• Semi-terpisah proyek : “sedang” tim dengan pengalaman bekerja dicampur dengan campuran persyaratan kaku kaku dan kurang dari.
• Embedded proyek : dikembangkan dalam satu set “ketat” kendala (hardware, software, operasional).
Estimasi Berdasarkan Sejarah
Jalan keluar dari ketergantungan pada
orang dan untuk membuat estimasi lebih khusus, yaitu anda harus mengerti
tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan
dan siapa yang bertanggung jawab atas tugas tersebut.
Anda dapat membandingkan tugas yang akan
diestimasikan dengan tugas yang sama yang dikerjakan lebih awal, setelah itu
mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar anda menjabarkan
suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk
dibandingkan.
Perbedaan Uji White Box dan Black Box
White Box
Programmer harus
mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga
masing-masing path logical dalam program dapat dieksekusi.
Black Box
Dalam pengujian ini, programmer
mengabaikan bagian dalam dari modul – data disediakan secara berurut dan
dianggap seperti pemakaian sebenarnya.
Tahapan Uji
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.
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.
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.
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.
Langganan:
Postingan (Atom)