Reliability
Software
adalah probabilitas software yang akan bekerja dengan baik dalam lingkungan
tertentu dan untuk jumlah waktu tertentu.
Menggunakan rumus berikut, kemungkinan
kegagalan dihitung dengan menguji sampel dari semua input yang tersedia.
Himpunan semua kemungkinan masukan
disebut ruang input. Untuk menemukan keandalan software, kita perlu menemukan
ruang output dari ruang input yang diberikan dan perangkat lunak.
Untuk uji reliabilitas, data yang
dikumpulkan dari berbagai tahap perkembangan, seperti desain dan operasi tahap.
Tes terbatas karena pembatasan seperti biaya dan waktu pembatasan.
Sampel statistik yang diperoleh dari
produk perangkat lunak untuk menguji keandalan perangkat lunak. Setelah data
atau informasi yang cukup dikumpulkan, studi statistik dilakukan.
Keterbatasan waktu ditangani dengan
menerapkan tanggal tetap atau batas waktu untuk tes yang akan dilakukan.
Setelah tahap ini, desain perangkat lunak dihentikan dan tahap implementasi
yang sebenarnya dimulai.
Karena ada pembatasan biaya dan waktu,
data dikumpulkan dengan hati-hati sehingga setiap data memiliki beberapa tujuan
dan mendapatkan presisi yang diharapkan. Untuk mencapai hasil yang memuaskan
dari pengujian kehandalan satu harus mengurus beberapa karakteristik keandalan.
Misalnya, Mean Time To Failure (MTTF)
diukur dari segi tiga faktor:
1.
Waktu
operasi,
2.
Jumlah
pada siklus off,
3.
dan
waktu kalender.
Jika pembatasan yang waktu operasi atau
jika fokusnya adalah pada poin pertama untuk perbaikan, maka salah satu dapat
menerapkan percepatan waktu dikompresi untuk mengurangi waktu pengujian. Jika
fokusnya adalah pada waktu kalender (yaitu jika ada tenggat waktu yang telah
ditetapkan), kemudian diintensifkan stress
testing digunakan.
Reliability
Software
Adalah probabilitas operasi perangkat
lunak bebas kegagalan untuk jangka waktu tertentu di lingkungan tertentu. Reability
software juga merupakan faktor penting yang mempengaruhi keandalan sistem. Ini
berbeda dari kehandalan hardware dalam hal itu mencerminkan kesempurnaan
desain, daripada manufaktur kesempurnaan. Kompleksitas tinggi perangkat lunak
adalah faktor utama dari masalah reliability software. Reliability software bukan
merupakan fungsi dari waktu meskipun peneliti telah menggunakan dua model yang
berkaitan. Teknik pemodelan untuk reliability software mencapai kesempurnaan,
tetapi sebelum menggunakan teknik, kita harus hati-hati memilih model yang baik
sesuai kasus kita. Pengukuran dalam perangkat lunak masih dalam masa
pertumbuhan. Tidak ada metode kuantitatif yang baik telah dikembangkan untuk
mewakili reliability software tanpa batasan yang berlebihan. Berbagai
pendekatan dapat digunakan untuk meningkatkan reliability software,
bagaimanapun, sulit untuk menyeimbangkan waktu pengembangan dan anggaran dengan
reliability software.
Mekanisme
Kegagalan Software
Kegagalan software mungkin karena
kesalahan, ambiguitas, kelalaian atau salah tafsir dari spesifikasi bahwa
perangkat lunak seharusnya memuaskan, kecerobohan atau ketidakmampuan dalam
menulis kode, pengujian tidak memadai, salah atau tak terduga penggunaan
perangkat lunak atau masalah yang tak terduga lainnya. [Keiller91]
Sementara itu tergoda untuk menarik
analogi antara reliability software dan reliability hardware, perangkat lunak
dan perangkat keras yang memiliki perbedaan mendasar yang membuat mereka
berbeda dalam mekanisme kegagalan. Kesalahan hardware sebagian besar kesalahan
fisik, sementara kesalahan perangkat lunak kesalahan desain, yang lebih sulit
untuk memvisualisasikan, mengklasifikasikan, mendeteksi, dan benar. [Lyu95]
Kesalahan desain berhubungan erat dengan
faktor kesalahan manusia dan proses desain, yang kita tidak memiliki pemahaman
yang kuat. Pada hardware, kesalahan desain mungkin juga ada, tapi kesalahan
fisik biasanya mendominasi. Dalam perangkat lunak, kita hampir tidak dapat
menemukan mitra yang ketat sesuai untuk "manufaktur" sebagai proses
manufaktur hardware, jika tindakan sederhana dari modul software upload ke
tempat tidak masuk hitungan. Oleh karena itu, kualitas perangkat lunak tidak
akan berubah setelah diupload ke dalam penyimpanan dan mulai berjalan. Mencoba
untuk mencapai keandalan yang lebih tinggi hanya dengan menduplikasi modul
perangkat lunak yang sama tidak akan bekerja, karena kesalahan desain tidak
bisa ditutupi dengan suara.
Daftar sebagian dari karakteristik yang
berbeda dari software dibandingkan dengan hardware tercantum di bawah ini
[Keene 94]:
·
Penyebab
kegagalan: cacat software terutama dirancang cacat.
·
Wear-out:
software tidak memiliki fase wear-out terkait energi. Kesalahan dapat terjadi
tanpa peringatan.
·
Konsep
sistem diperbaiki: restart periodik dapat membantu memperbaiki masalah
software.
·
Waktu
ketergantungan dan siklus hidup: reliability software bukan merupakan fungsi
dari waktu operasional.
·
Faktor
lingkungan: jangan mempengaruhi reliability software, kecuali mungkin
mempengaruhi input program.
·
Keandalan
prediksi: reliability software tidak dapat diprediksi dari setiap dasar fisik,
karena tergantung sepenuhnya pada faktor manusia dalam desain.
·
Redundansi:
tidak dapat meningkatkan kehandalan perangkat lunak jika komponen software identik
digunakan.
·
Antarmuka:
antarmuka software adalah murni konseptual selain visual.
·
Motivator
tingkat kegagalan: biasanya tidak dapat diprediksi dari analisis laporan
terpisah.
·
Dibangun
dengan komponen standar: dapat dipahami dan ekstensif diuji bagian standar akan
membantu meningkatkan pemeliharaan dan keandalan. Namun dalam industri
perangkat lunak, kami belum mengamati tren ini. Kode reuse telah ada selama
beberapa waktu, tetapi untuk tingkat yang sangat terbatas. Sebenarnya tidak ada
bagian standar untuk perangkat lunak, kecuali beberapa struktur logika standar.
Bathtub
kurva untuk Software Keandalan
Seiring waktu, hardware menunjukkan
karakteristik kegagalan yang ditunjukkan pada Gambar 1, dikenal sebagai kurva
bak mandi. Periode A, B dan C adalah singkatan dari burn-in fase, fase masa
manfaat dan tahap akhir dari hidup. Sebuah diskusi rinci tentang kurva dapat
ditemukan di topik keandalan tradisional.
Gambar 1. Kurva Bathtub untuk keandalan hardware
Kehandalan perangkat lunak,
bagaimanapun, tidak menunjukkan karakteristik yang sama seperti hardware. Kurva
mungkin ditunjukkan pada Gambar 2 jika kita proyeksikan keandalan software pada
sumbu yang sama. [RAC 96]
Ada dua perbedaan utama antara hardware
dan software kurva. Salah satu perbedaan adalah bahwa dalam tahap terakhir,
perangkat lunak tidak memiliki peningkatan tingkat kegagalan, hardware tidak.
Pada fase ini, software mendekati usang, tidak ada motivasi untuk upgrade atau
perubahan perangkat lunak. Oleh karena itu, tingkat kegagalan tidak akan
berubah. Perbedaan kedua adalah bahwa dalam tahap masa manfaat, perangkat lunak
akan mengalami peningkatan drastis tingkat kegagalan setiap kali upgrade dibuat.
Tingkat-tingkat kegagalan mati secara bertahap sebagian, karena cacat ditemukan
dan tetap setelah upgrade.
Gambar 2. Revisi kurva bak mandi untuk reliability
software
Upgrade pada Gambar 2 menyiratkan
upgrade fitur, tidak upgrade untuk keandalan. Untuk upgrade fitur, kompleksitas
software kemungkinan akan meningkat, karena fungsi dari software ditingkatkan.
Bahkan perbaikan kesalahan mungkin menjadi alasan untuk kegagalan perangkat
lunak yang lebih, jika bug fix menginduksi cacat lainnya ke dalam perangkat
lunak. Untuk upgrade keandalan, adalah mungkin untuk dikenakan penurunan
tingkat kegagalan software, jika tujuan dari upgrade ini meningkatkan keandalan
perangkat lunak, seperti desain ulang atau pelaksanaan ulang beberapa modul
menggunakan pendekatan rekayasa yang lebih baik, seperti metode ruang bersih.
Sebuah bukti dapat ditemukan dalam hasil
dari proyek Ballista, pengujian ketahanan komponen software off-the-rak. Gambar
3 menunjukkan hasil pengujian dari lima belas POSIX sistem operasi compliant.
Dari grafik kita melihat bahwa untuk QNX dan HP-UX, kenaikan tingkat kegagalan
ketahanan setelah upgrade. Tapi untuk SunOS, IRIX dan Digital UNIX, tingkat
kegagalan ketahanan tetes ketika nomor versi naik. Karena ketahanan software adalah
salah satu aspek kehandalan software, hasil ini menunjukkan bahwa upgrade dari
sistem-sistem yang ditunjukkan pada Gambar 3 harus dimasukkan upgrade
kehandalan.
Alat
yang tersedia, teknik, dan metrik
Sejak reliability software merupakan
salah satu aspek yang paling penting dari kualitas perangkat lunak, teknik
pendekatan keandalan dipraktekkan di lapangan perangkat lunak juga. Software
Reliability Engineering (SRE) adalah studi kuantitatif perilaku operasional
sistem software berbasis sehubungan dengan kebutuhan pengguna mengenai
keandalan [IEEE 95].
Model
Software Riliability
Sebuah proliferasi model keandalan
perangkat lunak telah muncul, sebagai orang mencoba untuk memahami
karakteristik bagaimana dan mengapa perangkat lunak gagal, dan mencoba untuk
mengukur keandalan perangkat lunak. Lebih dari 200 model telah dikembangkan
sejak awal 1970-an, tapi bagaimana mengukur keandalan software masih tetap
sebagian besar belum terpecahkan. Seperti banyak model yang ada dan banyak lagi
muncul, tak satu pun dari model dapat menangkap sejumlah memuaskan dari
kompleksitas perangkat lunak, kendala dan asumsi harus dibuat untuk proses
kuantitasnya. Oleh karena itu, tidak ada model tunggal yang dapat digunakan
dalam semua situasi. Ada model selesai atau bahkan perwakilan. Salah satu model
dapat bekerja dengan baik untuk satu set perangkat lunak tertentu, tetapi
mungkin benar-benar keluar jalur untuk jenis lain dari masalah.
Kebanyakan model perangkat lunak berisi
bagian-bagian berikut: asumsi, faktor, dan fungsi matematika yang berhubungan dengan
faktor keandalan. Fungsi matematika adalah agar biasanya lebih tinggi
eksponensial atau logaritmik.
Teknik pemodelan perangkat lunak dapat
dibagi menjadi dua subkategori: pemodelan prediksi dan pemodelan simulasi. [RAC
96]
Kedua jenis
teknik pemodelan didasarkan pada mengamati dan mengumpulkan data yang gagal dan
menganalisis dengan inferensi statistik. Perbedaan utama dari dua model
ditunjukkan pada Tabel 1.
|
MASALAH
|
MODEL
PREDIKSI
|
MODEL
ESTIMASI
|
|
DATA
REFERENSI
|
Menggunakan
data historis
|
Menggunakan
data dari upaya pengembangan perangkat lunak saat ini
|
|
SAAT
DIGUNAKAN DALAM SIKLUS PENGEMBANGAN
|
Biasanya
dilakukan sebelum pembangunan atau tes tahap; dapat digunakan sebagai awal
tahap konsep
|
Biasanya
dibuat kemudian dalam siklus hidup (setelah beberapa data telah dikumpulkan);
tidak biasanya digunakan dalam konsep fase pengembangan
|
|
JANGKA
WAKTU
|
Memprediksi
keandalan di beberapa waktu mendatang
|
Memperkirakan
kehandalan baik di saat ini atau beberapa waktu mendatang
|
Tabel 1. Perbedaan antara model prediksi keandalan
perangkat lunak dan model estimasi keandalan perangkat lunak
Model prediksi perwakilan termasuk Musa
Waktu Eksekusi Model, Putnam Model. dan model Roma Laboratorium TR-92-51 dan
TR-92-15, dll. Menggunakan model prediksi, keandalan software dapat diprediksi
di awal tahap pengembangan dan perangkat tambahan dapat dimulai untuk
meningkatkan keandalan.
Model estimasi perwakilan termasuk model
distribusi eksponensial, Weibull model distribusi, Model Thompson dan Chelson
ini, dll. Model Exponential dan model distribusi Weibull biasanya disebut
sebagai model estimasi tingkat hitungan kesalahan klasik / kesalahan, sedangkan
model Thompson dan Chelson ini miliki model estimasi tingkat kesalahan
Bayesian.
Lapangan telah matang ke titik bahwa
model perangkat lunak dapat diterapkan dalam situasi praktis dan memberikan
hasil yang berarti dan bahwa tidak ada satu model yang terbaik dalam segala
situasi. [Lyu95]
Karena kompleksitas dari software, model
apapun harus memiliki asumsi tambahan. Hanya faktor yang terbatas dapat
dimasukkan ke dalam pertimbangan. Kebanyakan model keandalan perangkat lunak
mengabaikan proses pengembangan perangkat lunak dan fokus pada hasil kesalahan
dan atau kegagalan diamati. Dengan demikian, kompleksitas berkurang dan
abstraksi dicapai, namun, model cenderung mengkhususkan diri untuk diterapkan
hanya sebagian dari situasi dan kelas tertentu dari masalah. Kita harus
hati-hati memilih model yang tepat yang sesuai dengan kasus tertentu. Selanjutnya,
hasil pemodelan tidak bisa dipercaya begitu saja dan diterapkan.
Software
Keandalan Metrik
Pengukuran adalah biasa dalam bidang
teknik lainnya, tetapi tidak dalam rekayasa perangkat lunak. Meskipun frustasi,
pencarian kuantifikasi keandalan software tidak pernah berhenti. Sampai
sekarang, kami masih memiliki cara yang baik untuk mengukur keandalan perangkat
lunak.
Mengukur keandalan perangkat lunak tetap
menjadi masalah yang sulit karena kita tidak memiliki pemahaman yang baik
tentang sifat perangkat lunak. Tidak ada definisi yang jelas untuk apa aspek
yang terkait dengan keandalan software. Kami tidak dapat menemukan cara yang
cocok untuk mengukur keandalan perangkat lunak, dan sebagian besar aspek yang
terkait dengan kehandalan software. Bahkan metrik produk yang paling jelas
seperti ukuran software memiliki definisi tidak seragam.
Hal ini menggoda untuk mengukur sesuatu
yang berhubungan dengan keandalan untuk mencerminkan karakteristik, jika kita
tidak bisa mengukur keandalan langsung. Praktik saat pengukuran keandalan
perangkat lunak dapat dibagi menjadi empat kategori: [RAC 96]
· Produk
Metrik
Ukuran software
dianggap mencerminkan kompleksitas, upaya pengembangan dan kehandalan. Line Of
Code (LOC), atau LOC dalam ribuan (KLOC), merupakan pendekatan awal intuitif
untuk mengukur ukuran perangkat lunak. Tapi tidak ada cara standar
penghitungan. Biasanya, kode sumber yang digunakan (SLOC, SLOC) dan komentar
dan pernyataan non-executable lainnya tidak dihitung. Metode ini tidak dapat
setia bandingkan software tidak ditulis dalam bahasa yang sama. Munculnya
teknologi baru kode reuse dan teknik generasi kode juga meragukan metode
sederhana ini.
Fungsi titik
metrik adalah metode mengukur fungsi dari pengembangan perangkat lunak yang
diusulkan berdasarkan hitungan input, output, file induk, pertanyaan, dan
interface. Metode ini dapat digunakan untuk memperkirakan ukuran sistem
perangkat lunak secepat fungsi-fungsi ini dapat diidentifikasi. Ini adalah
ukuran dari kompleksitas fungsional program. Ini mengukur fungsi dikirim ke
pengguna dan independen dari bahasa pemrograman. Hal ini digunakan terutama
untuk sistem bisnis, itu tidak terbukti dalam aplikasi ilmiah atau real-time.
Kompleksitas secara langsung
berhubungan dengan kehandalan perangkat lunak, sehingga mewakili kompleksitas
penting. Metrik kompleksitas berorientasi adalah metode penentuan kompleksitas
struktur kontrol program, dengan menyederhanakan kode menjadi representasi
grafis. Metrik perwakilan adalah McCabe Kompleksitas Metric.
Metrik cakupan tes adalah cara
memperkirakan kesalahan dan kehandalan dengan melakukan tes pada produk
software, didasarkan pada asumsi bahwa keandalan software merupakan fungsi dari
bagian perangkat lunak yang telah berhasil diverifikasi dan diuji. Diskusi
rinci tentang berbagai metode pengujian perangkat lunak dapat ditemukan dalam
topik Pengujian Perangkat Lunak.
· Metrik
manajemen proyek
Para peneliti
telah menyadari bahwa manajemen yang baik dapat menghasilkan produk yang lebih
baik. Penelitian telah menunjukkan bahwa ada hubungan antara proses pembangunan
dan kemampuan untuk menyelesaikan proyek tepat waktu dan sesuai sasaran mutu
yang diinginkan. Biaya meningkat ketika pengembang menggunakan proses yang
tidak memadai. keandalan yang lebih tinggi dapat dicapai dengan menggunakan
proses pembangunan yang lebih baik, proses manajemen risiko, proses manajemen
konfigurasi, dll.
· Metrik
proses
Berdasarkan
asumsi bahwa kualitas produk merupakan fungsi langsung dari proses, metrik
proses dapat digunakan untuk memperkirakan, memantau dan meningkatkan keandalan
dan kualitas perangkat lunak. ISO-9000, atau "standar manajemen
mutu", adalah referensi generik untuk keluarga standar yang dikembangkan
oleh Organisasi Standar Internasional (ISO).
· Kesalahan
dan kegagalan metrik
Tujuan dari
pengumpulan kesalahan dan kegagalan metrik adalah untuk dapat menentukan kapan
perangkat lunak mendekati eksekusi gagal bebas. Minimal, baik jumlah kesalahan
yang ditemukan selama pengujian (yaitu, sebelum pengiriman) dan kegagalan (atau
masalah lain) dilaporkan oleh pengguna setelah melahirkan dikumpulkan,
dirangkum dan dianalisa untuk mencapai tujuan ini. Strategi uji sangat relatif
terhadap efektivitas metrik kesalahan, karena jika skenario pengujian tidak
mencakup fungsionalitas penuh dari perangkat lunak, perangkat lunak dapat lulus
semua tes dan belum menjadi rentan terhadap kegagalan sekali disampaikan.
Biasanya, metrik kegagalan didasarkan pada informasi pelanggan mengenai
kegagalan ditemukan setelah rilis perangkat lunak. Data kegagalan yang dikumpulkan
oleh karena itu digunakan untuk menghitung kepadatan kegagalan, Mean Time
Between Failure (MTBF) atau parameter lain untuk mengukur atau memprediksi
keandalan perangkat lunak.
Software
Teknik Keandalan Perbaikan
Metode rekayasa yang baik sebagian besar
dapat meningkatkan keandalan perangkat lunak.
Sebelum penyebaran produk perangkat
lunak, pengujian, verifikasi dan validasi adalah langkah-langkah yang
diperlukan. Software pengujian sering digunakan untuk memicu, menemukan dan
menghapus cacat software. Software pengujian masih dalam tahap kecil tersebut,
pengujian ini dibuat untuk memenuhi kebutuhan spesifik dalam berbagai proyek
pengembangan perangkat lunak secara ad-hoc.
Berbagai alat analisis seperti analisis trend, analisis kesalahan-pohon,
klasifikasi cacat orthogonal dan metode formal, dll, juga dapat digunakan untuk
meminimalkan kemungkinan cacat terjadinya setelah rilis dan karena itu
meningkatkan keandalan perangkat lunak.
Setelah penyebaran produk perangkat
lunak, data lapangan dapat dikumpulkan dan dianalisa untuk mempelajari perilaku
cacat perangkat lunak. Toleransi kesalahan atau kesalahan / kegagalan peramalan
teknik akan teknik membantu dan aturan panduan untuk meminimalkan terjadinya
kesalahan atau dampak dari kesalahan pada sistem.
Hubungan dengan topik lain
Software reliability adalah bagian dari
kualitas perangkat lunak. Hal ini terkait dengan banyak daerah di mana kualitas
perangkat lunak yang bersangkutan.
· Tradisional /
Hardware Keandalan
Pencarian awal
dalam studi keandalan perangkat lunak didasarkan pada analogi keandalan
tradisional dan hardware. Banyak konsep dan metode analisis yang digunakan
dalam kehandalan tradisional dapat digunakan untuk menilai dan meningkatkan
keandalan perangkat lunak juga. Namun, keandalan perangkat lunak berfokus pada
desain kesempurnaan daripada manufaktur kesempurnaan, seperti kehandalan
tradisional / hardware tidak.
· Software Fault
Toleransi
Toleransi
kesalahan perangkat lunak adalah bagian penting dari sistem dengan keandalan
yang tinggi. Ini adalah cara menangani perangkat lunak yang tidak diketahui dan
tak terduga (dan hardware) kegagalan (kesalahan) [Lyu95], dengan menyediakan
satu set modul software fungsional setara dikembangkan oleh tim produksi yang
beragam dan independen. Asumsinya adalah keragaman desain perangkat lunak, yang
itu sendiri sulit dicapai.
· Pengujian
perangkat lunak
Software
pengujian berfungsi sebagai cara untuk mengukur dan meningkatkan kehandalan
perangkat lunak. Hal ini memainkan peran penting dalam desain, implementasi,
validasi dan rilis fase. Ini bukan bidang yang matang. Muka di bidang ini akan
memiliki dampak yang besar pada industri perangkat lunak.
· Sosial dan
kekhawatiran hukum
Sebagai
perangkat lunak menembus ke setiap sudut kehidupan kita sehari-hari, masalah
perangkat lunak terkait dan kualitas produk perangkat lunak dapat menyebabkan
masalah serius, seperti kecelakaan [Therac-25]. Cacat dalam perangkat lunak
secara signifikan berbeda dari yang di hardware dan komponen lain dari sistem,
mereka biasanya merancang cacat, dan banyak dari mereka terkait dengan masalah
dalam spesifikasi. Layak atau tidak layak sepenuhnya pengujian modul software
mempersulit masalah karena software bebas kerusakan tidak dapat dijamin untuk
sepotong cukup kompleks dari perangkat lunak. Tidak peduli seberapa keras kita
berusaha, produk software bebas cacat tidak dapat dicapai. Kerugian yang
disebabkan oleh cacat software menyebabkan kekhawatiran lebih dan sosial dan
hukum. Menjamin tidak ada cacat diketahui tentu bukan pendekatan yang cukup baik
untuk masalah.
Kesimpulan
Keandalan perangkat lunak adalah bagian
penting dalam kualitas perangkat lunak. Studi tentang kehandalan perangkat
lunak dapat dikategorikan menjadi tiga bagian: pemodelan, pengukuran dan
perbaikan. Software kehandalan modeling telah matang ke titik bahwa hasil yang
berarti dapat diperoleh dengan menerapkan model yang cocok untuk masalah ini. Ada
banyak model, tapi tidak ada model tunggal dapat menangkap jumlah yang
diperlukan karakteristik perangkat lunak. Asumsi dan abstraksi harus dilakukan
untuk menyederhanakan masalah. Tidak ada model tunggal yang bersifat universal
untuk semua situasi.
Pengukuran
software keandalan adalah naif. Pengukuran ini jauh dari biasa dalam perangkat
lunak, seperti dalam bidang teknik lainnya. "Seberapa baik perangkat
lunak, kuantitatif?" Sesederhana pertanyaannya adalah, masih belum ada
jawaban yang baik. Keandalan perangkat lunak tidak dapat diukur secara
langsung, sehingga faktor-faktor terkait lainnya diukur untuk memperkirakan
kehandalan perangkat lunak dan membandingkannya antara produk. proses
pembangunan, kesalahan dan kegagalan menemukan merupakan faktor-faktor yang
berhubungan dengan keandalan perangkat lunak.
Perbaikan
software kehandalan sulit. Sulitnya masalah berasal dari kurang memahami
keandalan software dan secara umum, karakteristik perangkat lunak. Sampai saat
ini belum ada cara yang baik untuk menaklukkan masalah kompleksitas perangkat
lunak. pengujian lengkap dari perangkat lunak modul cukup kompleks adalah tidak
layak. Produk perangkat lunak bebas cacat tidak dapat dijamin. Kendala waktu
yang realistis dan anggaran sangat membatasi upaya dimasukkan ke dalam
peningkatan keandalan perangkat lunak.
Karena
semakin banyak software yang merayap ke dalam sistem embedded, kita harus memastikan mereka tidak menanamkan bencana.
Jika tidak diperhatikan dengan cermat, keandalan perangkat lunak dapat menjadi
hambatan keandalan seluruh sistem. Memastikan keandalan perangkat lunak
bukanlah tugas yang mudah. Sekeras masalahnya adalah, kemajuan yang menjanjikan
masih sedang dibuat ke arah perangkat lunak yang lebih handal. Komponen standar
yang lebih dan proses yang lebih baik diperkenalkan dalam bidang rekayasa
perangkat lunak.
Diakses
dari sumber internet: https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability/
dan
terjemahan alamat asli dari: https://translate.google.co.id/
Tidak ada komentar:
Posting Komentar