Vclass Postest Estimasi (Peng Proyek Sistem Informasi)

Macam-macam COCOMO :

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

COCOMO berlaku untuk tiga kelas proyek perangkat lunak:

• Proyek Organik – “kecil” tim dengan “baik” pengalaman bekerja dengan “kurang kaku” persyaratan
• Proyek semi-terpisah – “menengah” tim dengan pengalaman bekerja dicampur dengan campuran kaku dan kurang dari kebutuhan kaku
• Proyek tertanam – dikembangkan dalam satu set “ketat” kendala. Hal ini juga kombinasi proyek organik dan semi-terpisah. ( Hardware, software, operasional ).

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

Dalam rinci COCOMO, upaya dihitung sebagai fungsi dari ukuran program yang dan satu set driver biaya yang diberikan sesuai dengan setiap fase siklus hidup perangkat lunak.

Vclass Estimasi Berdasarkan Sejarah (Peng Proyek Sistem Informasi)

Apa yang anda ketahui dengan estimasi berdasarkan sejarah

Menurut Kamus Besar Bahasa Indonesia (KBBI) Estimasi adalah perkiraan, penilaian atau pendapat. Estimasi adalah suatu metode dimana kita dapat memperkirakan nilai dari suatu populasi dengan menggunakan nilai dari sampel. Estimator adalah nilai pendugaan/suatu data statistik, sebagai sampel yang digunakan untuk mengisi suatu parameter.

            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.

Vclass Postest Pengelolaan Proyek Sistem Informasi

Pada fase pemograman ada tahapan uji. Sebutkan perbedaan dari uji secara black box dengan white box tahapan uji ! 

Perbedaan White Box & Black Box

·         White box (Struktural)

1.      Dilakukan oleh penguji yang mengetahui tentang QA.

2.      Melakukan testing pada software/program aplikasi menyangkut security dan performance program tersebut (meliputi tes code, desain implementasi, security, data flow, software failure).

3.      Dilakukan seiring dengan tahapan pengembangan software atau pada tahap testing.

·         Metode BlackBox  (Fungsional)

1.      Dilakukan oleh penguji Independent.

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

3.      Dilakukan setelah white box testing.

V Class Pretest Pengelolaan Proyek Sistem Informasi

LANGKAH-LANGKAH PEMROGRAMAN (THE PROGRAMMINGSTEPS)

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. Ini disebut disain modul. Disain modul adalah pendekatan top-down dimulai dengan kotak paling atas, AMST000 dan dipecah ke dalam sub-komponen yang tepat, Dan kemudian modul tersebut dipecah lagi sampai tercapai sebuah tingkatan dimana mulai dapat diprogram.

            Pertanyaan yang bisa diajukan adalah : “Pada tingkatan mana disain sistem berhenti dan disain modul dimulai ?”. Jawabannya adalah “Disain sistem dipecah sampai pada tingkat dimana programmer dapat memulainya”. Tingkatan ini dapat bermacam-macam dari proyek ke proyek dan bahkan dari satu bagian sistem ke bagian lainnya – tergantung pada programmer yang menerima bagian tersebut.

            Adapun pertimbangan lainnya adalah :

• Jika pemecahan modul yang dihasilkan adalah sangat penting yang memerlukan prioritas seperti adanya respon, user-friendly atau konsistensi, perancang bisa melanjutkan ke tingkat yang lebih rendah.

• Tingkat pemecahan dari disain dinyatakan dengan kontrak.

• Jika programmer tidak mengetahui pada waktu disain, pengetahuan programmer tingkat menengah dapat diasumsikan, dan disain dapat diambil alih oleh programmer tingkat menengah yang dapat mengatasinya.

            Tetapi perlu diingat bahwa programmer tidak senang menerima disain yang terlalu rinci, yang programnya adalah menerjemahkan bahasa Inggris yang sederhana, seperti pernyataan-pernyataan secara harafiah ke dalam bahasa pemrograman.

   

Langkah 3. Telusuri Disain Modul (WalkThrough The Module Design)

            Seperti pada tingkat atas dan menengah dari disain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. 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)

           

            Standar pengkodean akan ditetapkan pada saat disain sistem (lihat bagian 7.12). Kita tidak membahas bagaimana membuat program – lihat Referensi 12 (tulisan ini membahas disain sama baiknya dengan pemrograman) dan Referensi 13 untuk lebih jelasnya.

Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :

• Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya 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. Dokumen-dokumen berikut mungkin harus ditulis :

·         Tuntunan Pemakai (User’s Guide)

·         Tuntunan Pemeliharaan (Maintanance Guide)

·         Tuntunan Operator / Tuntunan Manajer Sistem (Operator’s Guide / System Manager’s Guide)

V-Class Bottom-up Testing

Soal:

Integration Testing (kel4)
1. Top-down test
2. Bottom-up test
3. Regression test

Kapan dan berikan contoh melakukan Bottom-up Test ?

Jawab:

Pengertian :

1.     Integrasi Top Down adalah sebuah pendekatan untuk pengujian terpadu dimana komponen tingkat terendah diuji terlebih dahulu,kemudian digunakan untuk memfasilitasi pengujian komponen tingkat yang lebih tinggi. Proses ini diulang sampai komponen di bagian atas hirarki diuji.

2.      Integrasi Bottom Up adalah sebuah pendekatan untuk pengujian terpadu dimana komponen tingkat terendah diuji terlebih dahulu, kemudian digunakan untuk memfasilitasi pengujian komponen tingkat yang lebih tinggi. Proses ini diulang sampai komponen di bagian atas hirarki diuji.

3.      Pengujian Regresi adalah menjalankan kembali beberapa subset pengujian yang telah dilakukan untuk meyakinkan bahwa perubahan punya efek samping yang diharapkan.

Pengujian Integrasi Bottom-up

Memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:

·       modul tingkat rendah digabung ke dalam cluster (build) yang melakukan subfungsi perangkat lunak spesifik.

·       Driver (program control untuk pengujian) ditulis untuk mengkoordinasi input dan output test case

·       cluster diuji

·       driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.

Contohnya, pendekatan top-down mungkin digunakan untuk menemukan sektor-sektor unggulan, kemudian untuk memilih saham-saham dalam sektor-sektor tersebut digunakan pendekatan bottom-up agar manajer investasi dapat menemukan saham-saham yang memiliki fundamental yang bagus dan valuasinya masih murah.

Sebaliknya, manajer investasi juga dapat memulai proses pemilihan saham dengan pendekatan bottom-up jika ia memang sudah memiliki sekumpulan saham yang ia nilai berpotensi. Dalam hal ini pendekatan bottom-up memungkinkannya untuk mencari manakah emiten yang paling atraktif - memiliki potensi terbesar untuk meraih pertumbuhan laba yang tinggi dalam beberapa tahun ke depan. Begitu emiten pilihan ditemukan, barulah manajer investasi mengaplikasikan pendekatan top-down untuk menentukan apakah emiten tersebut benar-benar diuntungkan dengan kondisi makroekonomi tertentu.

sumber : http://irdamentari.blogspot.co.id/2017/01/bottom-up-testing.html

Top-Down Integration Test

Soal :

Integration Testing

1. Top-down test

2. Bottom-up test

3. Regression test

Kapan dan contoh integration testing dilakukan top-down test ?

Jawaban:

Pengertian :

1.     Integrasi Top Down adalah sebuah pendekatan untuk pengujian terpadu dimana komponen tingkat terendah diuji terlebih dahulu,kemudian digunakan untuk memfasilitasi pengujian komponen tingkat yang lebih tinggi. Proses ini diulang sampai komponen di bagian atas hirarki diuji.

2.      Integrasi Bottom Up adalah sebuah pendekatan untuk pengujian terpadu dimana komponen tingkat terendah diuji terlebih dahulu, kemudian digunakan untuk memfasilitasi pengujian komponen tingkat yang lebih tinggi. Proses ini diulang sampai komponen di bagian atas hirarki diuji.

3.      Pengujian Regresi adalah menjalankan kembali beberapa subset pengujian yang telah dilakukan untuk meyakinkan bahwa perubahan punya efek samping yang diharapkan.

Pengujian integrasi top-down

