Analisis Awal dalam Rekayasa Perangkat Lunak

Analisis Awal dalam Rekayasa Perangkat Lunak

Rekomendasikan Artikel Artikel Komentar Cetak Artikel
Bagikan artikel ini di Facebook
Bagikan artikel ini di Twitter
Bagikan artikel ini di Linkedin
Bagikan artikel ini di Reddit
Bagikan artikel ini di Pinterest

Tujuan utama dari analisis awal dalam rekayasa perangkat lunak adalah untuk mengidentifikasi kebutuhan pelanggan, mengevaluasi konsep sistem untuk kelayakan, melakukan analisis ekonomi dan teknis, melakukan analisis biaya manfaat dan membuat definisi sistem yang membentuk dasar untuk semua pekerjaan rekayasa berikutnya.

Harus ada cukup keahlian yang tersedia untuk perangkat keras dan perangkat lunak untuk melakukan analisis.

Saat melakukan analisis, pertanyaan berikut muncul.

– Berapa banyak waktu yang harus dihabiskan untuk itu? Dengan demikian, tidak ada aturan atau formula yang tersedia untuk memutuskan hal ini. Namun, ukuran, kompleksitas, bidang aplikasi, penggunaan akhir, kewajiban kontrak adalah beberapa parameter yang harus diputuskan.

– Pertanyaan besar lainnya yang muncul adalah siapa yang harus melakukannya. Seorang analis terlatih yang berpengalaman harus melakukannya. Untuk proyek besar, bisa ada tim analisis.

Setelah analisis pendahuluan, analis harus melaporkan temuannya kepada manajemen, dengan rekomendasi yang menguraikan penerimaan atau penolakan proposal.

Awalnya ketika pelanggan membuat permintaan untuk suatu sistem, pelanggan itu sendiri tidak yakin tentang persyaratan sistem yang tepat. Untuk mengetahui apa sebenarnya yang diharapkan pelanggan dari sistem, analis secara pribadi bertemu dengan pengguna akhir atau pelanggan. Untuk analis ini harus sangat bijaksana dan memiliki keterampilan komunikasi yang baik sehingga ia dapat mengekstrak informasi yang maksimal dari pelanggan..

Dengan cara ini analis dapat mengetahui tentang kebutuhan yang tepat untuk sistem yang diinginkan. Semua informasi yang dikumpulkan selama periode identifikasi dicatat dalam Dokumen Konsep Sistem. Dokumentasi merupakan faktor yang sangat penting dalam rekayasa perangkat lunak.

Pengujian Perangkat Lunak Sebuah Primer Singkat

Apa itu Pengujian Perangkat Lunak?

Ada banyak definisi pengujian perangkat lunak yang diterbitkan, namun, semua definisi ini
intinya pada dasarnya sama: pengujian perangkat lunak adalah proses eksekusi
perangkat lunak secara terkendali, untuk menjawab pertanyaan “Apakah perangkat lunak”
berperilaku seperti yang ditentukan?”

Pengujian perangkat lunak sering digunakan dalam kaitannya dengan istilah verifikasi dan validasi.
Verifikasi adalah pemeriksaan atau pengujian item, termasuk perangkat lunak, untuk kesesuaian dan
konsistensi dengan spesifikasi terkait. Pengujian perangkat lunak hanyalah salah satu jenis
verifikasi, yang juga menggunakan teknik seperti tinjauan, analisis, inspeksi dan
penelusuran. Validasi adalah proses pengecekan bahwa apa yang telah ditentukan adalah apa yang
pengguna benar-benar ingin.

· Validasi: Apakah kita melakukan pekerjaan dengan benar?

· Verifikasi: Apakah kita melakukan pekerjaan dengan benar?

Istilah bug sering digunakan untuk merujuk pada masalah atau kesalahan pada komputer. Ada perangkat lunak
bug dan bug perangkat keras. Istilah ini berasal dari Amerika Serikat, pada saat
komputer perintis dibangun dari katup, ketika serangkaian yang sebelumnya tidak dapat dijelaskan
kesalahan akhirnya dilacak ke ngengat yang terbang di dalam komputer.

Pengujian perangkat lunak tidak boleh disamakan dengan debugging. Debugging adalah proses dari
menganalisis dan menemukan bug ketika perangkat lunak tidak berperilaku seperti yang diharapkan. walaupun
identifikasi beberapa bug akan terlihat jelas dari bermain dengan perangkat lunak, metode yang
pendekatan untuk pengujian perangkat lunak adalah cara yang jauh lebih menyeluruh untuk mengidentifikasi bug.

