Jumat, 23 Juni 2017

FASE PEMROGRAMAN



Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang. kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan pembangun pun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement.
Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Requirement berfungsi ganda yaitu:
Menjadi dasar penawaran suatu kontrak è harus terbuka untuk masukan
Menjadi dasar kontrak è harus didefinisikan secara detil
Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan tersebut disebut Requirement Engineering.

Pengumpulan requirement
Interviews : Memberi informasi yang terbaik,mahal
Questionnaires: Bagus jika banyak orang terlibat dan tersebar, respon cenderung kurang baik
Observation: Akurat jika dilakukan dengan baik, mahal
Searching :Informasi terbatas, cenderung tidak menampilkan hal-hal yang mungkin jadi masalah
Beberapa macam requirement :

User requirement (kebutuhan pengguna)
ü Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

System requirement (kebutuhan sistem)
ü Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

A software design specification (spesifikasi rancangan PL)
ü Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.


  • Perbedaan White Box & Black Box
    • White box (Struktural) 
      • Dilakukan oleh penguji yang mengetahui tentang QA.
      • Melakukan testing pada software/program aplikasi menyangkut security dan performance program tersebut (meliputi tes code, desain implementasi, security, data flow, software failure).
      • Dilakukan seiring dengan tahapan pengembangan software atau pada tahap testing. 
    • Metode BlackBox  (Fungsional) 
      • Dilakukan oleh penguji Independent.
      • Melakukan pengujian berdasarkan apa yang dilihat, hanya fokus terhadap fungsionalitas dan output. Pengujian lebih ditujukan pada desain software sesuai standar dan reaksi apabila terdapat celah-celah bug/vulnerabilitas pada program aplikasi tersebut setelah dilakukan white box testing. 
      • Dilakukan setelah white box testing. 



TAHAP FASE PEMROGRAMAN

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 :

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

a.       Kelebihan pengujian “White Box”
1.     Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti. 
2.     Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki. 
3.     Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive.

b.      Kelemahan pengujian “White Box”
Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya


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

a.       Kelebihan black box testing :
1.      Spesifikasi program dapat ditentukan di awal
2.      Dapat digunakan untuk menilai konsistensi program
3.      Testing dilakukan berdasarkan spesifikasi
4.      Tidak perlu melihat kode program secara detail

b.      Kekurangan black box testing :
Bila spesifikasi program yang dibuat kurang jelas dan ringkas, maka akan sulit membuat dokumentasi setepat mungkin





 

ESTIMASI V-CLASS



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 tuagas yang akan diestimasik 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

JENIS JENIS COCOMO
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)Proyek yang dibangun dengan spesifikasi dan operasi yang ketat
Model COCOMO dasar ditunjukkan dalam persamaan 1, 2, dan 3 berikut ini:
keterangan
:
* E : besarnya usaha (orang-bulan)
* D : lama waktu pengerjaan (bulan)
* KLOC : estimasi jumlah baris kode (ribuan)
* P : jumlah orang yang diperlukan.

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

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