·       Validasi arsitektural. Pengujian Top-Down lebih mungkin menemukan eror pada arsitektur sistem dan perancangan tingkat tinggi pada tahap awal proses pengembangan. Karena eror ini biasanya merupakan eror strukural, deteksi awal berarti eror tersebut dapat diperbaiki tanpa biaya tidak layak.

·       Demonstrasi sistem. Dengan pengembangan Top-Down, sistem yang dapat dipakai dan terbatas tersedia pada tahap awal pengembangan. Ini merupakan dorongan psikologi yang penting bagi yang terlibat dalam pengembangan sistem. Validasi sistem dapat dimulai secara dini pada proses pengujian karena sistem yang dapat didemonstrasikan dapat disediakan bagi user.

·       Implementasi uji. Pengujian Top-Down yang ketat sulit diimplementasi karena stub program ini mungkin berupa versi sederhana komponen yang dibutuhkan atau dapat meminta penguji untuk memasukkan nilai yang sesuai atau untuk mensimulasi kerja komponen.

·       Pengamatan uji. Baik baik pengujian bottom-up maupun top-down dapat memiliki masalah dengan pengamatan uji. Pada banyak sistem, tingkat-tingkat sistem yang lebih tinggi yang diimplementasikan pada awal proses top-down tidak menghasilkan hasil uji.

Rangkuman bab 3 dan bab 4 Buku Digital Forensik

Rangkuman bab 3 dan bab 4 Buku Digital Forensik

Disusun oleh :

Agus Dwi C

Fahmi Akbar K

Muhammad Azzohabi

Prayoga Pratama

Riyan Eka P

Bab 3 metode komputer forensic

Metode computer forensic adalah metode untuk computer forensic. Metode ini menjelaskan tentang langkah – langkah seperti pengumpulan pengujian analisis laporan.

Permodelan forensic ada 3 :

1.       Mausia 

2.       Peralatan

3.       Aturan

Ahli computer forensic disebut investigator. Infestigator memiliki 3 peran :

1.       Computer forensic examiner

2.       Computer investigator

3.       Digital evidence collection spesialis

Di antara ketiga komponen computer forensic, aturan (protocol) memegang peranan paling penting. Protokol ditetapkan sebagai aturan dalam menggali,mendapatkan,menganalisis,dan akhirnya menyajikan dalam laporan – laporan.

Ada 4 fase dalam computer forensic

1.       Pengumpulan

2.       Pengujian

3.       Analisis

4.       Laporan

Buku ini memberi contoh dari form yang digunakan pada computer forensic. Form form yang digunakan dirancang sangat sederhana dapat memuat beberapa item sekaligus dan tergantung pada kebutuhan dan kepentingan.

Bab 4 Standarisasi Komputer Forensik

Standar pada umumnya harus mendasari seluruh aktivitas dalam forensic, yaitu :

1.       Pendefinisian

2.       Prinsip kerja

3.       Proses dan metode

4.       Hasil

5.       Bahasa dan istilah

Komponen tersebut harus bisa menjawab masalah inkompatibilitas

1.       Bagaimana proses mendapatkan informasi?

2.       Apakah layak untuk mengambil terlebih dahulu lalu menganalisa bukti?

3.       Apakah layak dalam sisi hukum, etika, dan system informasi?

Standar kerja ada 5 faktor :

1.       Identifikasi objek

2.       Pemulihan computer

3.       Membangun mediasi komunikasi

4.       Permintaan investigasi

5.       Pengumpulan bukti digital lain.

Kebijakan dan prosedur

Ada 7 hal yg perlu dipertimbangkan dalam penerapan protocol :

1.       Personel

2.       Pertimbangan administrative

3.       Permintaan layanan

4.       Manajerial kasus

5.       Penanganan dan memberlakukan bukti

6.       Pemrosesan kasus

7.       Mengembangkan prosedur teknis

Menilai bukti

Factor yang menjadi pertimbangan untuk mengidentifikasi segalabukti yang dianalisis

1.       Menilai kasus

2.       Membuat penalaran di lokasi

3.       Analisis lokasi pemrosesan

4.       Pertimbangan hokum

5.       Analisis bukti

Kasus yang mengandalkan computer forensic

1.       Pornografi

2.       Sabotase layanan