Oleh karena itu, debugging adalah aktivitas yang mendukung pengujian, tetapi tidak dapat menggantikan pengujian.
Namun, tidak ada jumlah pengujian yang dapat dijamin untuk menemukan semua bug.

Kegiatan lain yang sering dikaitkan dengan pengujian perangkat lunak adalah analisis statis dan
analisis dinamis. Analisis statis menyelidiki kode sumber perangkat lunak, mencari
masalah dan mengumpulkan metrik tanpa benar-benar mengeksekusi kode. Analisis dinamis
melihat perilaku perangkat lunak saat dijalankan, untuk memberikan informasi seperti:

4.2 Garis Besar

Rencana pengujian harus memiliki struktur berikut:

a) pengidentifikasi rencana pengujian;

b) Pendahuluan;

c) Butir tes;

d) Fitur yang akan diuji;

e) Fitur yang tidak akan diuji;

f) Pendekatan;

g) Kriteria lolos/gagal item;

h) Kriteria penangguhan dan persyaratan dimulainya kembali;

i) Hasil uji;

j) Tugas pengujian;

k) Kebutuhan lingkungan;

l) Tanggung jawab;

m) Kebutuhan staf dan pelatihan;

n) Jadwal;

o) Risiko dan kontinjensi;

p) Persetujuan.

Bagian harus dipesan dalam sp

Item tes

Identifikasi item tes termasuk versi/tingkat revisinya. Tentukan juga karakteristik transmisinya

media yang memengaruhi persyaratan perangkat keras atau menunjukkan perlunya transformasi logis atau fisik sebelum

pengujian dapat dimulai (misalnya, program harus ditransfer dari tape ke disk).

Berikan referensi ke dokumentasi item tes berikut, jika ada:

Spesifikasi persyaratan;

Spesifikasi desain;

Panduan pengguna;

Panduan operasi;

Petunjuk pemasangan.

Fitur yang akan diuji

Identifikasi semua fitur perangkat lunak dan kombinasi fitur perangkat lunak yang akan diuji. Identifikasi desain tes
spesifikasi yang terkait dengan setiap fitur dan setiap kombinasi fitur.

Fitur tidak untuk diuji

Identifikasi semua fitur dan kombinasi signifikan dari fitur yang tidak akan diuji dan alasannya.

Apa yang diperlukan untuk membangun Organisasi Tes terbaik.

Sikap

Pengakuan

Membunuh naluri untuk menggali dan memberikan

Budaya

Bekerjalah menuju gairah dan bukan uang

Bekerja menuju teknologi, berbagi, dan belajar

Kekuatan Etika

Apa yang kita lakukan:

Membangun silikon dengan arsitektur xyz.

memakai e-linux, membangun gambar dan kemudian meletakkan di atasnya.

Dukungan jaringan nirkabel diikuti dengan rilis.

Beberapa waktu yang menyenangkan:

1. Melaporkan semua kelulusan dan mengirim laporan tanpa benar-benar menjalankan tes. Produk mendapatkan bumerang dari tempat pelanggan. Industri tidak membiarkan kesalahan, dan yang ini bisa menjadi yang terburuk.

2.

Template:

Rencana Uji / Kasus Uji

Status Prioritas dan Keparahan serta pertukaran di antara keduanya: Pemetaan ke jargon Blocker dan Crasher kami.

Pemblokir Rilis: Keparahan Terakhir 1 tetapi prioritas pertama/BLOCKER (dari sudut pandang kami):

Contoh Kasus Ekstrim:

Adakah yang menemukan Produk Microsoft yang menentukan “Menang” alih-alih “Windows, tetapi Anda tidak akan dapat menemukannya. Mengapa, karena sebagai Penguji Anda mungkin mencatatnya sebagai tingkat keparahan terakhir, tetapi untuk Vendor/Microsoft itu menjadi prioritas 1/BLOCKER.

Test Blockers: Adalah kasus umum di mana Anda mencatat bug crash (Blocker), tetapi dianggap sebagai prioritas terakhir oleh manajemen. Mengapa???

Dalam salah satu contoh, vendor telah merilis versi OS, yang menetapkan bahwa setelah menginstal OS pada mesin baru, cabut kabel ke HDD dan OS akan macet dan tidak dapat dipulihkan sepenuhnya dan akan diperlukan untuk menginstal ulang seluruh OS lagi. Masih vendor yang dirilis, Mengapa? Karena vendor tidak akan mengharapkan pengguna akhir untuk melakukannya.

Pemrograman