Perkenalan
Pekerjaan ini dikhususkan untuk menjelaskan metode untuk mendeteksi dan menghilangkan kesalahan yang dapat meningkatkan kualitas secara signifikan perangkat lunak sistem tertanam dan menghemat sumber daya material dan waktu yang dihabiskan untuk debugging sistem. Metode yang dipertimbangkan dapat digunakan tanpa banyak kesulitan dalam mengembangkan berbagai macam proyek perangkat lunak sistem tertanam, dan akumulasi pengalaman sepenuhnya mempertahankan nilainya ketika mengimplementasikan proyek lain dan teknologi target. Selain itu, mereka memungkinkan untuk menjamin kemudahan pemeliharaan, modifikasi dan transfer program yang dibuat ke perangkat jenis baru. Singkatnya, teknik yang kita diskusikan tidak hanya memungkinkan Anda meningkatkan aplikasi tertanam dan proses pengembangan yang ada, namun juga memastikan bahwa seiring dengan berkembangnya perangkat tertanam baru, Anda sudah memiliki keahlian yang dibutuhkan untuk mengembangkan aplikasi berkinerja tinggi untuk teknologi ini, tepat waktu. dan sesuai anggaran.
Bukan rahasia lagi bahwa men-debug program untuk sistem tertanam sangatlah sulit. Debugging itu sendiri bukanlah suatu upaya, namun debugging perangkat lunak untuk sistem tertanam memerlukan hal yang sama persyaratan khusus. Pertama-tama, sangat sulit untuk mengekstrak informasi yang diperlukan dari sistem tertanam. Proses debugging biasanya didasarkan pada informasi yang dikeluarkan oleh aplikasi dan terkait masukan di pihak pemrogram, dan program sistem tertanam tidak memiliki kemampuan untuk mencetak gambar layar, yang dapat digunakan oleh pengembang perangkat lunak jenis lain.
Dari ini situasi yang tidak menyenangkan Aku harus keluar entah bagaimana caranya. Salah satu solusi yang mungkin menghubungkan peralatan khusus ke modul, yang merupakan seperangkat perangkat keras tempat perangkat lunak yang sedang di-debug ditulis. Perangkat keras khusus ini memberikan pengembang kemampuan untuk melihat apa yang terjadi dengan perangkat lunaknya. Misalnya, apa yang disebut monitor memori memungkinkan Anda menyimpan informasi di area memori terpisah, membaca isi memori ke dalam monitor, dan menggunakan isi memori monitor untuk menganalisis keadaan sistem pada saat sistem mogok. Selain itu, sistem tertanam dapat di-debug menggunakan sistem simulasi, yaitu lingkungan perangkat lunak, di mana program yang sedang di-debug dijalankan dengan cara yang sama seperti program tersebut akan dieksekusi sistem sasaran.
Sistem simulasi mempunyai banyak keuntungan. Mereka biasanya menyertakan debugger dan alat pencetakan, namun sistem pemodelan hanyalah simulator. Program yang sedang di-debug dapat berhasil dijalankan dalam sistem simulasi dan tidak dapat dioperasikan sepenuhnya kondisi nyata. Jadi sistem pemodelan itu adil solusi parsial. Kesalahan perangkat lunak mungkin melewati sistem pemodelan dan muncul peralatan nyata.
Di sinilah letaknya yang tersembunyi masalah utama: Seperti yang ditunjukkan pada gambar. 1, memperbaiki kesalahan yang teridentifikasi bukan pada tahap pengujian, tetapi selama penggunaan, jauh lebih mahal. Jika bug ditemukan dalam program untuk sistem yang tidak tertanam, maka Anda dapat melepaskannya versi yang diperbarui program dengan patch, biaya pembaruan tersebut biasanya relatif rendah. Jika ditemukan kesalahan pada sistem tertanam, maka untuk memperbaikinya perlu mengembalikan dan memodifikasi perangkat itu sendiri dengan sistem ini. Biaya pengembalian seperti itu dapat mencapai nilai yang sangat besar dan menyebabkan kehancuran perusahaan.

Beras. 1. Biaya menghilangkan kesalahan dalam sistem tertanam

Menurut pendapat saya, waktu dan biaya untuk mengidentifikasi dan memperbaiki kesalahan pada sistem tertanam kira-kira dua kali lipat (karena kesulitan yang dijelaskan di atas). Mengingat biaya yang sangat besar, metode apa pun yang dapat mencegah terjadinya kesalahan sangatlah berharga. Untungnya bagi pengembang tertanam, beberapa teknologi baru dapat digunakan untuk mencegah kesalahan pengembangan perangkat lunak. Dua yang paling direkomendasikan adalah standar pemrograman dan pengujian unit.
Benar, kedua metode ini saat ini tidak banyak digunakan dan dimuliakan. Hampir setiap pengembang perangkat lunak setuju dengan nilainya yang tinggi, namun hanya sedikit yang menggunakannya. Inkonsistensi ini dalam banyak kasus dijelaskan oleh dua alasan. Pertama-tama, banyak orang menganggap mengikuti standar pemrograman dan pengujian unit cukup membosankan. Mempertimbangkan berapa banyak waktu dan tenaga yang dapat dihemat oleh pendekatan ini di masa depan, pengembang sebaiknya memiliki sedikit kesabaran dan menghindari upaya dalam jumlah besar (dan kemungkinan ditinggalkannya proyek) di kemudian hari.
Pengembang sistem real-time memiliki waktu yang lebih sulit, karena mereka juga harus menangani masalah yang terkait dengan pemenuhan berbagai ketergantungan waktu. Di akhir artikel, kita akan melihat kesulitan yang dihadapi dalam men-debug sistem real-time dan memperkenalkan beberapa teknik debugging yang dirancang untuk mengatasi kesulitan ini dan juga dapat digunakan dalam pengembangan perangkat lunak apa pun.
Metode untuk men-debug program
Men-debug program terdiri dari memeriksa kebenaran pengoperasian program dan perangkat keras. Sebuah program yang tidak mengandung kesalahan sintaksis namun, ini mungkin mengandung kesalahan logis yang mencegah program menjalankan fungsi yang dimaksudkan. Kesalahan logika mungkin terkait dengan algoritma program atau kesalahpahaman tentang pengoperasian peralatan yang terhubung ke port mikrokontroler.
Debugger yang dibangun ke dalam lingkungan pemrograman terintegrasi memungkinkan Anda untuk men-debug bagian-bagian kode program yang tidak bergantung pada pengoperasian peralatan yang bukan bagian dari chip mikrokontroler. Hal ini biasanya mengacu pada evaluasi ekspresi matematika atau konversi format representasi data.
Tiga metode yang biasanya digunakan untuk men-debug program: Proses debug langkah demi langkah program dengan masuk ke subrutin; Debugging program selangkah demi selangkah dengan eksekusi subrutin sebagai operator tunggal; Jalankan program sampai breakpoint.
Debugging program langkah demi langkah terdiri dari mengeksekusi satu pernyataan program dan kemudian memantau variabel-variabel yang seharusnya terpengaruh oleh pernyataan ini.
Jika program telah men-debug subprogram, maka subprogram tersebut dapat dianggap sebagai satu pernyataan program dan menggunakan metode debug program yang kedua.
Jika suatu program berisi bagian program yang cukup besar yang telah di-debug sebelumnya, maka program tersebut dapat dijalankan tanpa mengontrol variabel yang terpengaruh. Menggunakan breakpoint memungkinkan Anda melewati bagian program yang sudah di-debug. Breakpoint diatur di tempat-tempat di mana perlu untuk memeriksa isi variabel atau sekadar memeriksa apakah kontrol telah ditransfer ke operator ini.
Hampir semua debugger mendukung properti ini (serta eksekusi program pada kursor dan keluar dari subrutin). Kemudian debugging program dilanjutkan mode langkah demi langkah dengan kontrol variabel lokal dan global, serta register internal mikrokontroler dan voltase pada pin sirkuit mikro ini. Ikuti standar pemrograman!

Cara terbaik untuk meningkatkan kualitas perangkat lunak adalah dengan mencoba menghindari kesalahan selama proses input teks sumber.
Langkah pertama untuk mencegah kesalahan adalah menyadari bahwa kesalahan memang bisa dicegah. Hambatan terbesar dalam pengendalian kesalahan adalah keyakinan umum bahwa kesalahan tidak bisa dihindari. Ini adalah suatu kekeliruan! Kesalahan tidak muncul dengan sendirinya; kesalahan dimasukkan ke dalam teks oleh pengembang. Melakukan kesalahan adalah hal yang manusiawi, bahkan yang paling manusiawi sekalipun programmer terbaik membuat kesalahan dari waktu ke waktu jika mereka memiliki kesempatan. Oleh karena itu, untuk mengurangi jumlah kesalahan, perlu dilakukan pengurangan kemungkinan terjadinya kesalahan. Salah satu cara terbaik di sini kepatuhan terhadap standar pemrograman, yang menghilangkan lahan subur terjadinya kesalahan pada tahap pertama.
Standar pemrograman adalah "aturan" khusus bahasa yang, jika diikuti, sangat mengurangi kemungkinan terjadinya kesalahan selama pengembangan aplikasi. Standar pemrograman harus diikuti pada tahap penulisan program, sebelum ditransfer ke platform target, dan standarisasi harus ada untuk semua bahasa. Karena sebagian besar pengembang sistem tertanam menggunakan bahasa C, kami akan lebih memperhatikan standar pemrograman C, meskipun standar yang sama juga berlaku untuk bahasa lain, termasuk C++ dan Java.
Biasanya, standar pemrograman terbagi dalam dua kategori:
standar pemrograman industri: aturan yang diterima oleh semua pemrogram bahasa yang diberikan(misalnya, melarang masuk ke dalam loop tidak melalui headernya).
standar pemrograman khusus: aturan diikuti kelompok tertentu pengembang, dalam proyek tertentu, atau bahkan sebagai pemrogram tunggal. Ada tiga jenis standar khusus, yang dapat digunakan oleh pengembang tersemat sistem perangkat lunak: standar internal, standar pribadi, dan standar yang ditentukan oleh platform target.
Standar pemrograman internal adalah aturan yang khusus untuk organisasi atau tim pengembangan Anda. Dengan demikian, aturan penamaan yang unik untuk suatu organisasi adalah contoh standar pemrograman internal.
Standar pribadi ini adalah aturan yang akan sangat membantu Anda menghindarinya kesalahan umum. Setiap kali kesalahan terjadi, pemrogram harus menganalisis alasan terjadinya kesalahan tersebut dan mengembangkan aturannya sendiri untuk mencegah terulangnya kesalahan tersebut. Misalnya, jika Anda sering menulis tanda penugasan dan bukannya tanda centang kesetaraan dalam pernyataan kondisional (yaitu, "jika (a=b)" dan bukannya "jika (a= =b)"), maka Anda perlu membuat standar berikut untuk diri Anda sendiri: "Hati-hati menggunakan tanda tugas dalam pernyataan bersyarat."
Standar yang ditentukan oleh platform target adalah aturan yang, jika dilanggar, pada platform tertentu dapat mengakibatkan munculnya masalah tertentu. Misalnya, standar tersebut dapat berupa penggunaan memori atau batasan ukuran variabel yang diberlakukan oleh platform target.
Untuk lebih memahami apa itu standar pemrograman dan cara kerjanya, mari mengenalnya di contoh spesifik. Perhatikan notasi berikut dalam C:
{
.
.
.
}
Di sini, ukuran array satu dimensi dideklarasikan dalam daftar argumen fungsi. Ini adalah konstruksi yang berbahaya karena dalam C argumen array diteruskan sebagai penunjuk ke elemen pertamanya, dan panggilan yang berbeda ke fungsi tersebut mungkin menyertakan array dengan ukuran berbeda di antara argumen sebenarnya. Setelah membuat konstruksi seperti itu, Anda berharap menggunakan buffer ukuran tetap untuk 80 elemen, mengingat buffer inilah yang akan diteruskan ke fungsi, dan ini dapat menyebabkan kerusakan memori. Jika penulis pernyataan ini mengikuti standar pemrograman "jangan menyatakan ukuran array satu dimensi sebagai argumen fungsi" (diambil dari seperangkat standar pemrograman C dari salah satu perusahaan telekomunikasi terkemuka), maka teks ini akan terlihat seperti ini dan masalah kerusakan memori dapat dihindari:
karakter *substring ( string karakter, int start_pos, int panjang)
{
.
.
.
}
Standar pemrograman juga memungkinkan Anda menghindari masalah yang mungkin tidak muncul hingga kode di-porting ke platform lain. Misalnya, potongan kode berikut akan berfungsi dengan baik pada beberapa platform tetapi akan menghasilkan kesalahan saat dipindahkan ke platform lain:
#termasuk
tes batal (karakter c) (
jika(sebuah<= c && c <= z) { // Неправильно
}
if(islower(c)) (// Benar
}
sementara (A<= c && c <= Z) { // Неправильно
}
while (isupper(c)) ( // Benar
}
}
Masalah portasi mungkin terkait dengan pengujian simbolik yang tidak menggunakan fungsi ctype.h (isalnum, isalpha, iscntrl, isdigit, isgraph, islower, isprint, ispunct, isspace, isupper, isxdigit, tolower, toupper). Fungsi ctype.h untuk memeriksa karakter dan mengubah huruf besar menjadi huruf kecil dan sebaliknya bekerja dengan berbagai macam rangkaian karakter, biasanya sangat efisien, dan memastikan penerapan produk perangkat lunak secara internasional.
Cara terbaik untuk menerapkan standar ini dan standar pemrograman lainnya adalah dengan menerapkannya secara otomatis sebagai bagian dari teknologi pemrograman, bersama dengan serangkaian standar industri yang terfokus dan mekanisme untuk menciptakan dan memelihara standar pemrograman sistem yang spesifik. Saat memilih teknologi seperti itu, Anda harus terlebih dahulu menemukan jawaban atas pertanyaan-pertanyaan, antara lain sebagai berikut:
Apakah ini berlaku untuk program dan/atau kompiler ini?
Apakah berisi seperangkat standar pemrograman industri?
Apakah ini memungkinkan Anda membuat dan memelihara standar pemrograman khusus (termasuk yang ditentukan oleh platform target)?
Apakah mudah untuk menyusun laporan sesuai dengan tim dan prioritas proyek Anda?
Seberapa mudahkah hal ini diintegrasikan ke dalam proses pengembangan Anda saat ini?
Pengujian satuan

Seringkali, ketika pengembang mendengar tentang pengujian unit, mereka menganggapnya identik dengan pengujian unit. Dengan kata lain, ketika menguji satu modul atau subrutin dari unit perangkat lunak yang lebih besar, pengembang yakin bahwa mereka sedang melakukan pengujian unit. Tentu saja, pengujian unit sangat penting dan harus dilakukan, tetapi ini bukanlah metode yang ingin saya fokuskan. Ketika saya berbicara tentang "pengujian unit", yang saya maksud adalah pengujian pada tingkat yang lebih rendah lagi: menguji unit program sekecil mungkin yang membentuk program aplikasi, saat masih berada di lingkungan host (sistem host) dalam kasus C, ini akan be fungsi , yang diperiksa segera setelah dikompilasi.
Pengujian unit secara signifikan meningkatkan kualitas perangkat lunak dan efisiensi proses pengembangan. Saat menguji pada tingkat objek, Anda lebih dekat dengan teknik ini dan memiliki kemampuan yang jauh lebih besar untuk membangun kumpulan masukan yang mendeteksi kesalahan dengan cakupan 100% (Gambar 2). Selain itu, dengan menguji blok kode segera setelah ditulis, Anda menghindari keharusan melewati lapisan kesalahan untuk menemukan dan memperbaiki satu-satunya yang asli, dalam hal ini, Anda segera menghilangkannya, dan seluruh masalah terpecahkan . Hal ini secara signifikan mempercepat dan memfasilitasi proses pengembangan, karena lebih sedikit sumber daya material dan waktu yang dihabiskan untuk menemukan dan menghilangkan kesalahan.

Beras. 2. Kemudahan menemukan kesalahan pada saat pengujian unit

Pengujian unit dapat dibagi menjadi setidaknya dua proses terpisah. Yang pertama adalah pengujian black box, atau proses mengidentifikasi masalah fungsional. Pada tingkat blok, pengujian kotak hitam terdiri dari verifikasi karakteristik fungsional dengan menentukan sejauh mana parameter antarmuka terbuka suatu fungsi sesuai dengan spesifikasinya; pemeriksaan tersebut dilakukan tanpa memperhitungkan metode pelaksanaannya. Hasil dari pengujian black box pada tingkat blok adalah keyakinan bahwa suatu fungsi tertentu berperilaku persis seperti yang didefinisikan dan bahwa kesalahan fungsional kecil tidak akan menyebabkan banyak masalah yang sulit diselesaikan.

Beras. 3. Pengujian kotak hitam

Proses kedua disebut pengujian kotak putih dan dirancang untuk mengidentifikasi kelemahan desain. Pada tingkat blok individual, diperiksa apakah seluruh program akan crash ketika meneruskan parameter yang tidak terduga ke fungsi. Jenis pengujian ini harus dilakukan oleh seorang spesialis yang memiliki pemahaman lengkap tentang bagaimana fungsi yang diuji diterapkan. Setelah pemeriksaan seperti itu, Anda dapat yakin bahwa tidak ada kesalahan yang menyebabkan kegagalan sistem dan bahwa fungsi tersebut akan bekerja secara stabil dalam kondisi apa pun (yaitu, memberikan hasil yang dapat diprediksi bahkan ketika parameter input yang tidak terduga dimasukkan).

Beras. 4. Pengujian kotak putih

Kedua proses di atas dapat menjadi dasar untuk pengujian regresi yang ketiga. Dengan menyimpan kasus pengujian kotak hitam dan kotak putih, Anda dapat menggunakannya untuk pengujian regresi tingkat blok dan memantau integritas kode saat Anda memodifikasinya. Konsep pengujian regresi pada level ini merupakan pendekatan baru dan orisinal. Saat Anda melakukan pengujian regresi pada tingkat blok, Anda dapat menentukan apakah masalah baru muncul segera setelah Anda mengubah teks dan memperbaikinya segera setelah terjadi, sehingga mencegah kesalahan menyebar ke tingkat yang lebih tinggi.
Masalah utama dengan pengujian unit adalah jika teknik pengujian unit otomatis tidak digunakan, pengujian tersebut akan sulit, membosankan, dan memakan waktu. Mari kita lihat sekilas alasan mengapa sulit (jika bukan tidak mungkin) untuk memasukkan pengujian unit manual ke dalam proses pengembangan saat ini.
Tahap pertama pengujian unit perangkat lunak sistem tertanam adalah menciptakan lingkungan yang memungkinkan fungsi yang diinginkan dijalankan dan diuji pada sistem host. Ini memerlukan dua langkah berikut:
pengembangan teks program yang akan menjalankan fungsi,
menulis modul tiruan yang akan mengembalikan hasil, bukan sumber daya eksternal yang diakses oleh fungsi yang saat ini hilang atau tidak dapat diakses.
Tahap kedua adalah pengembangan alat tes. Untuk sepenuhnya mencakup desain dan fitur fungsional suatu fungsi, perlu dibuat dua jenis set pengujian: untuk "kotak hitam" dan untuk "kotak putih".
Dasar untuk mengembangkan kasus uji black box haruslah spesifikasi fungsi. Secara khusus, setidaknya satu kasus uji harus dibuat untuk setiap entri dalam spesifikasi, dan diharapkan bahwa kumpulan ini memperhitungkan kondisi batas yang ditentukan dalam spesifikasi. Tidaklah cukup hanya memeriksa apakah beberapa masukan memberikan hasil yang diharapkan; perlu untuk menentukan rentang hubungan antara input dan output, yang memungkinkan kita menarik kesimpulan tentang implementasi yang benar dari karakteristik fungsional yang ditentukan, dan kemudian membuat set pengujian yang sepenuhnya mencakup rentang ini. Anda juga dapat menguji kondisi di luar spesifikasi dan kondisi yang salah.
Tujuan dari kasus uji kotak putih adalah untuk mendeteksi semua cacat tersembunyi dengan menguji fungsi secara ekstensif dengan berbagai parameter masukan. Kit ini harus memiliki kemampuan berikut:
memberikan cakupan fungsi setinggi mungkin (100%): seperti yang telah disebutkan, tingkat cakupan pada tingkat blok ini dimungkinkan karena lebih mudah untuk membuat rangkaian pengujian untuk setiap karakteristik fungsi di luar aplikasi (cakupan 100% tidak mungkin dilakukan dalam semua kasus, namun ini adalah tujuan yang harus diperjuangkan);
mengidentifikasi kondisi kegagalan fungsi.
Perlu dicatat bahwa membuat perangkat seperti itu sendiri, tanpa mengetahui teknologi konstruksinya, adalah tugas yang sangat sulit. Untuk membuat kasus pengujian kotak putih yang efektif, pertama-tama Anda harus memperoleh pemahaman lengkap tentang struktur internal fungsi, menulis kasus pengujian yang memberikan cakupan fungsi maksimum, dan menemukan kumpulan masukan yang menyebabkan fungsi gagal. Mendapatkan cakupan yang diperlukan untuk pengujian white-box berkinerja tinggi hanya mungkin dilakukan dengan memeriksa sejumlah besar jalur melalui fungsi tersebut. Misalnya, dalam program tipikal yang terdiri dari 10.000 pernyataan, terdapat sekitar seratus juta kemungkinan jalur traversal; Tidak mungkin membuat kasus uji secara manual untuk menguji semua jalur ini.
Setelah membuat kasus uji, perlu dilakukan pengujian fungsi secara menyeluruh dan menganalisis hasilnya untuk mengidentifikasi penyebab kesalahan, kerusakan, dan kelemahan. Anda harus mempunyai cara untuk menjalankan semua kasus pengujian dan dengan cepat menentukan kasus mana yang menyebabkan masalah. Alat pengukuran cakupan juga diperlukan untuk mengevaluasi kelengkapan pengujian fitur dan menentukan kebutuhan rangkaian pengujian tambahan.
Setiap kali suatu fitur berubah, pengujian regresi harus dilakukan untuk memastikan bahwa tidak ada bug baru dan/atau bug sebelumnya telah teratasi. Menyertakan pengujian regresi blok dalam proses pengembangan akan melindungi dari banyak kesalahan yang akan terdeteksi segera setelah terjadi dan tidak akan menyebabkan kesalahan menyebar ke seluruh aplikasi;
Pengujian regresi dapat dilakukan dengan dua cara. Yang pertama adalah pengembang atau penguji menganalisis setiap kasus pengujian dan menentukan kasus mana yang mungkin terpengaruh oleh perubahan kode. Pendekatan ini ditandai dengan penghematan waktu mesin dengan mengorbankan tenaga manusia. Yang kedua, yang lebih efektif, adalah menjalankan semua set pengujian di komputer secara otomatis setelah setiap perubahan teks. Pendekatan ini menjamin efisiensi yang lebih besar bagi pengembang, karena ia tidak perlu menghabiskan waktu menganalisis seluruh rangkaian kasus uji untuk menentukan rangkaian mana yang harus dijalankan dan mana yang tidak.
Jika Anda dapat mengotomatiskan proses pengujian unit, Anda tidak hanya akan meningkatkan kualitas pengujian, tetapi juga membebaskan lebih banyak waktu dan sumber daya material secara signifikan daripada yang akan dihabiskan untuk proses ini. Jika Anda menulis program dalam C, Anda dapat menggunakan teknologi yang ada untuk mengotomatiskan pengujian unit. Semakin banyak proses yang dapat Anda otomatisasi, semakin banyak manfaat yang akan Anda terima.
Saat memilih teknologi pengujian unit, Anda harus menjawab pertanyaan berikut terlebih dahulu:
Apakah teknologi ini cocok untuk teks dan/atau kompiler Anda?
Bisakah secara otomatis menghasilkan rangkaian uji?
Bisakah secara otomatis menghasilkan kasus uji?
Apakah ini mengizinkan pengenalan kasus uji dan modul tiruan yang dibuat pengguna?
Apakah pengujian regresi dilakukan secara otomatis?
Apakah ini menyertakan atau menghubungkan ke teknologi untuk mengenali kesalahan secara otomatis selama pengoperasian?
Alat debugging yang tidak mengubah mode operasi program

Karena sistem operasi real-time harus melakukan tugas-tugas tertentu di bawah batasan waktu yang telah ditentukan, pengaturan waktu menjadi parameter penting yang harus dipertimbangkan pengembang saat menyiapkan perangkat lunak pengujian. Biasanya, banyak interupsi berbeda terjadi selama eksekusi program, dan sangat penting bagi aplikasi untuk merespons dengan benar ketika interupsi terjadi. Situasi menjadi lebih rumit ketika beberapa interupsi terjadi secara bersamaan atau ketika sistem menjalankan banyak aplikasi dengan banyak thread yang berinteraksi satu sama lain. Pada dasarnya, ini adalah aplikasi dengan beberapa jalur eksekusi simultan; urutan kode berbeda tampaknya dijalankan pada waktu yang sama, meskipun hanya ada satu prosesor pusat dalam sistem. Menarik untuk dicatat bahwa jika aplikasi ini berjalan pada banyak prosesor, maka thread yang berbeda dalam praktiknya akan dimuat pada prosesor yang berbeda.
Jika kesalahan yang ditemui dalam aplikasi real-time terjadi dalam interaksi antara program dan interupsi, kesalahan tersebut akan sangat sensitif terhadap waktu. Dalam hal ini, penting untuk mencatat urutan terjadinya kesalahan, karena ini akan memungkinkan Anda memahami sebab dan akibat dari setiap kesalahan. Inilah masalah utama dalam men-debug sistem waktu nyata: terdapat cukup banyak kesalahan yang sulit dideteksi yang hanya muncul pada hubungan waktu tertentu.
Masalah ini diperumit oleh kenyataan bahwa kesalahan tersebut tidak mudah direproduksi. Sangat sulit untuk menciptakan kembali situasi dengan hubungan waktu yang sama yang menyebabkan kesalahan dalam program sebenarnya. Mekanisme untuk men-debug aplikasi semacam itu harus selembut mungkin. Intervensi apa pun dalam pelaksanaan program dapat menyebabkan perubahan karakteristik waktunya dan tidak adanya kondisi kesalahan. Tentu saja, menciptakan kondisi di mana kesalahan tidak terjadi adalah hal yang baik, tetapi dalam hal ini merupakan hambatan untuk melakukan debug program.
Landasan teoretis untuk masalah debugging sistem waktu nyata adalah prinsip ketidakpastian fisikawan Jerman Werner Heisenberg, yang diketahui semua orang dari kursus fisika, yang menurutnya tidak mungkin menentukan kecepatan dan lokasi partikel bergerak secara bersamaan. Heisenberg percaya bahwa dengan menentukan koordinat suatu partikel, pelaku eksperimen mengubah lokasinya, sehingga koordinatnya tidak dapat ditentukan secara akurat. Operasi pengukuran mempengaruhi objek yang diukur dan merusak hasil pengukuran. Prinsip ketidakpastian adalah salah satu aksioma mekanika kuantum.
Sebagaimana diterapkan pada topik kita, prinsip ini berarti bahwa proses debug suatu sistem memerlukan pengumpulan informasi tentang statusnya. Namun, pengumpulan informasi tentang keadaan sistem mengubah karakteristik waktunya dan membuatnya lebih sulit untuk mereproduksi kondisi kesalahan secara andal.
Jadi, inti dari masalah ini adalah kita perlu menemukan cara untuk mendeteksi kesalahan waktu nyata dan menganalisis perilaku program tanpa mempengaruhi hubungan waktu yang ada. Naluri pertama Anda mungkin adalah beralih ke debugger, tetapi debugger cenderung mengganggu eksekusi program dan, karenanya, mengubah karakteristik waktunya. Sistem simulasi juga tidak banyak berguna, karena tidak dapat menciptakan kembali karakteristik waktu dari sarana teknis yang sebenarnya. Belum ada yang menciptakan sistem simulasi yang dapat melakukan simulasi secara real time; parameter sementara hanya dapat ditentukan dengan memuat program ke dalam perangkat keras itu sendiri.
Yang terakhir ini memerlukan mekanisme khusus untuk menyederhanakan pencatatan status sistem. Salah satu mekanisme yang mungkin dan cocok adalah menulis informasi ke dalam RAM, karena operasi semacam itu dilakukan dengan sangat cepat. Salah satu cara untuk menggunakan mekanisme ini adalah dengan mengatur buffer khusus di suatu tempat di memori dan menggunakan pointer ke buffer ini di program Anda. Pointer selalu menunjuk ke awal buffer. Program menyisipkan operasi tulis ke dalam sel yang diidentifikasi oleh penunjuk. Setelah setiap operasi penulisan, nilai penunjuk akan berubah. Terkadang berguna untuk menggunakan buffer cincin (yaitu, setelah menulis ke sel terakhir buffer, penunjuk mulai menunjuk ke awal buffer), yang memungkinkan Anda melacak situasi yang menyebabkan masalah. Penting untuk menyediakan cara untuk menyimpan konten buffer setelah penghentian program secara normal atau tidak normal, untuk kemudian memiliki akses ke sana dan melakukan apa yang disebut "debugging post-mortem". Metode implementasi tergantung pada perangkat kerasnya, tetapi biasanya dapat dilakukan tanpa menginisialisasi ulang perangkat keras.
Sekarang Anda memerlukan mekanisme untuk membaca memori ini. Di sini Anda dapat menggunakan debugger dan cara lain untuk mengekstrak informasi dari RAM. Secara khusus, Anda dapat menulis program sederhana yang akan mengirimkan data ini ke file atau ke printer. Alat apa pun yang Anda gunakan, langkah terakhir kemungkinan besar adalah analisis manual terhadap konten buffer. Jika buffer Anda adalah buffer cincin, maka Anda harus memiliki pengetahuan yang tepat tentang nilai penunjuk; peristiwa yang memulai urutan akan terjadi tepat sebelum penunjuk, peristiwa yang terjadi tepat sebelum kerusakan akan terjadi segera setelah penunjuk.

Beras. 5. Urutan kejadian di ring buffer

Sekarang tugas utama Anda adalah mencoba memahami urutan data yang ditulis dalam buffer. Tugas ini mirip dengan mempelajari penyebab kecelakaan pesawat menggunakan pembacaan instrumen yang dicatat oleh “kotak hitam” pesawat. Dalam hal ini, analisis karakteristik program dilakukan setelah kejadian terjadi, yang tentu saja memiliki dampak yang jauh lebih kecil terhadap pelaksanaannya dibandingkan pemantauan selama operasi.
Terkadang sangat sulit untuk merekonstruksi peristiwa yang menyebabkan kecelakaan itu, dan tidak ada gambaran yang jelas kapan kesalahan itu terjadi. Diperlukan waktu berbulan-bulan hanya untuk mengetahui penyebab kesalahan tersebut. Dalam kasus seperti itu, Anda dapat menggunakan metode debugging logaritmik untuk menemukan pernyataan yang salah. Di berbagai tempat kode yang sedang di-debug, penanda ditempatkan (misalnya, operator seperti exit), dan di depannya adalah operator penulisan memori. Kemudian Anda menjalankan program dan menunggu saat crash. Jika terjadi kecelakaan, Anda tahu di antara penanda mana kecelakaan itu terjadi. Metode ini juga dapat mengidentifikasi masalah timing karena dapat menemukan segmen kode dimana terjadi pelanggaran timing.
Solusi lain adalah dengan menggunakan apa yang disebut firewall sebagai teknologi debugging. Firewall adalah suatu titik dalam aliran logis suatu program di mana validitas asumsi yang menjadi sandaran kode berikutnya terbukti. Pengecekan asumsi ini berbeda dengan pengecekan kesalahan biasa. Aktivasi firewall merupakan sinyal bagi pengembang bahwa keadaan internal sistem tidak stabil. Hal ini dapat terjadi, misalnya, jika suatu fungsi yang mengharapkan argumen positif menerima nilai nol atau negatif. Bagi pengembang yang tidak berpengalaman, sebagian besar firewall tampak sepele dan tidak diperlukan. Namun, pengalaman mengembangkan proyek besar menunjukkan bahwa seiring dengan berkembang dan membaiknya sistem perangkat lunak, asumsi implisit mengenai lingkungan eksekusi semakin sering dilanggar. Dalam banyak kasus, bahkan penulis sendiri merasa kesulitan untuk merumuskan kondisi yang tepat untuk mengeksekusi bagian kode tertentu.
Firewall yang diterapkan di dalam sistem tertanam memerlukan sarana komunikasi khusus untuk mengirimkan pesan ke dunia luar; diskusi tentang cara membangun saluran transmisi tersebut berada di luar cakupan artikel ini.
Kesimpulan

Metode pencegahan dan deteksi kesalahan yang dibahas di atas, serta teknologi debugging, dapat secara signifikan meningkatkan kualitas perangkat lunak sistem tertanam dan mengurangi sumber daya material dan waktu yang dihabiskan untuk debugging. Metode di atas dapat dengan mudah digunakan dalam pengembangan berbagai macam proyek perangkat lunak sistem tertanam, dan akumulasi pengalaman sepenuhnya mempertahankan nilainya ketika mengimplementasikan proyek lain dan teknologi target. Selain itu, mereka memungkinkan untuk menjamin kemudahan pemeliharaan, modifikasi dan porting program yang dibuat ke perangkat jenis baru. Singkatnya, teknik yang kami bahas tidak hanya memungkinkan Anda meningkatkan aplikasi tertanam dan proses pengembangan yang sudah ada, namun juga memastikan bahwa seiring dengan berkembangnya perangkat tertanam baru, Anda sudah memiliki keahlian yang diperlukan untuk mengembangkan aplikasi berkinerja tinggi untuk teknologi ini tepat waktu dan tepat waktu. waktu. anggaran.
Literatur

1. M. Aivazis dan W. Hicken. "Pemrograman Defensif C++: Firewall dan Informasi Debugging." Laporan C++ (Juli-Agustus 1999): 34 40.

Klasifikasi kesalahan perangkat lunak

Mari kita perhatikan klasifikasi kesalahan menurut tempat terjadinya, yang dibahas dalam buku “Software Testing” karya S. Kaner. Konsep dasar manajemen aplikasi bisnis. . Kriteria utama suatu program adalah kualitasnya, yang diartikan sebagai tidak adanya kekurangan, serta kegagalan dan kesalahan yang nyata. Kerugian dari program ini bergantung pada penilaian subjektif terhadap kualitasnya oleh calon pengguna. Pada saat yang sama, penulis skeptis terhadap spesifikasi tersebut dan berpendapat bahwa meskipun ada, kekurangan yang diidentifikasi pada tahap akhir menunjukkan kualitasnya yang rendah. Dengan pendekatan ini, mengatasi kekurangan program, terutama pada tahap desain akhir, dapat menyebabkan penurunan keandalan. Jelas sekali, pendekatan ini tidak cocok untuk pengembangan perangkat lunak (perangkat lunak) yang bertanggung jawab dan aman, namun masalah kesalahan dalam spesifikasi dan penilaian subjektif terhadap kualitas program oleh pengguna memang ada dan tidak dapat diabaikan. Sebuah sistem pembatasan tertentu harus dikembangkan yang akan mempertimbangkan faktor-faktor ini ketika mengembangkan dan mensertifikasi perangkat lunak semacam ini. Untuk program biasa, semua masalah yang terkait dengan penilaian subjektif terhadap kualitasnya dan adanya kesalahan kemungkinan besar tidak dapat dihindari.

Kesalahan berikut disorot dalam klasifikasi singkat.

Kesalahan antarmuka pengguna.

Kesalahan perhitungan.

Kesalahan kontrol aliran.

Kesalahan dalam transmisi atau interpretasi data.

Kelebihan muatan.

Kontrol versi.

Kesalahan telah diidentifikasi dan dilupakan.

Kesalahan pengujian.

1. Kesalahan antarmuka pengguna.

Banyak di antaranya yang subjektif, karena... sering kali hal ini lebih menimbulkan ketidaknyamanan daripada kesalahan logika "murni". Namun, mereka dapat memicu kesalahan pengguna dalam program atau memperlambat waktu kerjanya hingga batas yang tidak dapat diterima. Akibatnya kita akan mengalami kesalahan pada sistem informasi (SI) secara keseluruhan. Sumber utama kesalahan tersebut adalah kompromi kompleks antara fungsionalitas program dan kemudahan pengguna dalam mempelajari dan bekerja dengan program. Masalahnya harus mulai diselesaikan ketika merancang sistem pada tingkat penguraiannya menjadi modul-modul individual, berdasarkan fakta bahwa kecil kemungkinannya untuk merancang antarmuka pengguna yang sederhana dan nyaman untuk modul yang dipenuhi dengan berbagai fungsi. Selain itu, pedoman desain antarmuka pengguna harus dipertimbangkan. Pada tahap pengujian perangkat lunak, akan berguna untuk menyediakan alat pengujian bawaan yang akan mengingat urutan tindakan pengguna, waktu operasi individu, dan jarak pergerakan kursor mouse. Selain itu, dimungkinkan untuk menggunakan alat pengujian psiko-fisik yang jauh lebih kompleks pada tahap pengujian antarmuka pengguna, yang memungkinkan Anda mengevaluasi kecepatan reaksi pengguna, frekuensi reaksi ini, kelelahan, dll. Perlu dicatat bahwa kesalahan tersebut sangat penting dari sudut pandang keberhasilan komersial perangkat lunak yang sedang dikembangkan, karena mereka terutama akan dinilai oleh calon pelanggan.

2. Kesalahan perhitungan.

Alasan terjadinya kesalahan tersebut berikut diidentifikasi:

Logika yang salah (dapat disebabkan oleh kesalahan desain dan pengkodean);

Operasi aritmatika dilakukan secara tidak benar (biasanya kesalahan pengkodean);

Perhitungan yang tidak akurat (mungkin disebabkan oleh kesalahan desain dan pengkodean). Sebuah topik yang sangat kompleks, Anda perlu mengembangkan sikap Anda terhadapnya dari sudut pandang pengembangan perangkat lunak yang aman.

Sub-item berikut disorot: konstanta usang; kesalahan perhitungan; tanda kurung salah ditempatkan; urutan operator yang salah; Fungsi dasar tidak berfungsi dengan benar; meluap dan meluap; kesalahan kliping dan pembulatan; kebingungan dengan penyajian data; konversi data yang salah dari satu format ke format lainnya; rumus yang salah; perkiraan yang salah.

3. Kesalahan kontrol aliran.

Bagian ini mencakup segala sesuatu yang berkaitan dengan urutan dan keadaan pelaksanaan pernyataan program.

Sub-item berikut disorot:

Perilaku program ini jelas salah;

Transisi oleh GOTO;

Logika berdasarkan definisi pemanggilan rutin;

Menggunakan tabel transisi;

Jalankan data (bukan perintah). Situasi ini mungkin terjadi karena kesalahan dalam bekerja dengan pointer, kurangnya pemeriksaan batas array, kesalahan lompatan yang disebabkan, misalnya, oleh kesalahan dalam tabel alamat lompatan, kesalahan segmentasi memori.

4. Kesalahan dalam pengolahan atau interpretasi data.

Sub-item berikut disorot:

Masalah saat mentransfer data antar subrutin (beberapa jenis kesalahan disertakan di sini: parameter ditentukan dalam urutan yang salah atau hilang, ketidakcocokan tipe data, alias dan interpretasi berbeda dari konten area memori yang sama, interpretasi data yang salah, informasi kesalahan yang tidak memadai , sebelum pintu keluar darurat, status data yang benar belum dipulihkan dari subrutin, salinan data sudah ketinggalan zaman, variabel terikat tidak disinkronkan, pengaturan lokal data global (artinya kebingungan variabel lokal dan global), penggunaan global variabel lokal, salah bit field mask, nilai yang salah dari tabel);

Batas lokasi data (beberapa jenis kesalahan disertakan di sini: akhir dari string yang diakhiri dengan null tidak ditunjukkan, akhir string yang tidak terduga, penulisan/pembacaan di luar batas struktur data atau elemennya, pembacaan di luar buffer pesan , membaca di luar buffer pesan, menambahkan variabel ke kata lengkap, overflow dan underflow dari tumpukan data, menimpa kode atau data dari proses lain);

Masalah dengan pertukaran pesan (beberapa jenis kesalahan disertakan di sini: mengirim pesan ke proses yang salah atau ke port yang salah, kesalahan dalam mengenali pesan yang diterima, pesan hilang atau tidak tersinkronisasi, pesan dikirimkan hanya ke N proses dari N+ 1, kerusakan data yang disimpan di perangkat eksternal, hilangnya perubahan, data yang dimasukkan tidak disimpan, volume data terlalu besar untuk proses penerimaan, upaya gagal untuk membatalkan penulisan data).

5. Peningkatan beban.

Dengan meningkatnya beban atau kurangnya sumber daya, kesalahan tambahan mungkin terjadi. Sub-item disorot: sumber daya yang dibutuhkan tidak tersedia; sumber daya tidak dirilis; tidak ada sinyal untuk melepaskan perangkat; file lama belum dihapus dari drive; memori yang tidak terpakai tidak dikembalikan ke sistem; pemborosan waktu komputer yang tidak perlu; tidak ada blok memori bebas dengan ukuran yang memadai; buffer input atau ukuran antrian tidak mencukupi; elemen antrian, buffer, atau tumpukan belum dihapus; pesan hilang; penurunan produktivitas; meningkatkan kemungkinan terjadinya balapan situasional; dengan peningkatan beban, jumlah data opsional tidak berkurang; keluaran yang disingkat dari proses lain tidak dikenali pada peningkatan beban; Pekerjaan dengan prioritas rendah tidak ditangguhkan.

Pada bagian ini saya ingin menarik perhatian Anda pada hal-hal berikut:

1) Beberapa kesalahan dari bagian ini mungkin muncul pada beban yang tidak terlalu tinggi, tetapi mungkin kesalahan tersebut akan muncul lebih jarang dan dalam interval yang lebih lama;

2) Banyak kesalahan dari 2 bagian sebelumnya yang sudah bersifat probabilistik dalam perumusannya, sehingga diasumsikan bahwa model dan metode probabilistik dapat digunakan untuk mengidentifikasinya.

6. Kontrol versi dan ID.

Sub-poin disorot: kesalahan lama muncul secara misterius; Tidak semua salinan data atau file program diperbarui; tidak ada judul; kurangnya nomor versi; nomor versi yang salah pada judul layar; informasi hak cipta hilang atau salah; program yang dikompilasi dari salinan arsip tidak sesuai dengan versi yang dijual; disk yang sudah jadi berisi kode atau data yang salah.

7. Kesalahan pengujian.

Ini adalah kesalahan staf tim penguji, bukan programnya. Sub-item berikut disorot:

Kesalahan yang terlewatkan dalam program;

Masalahnya tidak diperhatikan (alasan berikut dicatat untuk ini: penguji tidak mengetahui hasil yang benar, kesalahan hilang dalam sejumlah besar data keluaran, penguji tidak mengharapkan hasil pengujian seperti itu, penguji lelah dan lalai, bosan, mekanisme pelaksanaan tes sangat rumit sehingga penguji lebih memperhatikannya daripada hasilnya);

Mengabaikan kesalahan pada layar;

Masalahnya tidak didokumentasikan (alasan berikut dicatat: penguji tidak membuat catatan secara akurat, penguji tidak yakin bahwa tindakan program ini salah, kesalahan tampak terlalu kecil, penguji yakin bahwa kesalahan tidak akan diperbaiki, penguji diminta untuk tidak mendokumentasikan kesalahan tersebut lagi).

8. Kesalahan diidentifikasi dan dilupakan.

Kesalahan dalam menggunakan hasil tes dijelaskan. Menurut saya, bagian ini harus digabungkan dengan bagian sebelumnya. Sub-item berikut ini disorot: laporan akhir belum disusun; masalah yang serius tidak didokumentasikan ulang; perbaikan belum diuji; Daftar masalah yang belum terpecahkan tidak dianalisis sebelum produk dirilis.

Perlu dicatat bahwa kesalahan pengujian yang diuraikan dalam 2 bagian terakhir memerlukan pengujian otomatis dan alat pelaporan untuk dihilangkan. Idealnya, alat-alat ini harus diintegrasikan dengan alat dan teknologi desain perangkat lunak. Mereka harus menjadi alat penting untuk menciptakan perangkat lunak berkualitas tinggi. Saat mengembangkan alat pengujian otomatis, kesalahan yang melekat pada perangkat lunak apa pun harus dihindari, sehingga alat tersebut harus memiliki karakteristik keandalan yang lebih tinggi daripada perangkat lunak yang diuji dengan bantuannya.

Cara dasar untuk mengatasi kesalahan

Dengan mempertimbangkan ciri-ciri tindakan manusia selama penerjemahan, cara-cara berikut untuk mengatasi kesalahan dapat ditunjukkan:

· mempersempit ruang pencarian (penyederhanaan sistem yang dibuat),

· memastikan tingkat pelatihan pengembang yang diperlukan (ini adalah fungsi manajer tim pengembangan),

· memastikan interpretasi yang jelas atas penyajian informasi,

· Kontrol atas kebenaran terjemahan (termasuk kontrol atas interpretasi yang tidak ambigu).

Jika kita berasumsi bahwa akan ada beberapa kesalahan dalam perangkat lunak, maka strategi terbaik (setelah pencegahan kesalahan) adalah dengan menyertakan alat pendeteksi kesalahan dalam perangkat lunak itu sendiri.

Kebanyakan metode ditujukan untuk mendeteksi kegagalan secepat mungkin. Deteksi segera memiliki dua keuntungan: dapat meminimalkan dampak kesalahan dan kesulitan selanjutnya bagi orang yang harus mengambil informasi tentang kesalahan tersebut, menemukannya, dan memperbaikinya.

(SITELINK-S405) Tindakan deteksi kesalahan (/SITELINK) dapat dibagi menjadi dua subkelompok: pasif mencoba mendeteksi gejala kesalahan selama pengoperasian perangkat lunak "normal" dan aktif upaya sistem perangkat lunak untuk memeriksa statusnya secara berkala untuk mencari tanda-tanda kesalahan.

Deteksi pasif. Langkah-langkah deteksi kesalahan dapat diambil pada beberapa tingkat struktural sistem perangkat lunak. Di sini kita akan mempertimbangkan tingkat subsistem, atau komponen, yaitu. Kami akan tertarik pada langkah-langkah untuk mendeteksi gejala kesalahan yang terjadi selama transisi dari satu komponen ke komponen lainnya, serta di dalam komponen. Semua ini, tentu saja, juga berlaku untuk masing-masing modul dalam suatu komponen.

Dalam mengembangkan langkah-langkah ini, kami akan mengandalkan hal-hal berikut.

1. Saling tidak percaya. Setiap komponen harus berasumsi bahwa komponen lainnya mengandung kesalahan. Ketika menerima beberapa data dari komponen lain atau dari sumber di luar sistem, ia harus berasumsi bahwa data tersebut mungkin salah dan mencoba menemukan kesalahan di dalamnya.

2. Deteksi segera. Kesalahan harus dideteksi sedini mungkin. Ini tidak hanya membatasi kerusakan yang ditimbulkannya, tetapi juga membuat proses debug menjadi lebih mudah.

3. Redundansi. Semua alat pendeteksi kesalahan bergantung pada beberapa bentuk redundansi (baik eksplisit maupun implisit).

Saat mengembangkan tindakan deteksi kesalahan (SITELINK-S405)(/SITELINK), penting untuk mengadopsi strategi seluruh sistem yang konsisten. Tindakan yang diambil setelah ditemukannya kesalahan pada perangkat lunak harus seragam untuk seluruh komponen sistem. Hal ini menimbulkan pertanyaan tentang tindakan apa yang harus diambil ketika kesalahan ditemukan. Solusi terbaik adalah segera menghentikan program atau (dalam kasus sistem operasi) menempatkan prosesor pusat dalam keadaan siaga. Dari sudut pandang memberikan orang yang melakukan debug program, seperti pemrogram sistem, dengan kondisi yang paling menguntungkan untuk mendiagnosis kesalahan, penghentian segera tampaknya merupakan strategi terbaik. Tentu saja, di banyak sistem, strategi seperti itu tidak tepat (misalnya, sistem mungkin tidak dapat dijeda). Dalam hal ini, gunakan metode ini pencatatan kesalahan. Deskripsi gejala kesalahan dan “snapshot” status sistem disimpan dalam file eksternal, setelah itu sistem dapat terus beroperasi. File ini nantinya akan ditinjau oleh personel pemeliharaan.

Jika memungkinkan, lebih baik menghentikan sementara eksekusi program daripada mencatat kesalahan (atau menyediakan salah satu mode ini kepada sistem sebagai opsi tambahan). Saya akan mengilustrasikan perbedaan antara metode-metode ini dengan mencari cara untuk mengidentifikasi penyebab suara gerinda yang sesekali terjadi di mobil Anda. Apabila seorang mekanik mobil berada di jok belakang, maka ia dapat memeriksa kondisi mobil pada saat terjadi bunyi gerinda. Jika Anda memilih metode pencatatan kesalahan, tugas diagnostik menjadi lebih sulit.

Deteksi kesalahan aktif. Tidak semua kesalahan dapat dideteksi dengan metode pasif, karena metode ini hanya mendeteksi kesalahan jika gejalanya harus diverifikasi dengan tepat. Anda juga dapat melakukan pemeriksaan tambahan jika Anda merancang software khusus untuk secara aktif mencari tanda-tanda kesalahan pada sistem. Sarana seperti itu disebut sarana deteksi kesalahan aktif.

Alat pendeteksi kesalahan aktif biasanya digabungkan menjadi monitor diagnostik: proses paralel yang secara berkala menganalisis keadaan sistem untuk mendeteksi kesalahan. Sistem perangkat lunak besar yang mengelola sumber daya sering kali mengandung kesalahan yang menyebabkan hilangnya sumber daya dalam waktu lama. Misalnya, manajemen memori sistem operasi menyewakan blok memori ke program pengguna dan bagian lain dari sistem operasi. Kesalahan pada “bagian lain” sistem ini terkadang dapat menyebabkan pengoperasian unit manajemen memori yang salah, yang bertanggung jawab untuk mengembalikan memori yang disewa sebelumnya, yang menyebabkan degenerasi sistem yang lambat.

Monitor diagnostik dapat diimplementasikan sebagai tugas berkala (misalnya, dijadwalkan setiap jam) atau sebagai tugas berprioritas rendah yang dijadwalkan untuk dijalankan ketika sistem memasuki keadaan siaga. Seperti sebelumnya, pemeriksaan spesifik yang dilakukan monitor bergantung pada spesifikasi sistem, namun beberapa gagasan akan jelas dari contoh. Monitor dapat memeriksa memori utama untuk mendeteksi blok memori yang tidak dialokasikan untuk tugas apa pun yang sedang berjalan dan tidak termasuk dalam daftar memori bebas sistem. Ini juga dapat memeriksa situasi yang tidak biasa: misalnya, suatu proses tidak dijadwalkan untuk berjalan dalam jangka waktu yang wajar. Monitor dapat mencari pesan “hilang” dalam sistem atau operasi I/O yang tetap tidak selesai dalam waktu yang sangat lama, area memori disk yang tidak ditandai sebagai dialokasikan dan tidak termasuk dalam daftar memori bebas, serta berbagai macam keanehan pada file datanya.

Terkadang monitor diinginkan untuk melakukan uji diagnostik sistem dalam kondisi darurat. Itu dapat memanggil fungsi sistem tertentu, membandingkan hasilnya dengan yang telah ditentukan dan memeriksa apakah waktu eksekusi masuk akal. Monitor juga dapat secara berkala menyajikan sistem dengan tugas-tugas “kosong” atau “ringan” untuk memastikan bahwa sistem berfungsi setidaknya dengan cara yang paling primitif.

Mengirimkan karya bagus Anda ke basis pengetahuan itu mudah. Gunakan formulir di bawah ini

Pelajar, mahasiswa pascasarjana, ilmuwan muda yang menggunakan basis pengetahuan dalam studi dan pekerjaan mereka akan sangat berterima kasih kepada Anda.

Diposting di http://www.allbest.ru/

1. Analisis fitur keandalan perangkat lunak ASOIU dan metode untuk memprediksi kegagalan perangkat lunak

1.1 Konsep dasar keandalan perangkat lunak

Otomatisasi proses pengendalian adalah arah utama dalam pengembangan sistem pengendalian pasukan, di mana pengembangan, pembuatan dan penggunaan teknologi komputer elektronik, sarana teknis terkait, informasi dan dukungan matematika dalam proses pengendalian pasukan dilakukan, yang secara signifikan dapat meningkatkan efisiensi pengendalian dan meningkatkan kualitas pemrosesan informasi dan kinerja sistem manajemen. Untuk tujuan ini, sistem kendali pasukan otomatis sedang dibuat.

Elemen utama dari sistem kendali pasukan otomatis adalah seperangkat alat otomatisasi pos komando di berbagai tingkatan, yang merupakan kombinasi sarana teknis (transmisi, pemrosesan, tampilan informasi) dan perangkat lunak.

Salah satu kelemahan paling serius dari perangkat lunak ASOI adalah biayanya yang tinggi dan keandalan yang rendah. Banyak ahli menganggap kekurangan pertama ini merupakan kelanjutan dari kekurangan kedua. Karena perangkat lunak pada dasarnya tidak dapat diandalkan, pengujian dan pemeliharaannya memerlukan biaya berkelanjutan yang besar.

Sebelum menganalisis keandalan perangkat lunak, mari kita perjelas konsep dasar teori keandalan.

Keandalan perangkat lunak adalah kemampuan untuk memastikan bahwa hasil yang benar diperoleh sesuai dengan algoritma yang diberikan dalam interval waktu tertentu.

Kegagalan perangkat lunak adalah keadaan paket perangkat lunak yang terkait dengan tidak berfungsinya paket perangkat lunak dan terhentinya fungsi lebih lanjut karena kesalahan.

Yang kami maksud dengan kesalahan dalam perangkat lunak adalah kombinasi perintah dalam suatu program, yang pelaksanaannya, dengan data awal yang benar, menghasilkan hasil yang tidak sesuai dengan nilai referensi yang ditentukan dalam dokumentasi teknis.

Keandalan perangkat lunak ASOI ditentukan oleh operasi bebas kegagalan, kemampuan pemulihan, dan stabilitasnya.

Keandalan perangkat lunak adalah kemampuannya untuk mempertahankan kemampuan untuk menjalankan fungsi tertentu dengan benar dan memecahkan masalah yang dibebankan pada sarana komputasi sistem kendali otomatis dalam proses pemrosesan informasi di komputer untuk waktu tertentu. Dalam hal ini, keadaan perangkat lunak, di mana tugas-tugas pemrosesan informasi di komputer diselesaikan dengan benar (benar), disebut keadaan operasional. Jika tidak, negara disebut tidak dapat dioperasikan.

Transisi dari keadaan berfungsi ke keadaan tidak beroperasi terjadi di bawah pengaruh kegagalan perangkat lunak. Ciri kegagalan perangkat lunak adalah penghapusannya dilakukan dengan memperbaiki program atau memasukkan data.

Properti penting dari perangkat lunak adalah kemampuan pemulihannya, yang mengacu pada properti bahwa perangkat lunak dapat beradaptasi untuk mendeteksi penyebab kegagalan perangkat lunak dan menghilangkannya. Pemulihan setelah kegagalan suatu program mungkin melibatkan penyesuaian dan pemulihan teks program, koreksi data, perubahan pada organisasi proses komputasi (yang seringkali diperlukan ketika alat komputasi beroperasi secara real time).

Diketahui bahwa kegagalan dalam teori reliabilitas diartikan sebagai kegagalan koreksi diri yang tidak memerlukan intervensi pihak luar untuk menghilangkannya. Dengan kata lain, kegagalan adalah kegagalan yang dihilangkan secara otomatis dan memiliki waktu pemulihan yang cukup singkat. Oleh karena itu, sehubungan dengan keandalan perangkat lunak sistem kendali otomatis, suatu kriteria harus ditunjukkan secara khusus yang memungkinkan hilangnya fungsionalitas paket perangkat lunak untuk dikaitkan dengan kegagalan atau malfungsi. Sebagai kriteria seperti itu, kami mengambil nilai ambang batas waktu pemulihan tertentu (? dalam pori).

Dengan demikian, lebih sedikit waktu dan sumber daya yang dihabiskan untuk menghilangkan kegagalan dibandingkan menghilangkan kegagalan. Dalam bentuk formalnya, definisi kegagalan dan kegagalan perangkat lunak dapat direpresentasikan sebagai:

B dengan< ? в пор

Dalam s - waktu pemulihan setelah kegagalan.

Sekitar - waktu pemulihan setelah kegagalan.

Stabilitas operasi perangkat lunak adalah kemampuan untuk membatasi konsekuensi kesalahan internal dalam program dan dampak buruk dari lingkungan eksternal (termasuk kegagalan perangkat keras, input data yang salah, kesalahan operator, dan lain-lain) dan untuk menahannya.

Dalam analisis konsep dasar keandalan perangkat lunak, diberikan definisi kegagalan, kesalahan dan keandalan perangkat lunak. Ternyata peralihan dari kondisi berfungsi ke kondisi tidak beroperasi terjadi di bawah pengaruh kegagalan perangkat lunak. Dari indikator waktu terlihat jelas bahwa lebih sedikit waktu dan sumber daya yang dihabiskan untuk menghilangkan kegagalan dibandingkan menghilangkan kegagalan.

1.2 Penyebab utama dan tanda-tanda mengidentifikasi kesalahan perangkat lunak

Penyebab utama kesalahan perangkat lunak adalah:

Kompleksitas perangkat lunak yang lebih besar, misalnya dibandingkan dengan perangkat keras komputer.

Penerjemahan informasi yang salah dari satu representasi ke representasi lainnya pada tingkat makro dan mikro. Di tingkat makro, tingkat proyek, berbagai jenis informasi ditransfer dan diubah antar organisasi, departemen, dan pelaku tertentu di semua tahap siklus hidup perangkat lunak. Pada tingkat mikro, tingkat pelaku, informasi diubah sesuai skema: menerima informasi, mengingat, memilih dari memori, mereproduksi informasi.

Sumber kesalahan perangkat lunak adalah:

Internal: kesalahan desain, kesalahan algoritma, kesalahan pemrograman, kualitas alat keamanan yang tidak memadai, kesalahan dalam dokumentasi.

Eksternal: kesalahan pengguna, kegagalan dan kegagalan peralatan komputer, distorsi informasi dalam saluran komunikasi, perubahan konfigurasi sistem.

Tanda-tanda deteksi kesalahan adalah:

1. Penghentian program sebelum waktunya.

2. Peningkatan waktu eksekusi program.

3. Pelanggaran urutan pemanggilan subrutin individu.

4. Kesalahan keluaran informasi yang berasal dari sumber luar; terjadi ketidaksesuaian antara informasi masukan karena: distorsi data pada media primer, kegagalan dan kegagalan peralatan, kebisingan dan kegagalan saluran komunikasi, kesalahan dokumentasi.

Kesalahan tersembunyi dalam program itu sendiri: kesalahan perhitungan, kesalahan input/output, kesalahan logika, kesalahan manipulasi data, kesalahan kompatibilitas, kesalahan pemasangan.

Distorsi informasi masukan yang akan diproses: distorsi data pada media penyimpanan utama; kegagalan dan kegagalan peralatan input data dari media penyimpanan utama; kebisingan dan kegagalan saluran komunikasi saat mengirimkan pesan melalui jalur komunikasi; kegagalan dan kegagalan peralatan untuk mengirimkan atau menerima informasi; kehilangan atau kerusakan pesan dalam penyimpanan buffer sistem komputer; kesalahan dalam dokumentasi; digunakan untuk menyiapkan entri data; kesalahan pengguna saat menyiapkan informasi awal.

Tindakan pengguna yang salah:

1. Penafsiran pesan yang salah.

2. Tindakan pengguna yang salah saat berdialog dengan perangkat lunak.

3. Tindakan pengguna yang salah atau dengan kata lain dapat disebut kesalahan pengguna yang timbul akibat buruknya kualitas dokumentasi program: deskripsi kemampuan program yang salah; deskripsi mode operasi yang salah; deskripsi format informasi masukan dan keluaran yang salah; Deskripsi pesan diagnostik salah.

Kerusakan peralatan instalasi: menyebabkan gangguan pada proses normal proses komputasi; menyebabkan distorsi data dan teks program di memori utama dan eksternal.

Jadi, ketika mempertimbangkan penyebab utama kegagalan dan kegagalan perangkat lunak, kita dapat mengatakan bahwa pengetahuan ini memungkinkan kita mengambil tindakan yang diperlukan secara tepat waktu untuk mencegah kegagalan dan kegagalan perangkat lunak.

1.3 Parameter utama dan indikator keandalan program ASOIU

Istilah model keandalan perangkat lunak umumnya mengacu pada model matematika yang dibangun untuk mengevaluasi ketergantungan perangkat lunak pada beberapa parameter tertentu.

Parameter - besaran kuantitatif, dipilih atau dievaluasi dalam suatu fungsi atau model matematika dalam kondisi tertentu.

Nilai parameter tersebut diasumsikan diketahui atau dapat diukur melalui observasi atau studi eksperimental terhadap proses fungsi perangkat lunak.

Kerumitan algoritma untuk berfungsinya sistem otomatis menyebabkan volume dan kompleksitas perangkat lunak yang signifikan. Peningkatan volume (hingga 10 5 atau lebih instruksi mesin) dan kompleksitas perangkat lunak membuat pengembangan komponen perangkat lunak yang sepenuhnya bebas cacat menjadi tidak mungkin. Akibatnya, perangkat lunak dioperasikan dengan kesalahan yang menyebabkan kegagalan perangkat lunak. Proses debugging perangkat lunak untuk mengidentifikasi dan menghilangkan kesalahan dalam program dapat diwakili oleh grafik perubahan tingkat kegagalan perangkat lunak o.

Beras. 1.3.1. - program seumur hidup.

Bagian 1 berhubungan dengan tahapan debugging, pengujian dan uji coba pengoperasian perangkat lunak. Di bagian 2, kesalahan perangkat lunak sisa setelah desain, terkait dengan kombinasi data masukan yang agak jarang, dan kesalahan debugging. Di bagian 3, kesalahan baru muncul dan setelah beberapa modifikasi pada paket perangkat lunak, perangkat lunak tersebut menjadi usang. Setelah itu, perangkat lunak harus diganti seluruhnya karena sudah habis masa berlakunya dan tidak memenuhi ketentuan baru.

1.4 Metode untuk memprediksi kegagalan perangkat lunak dan menguji program

Pencegahan kesalahan adalah cara terbaik untuk meningkatkan keandalan perangkat lunak. Untuk mengimplementasikannya, metodologi desain sistem kendali dikembangkan yang sesuai dengan model spiral siklus hidup perangkat lunak. Teknik ini memberikan pengurangan kompleksitas yang konsisten di semua tahap analisis objek. Saat menguraikan ASOIU, tingkat kontrol sistem diidentifikasi, kemudian subsistem, rangkaian tugas, dan seterusnya, hingga fungsi dan prosedur otomatis individual.

Metode prediksi dan pengujian perangkat lunak dapat mencegah, meminimalkan atau menghilangkan terjadinya kesalahan.

Metode peramalan dan pengujian perangkat lunak meliputi:

1. Metode untuk mengatasi kompleksitas sistem.

Kompleksitas sistem adalah salah satu alasan utama rendahnya keandalan perangkat lunak. Secara umum kompleksitas suatu objek merupakan fungsi dari interaksi antar komponennya. Dalam perjuangan melawan kompleksitas perangkat lunak, dua konsep digunakan: [L.1]

Struktur hierarki. Hierarki memungkinkan Anda memecah sistem menjadi beberapa tingkat pemahaman. Konsep level memungkinkan Anda menganalisis sistem, menyembunyikan detail implementasi level lain yang tidak penting untuk level tertentu. Hierarki memungkinkan Anda memahami, merancang, dan mendeskripsikan sistem yang kompleks.

Kemerdekaan. Menurut konsep ini, untuk meminimalkan kompleksitas, independensi elemen sistem perlu dimaksimalkan.

2. Metode untuk mencapai akurasi yang lebih baik dalam menerjemahkan informasi.

Metode untuk meningkatkan pertukaran informasi didasarkan pada pengenalan berbagai jenis redundansi ke dalam perangkat lunak sistem:

Redundansi sementara. Menggunakan sebagian kinerja komputer untuk mengontrol eksekusi dan memulihkan fungsionalitas perangkat lunak setelah kegagalan.

Redundansi informasi. Duplikasi sebagian data sistem informasi untuk menjamin keandalan dan mengontrol keandalan data.

Redundansi perangkat lunak meliputi:

saling tidak percaya - komponen sistem dirancang berdasarkan asumsi bahwa komponen lain dan data sumber mengandung kesalahan, dan harus mencoba mendeteksinya;

deteksi segera dan pencatatan kesalahan;

kinerja fungsi yang identik oleh modul sistem yang berbeda dan perbandingan hasil pemrosesan;

kontrol dan pemulihan data menggunakan jenis redundansi lainnya.

Setiap metode meningkatkan keandalan perangkat lunak dan toleransi kesalahan. Tidak mungkin menentukan metode mana yang lebih baik, karena setiap metode didasarkan pada prinsip dan konsepnya sendiri. Oleh karena itu, kedua metode tersebut dapat digunakan.

Tahapan penting dalam siklus hidup perangkat lunak, yang menentukan kualitas dan keandalan sistem, adalah pengujian. Pengujian adalah proses mengeksekusi program dengan tujuan menemukan kesalahan. Tahapan pengujian: pengendalian modul perangkat lunak terpisah dari modul sistem lainnya; pengendalian antarmuka (koneksi) antar bagian sistem (modul, komponen, subsistem); memantau kinerja sistem dari fungsi-fungsi otomatis; memeriksa kepatuhan sistem dengan persyaratan pengguna dan kebenaran dokumentasi, menjalankan program sesuai dengan instruksi.

Ada dua strategi untuk merancang pengujian: pengujian terhadap spesifikasi (dokumentasi) tanpa mengkhawatirkan teks program, dan pengujian terhadap teks program tanpa mengkhawatirkan spesifikasinya. Kompromi yang masuk akal terletak di tengah-tengah, bergeser ke satu arah atau lainnya tergantung pada fungsi yang dilakukan oleh modul, kompleks, atau subsistem tertentu.

Kualitas penyiapan data awal untuk pengujian sangat mempengaruhi efisiensi proses secara keseluruhan dan meliputi:

1. Spesifikasi teknis.

2. Deskripsi sistem.

3. Panduan pengguna.

4. Teks sumber.

5. Aturan konstruksi (standar) program dan antarmuka.

6. Pengujian kriteria mutu.

7. Nilai acuan data awal dan data hasil.

8. Sumber daya yang dialokasikan ditentukan oleh sumber daya keuangan yang tersedia.

Namun, pengujian menyeluruh terhadap semua cabang algoritme program apa pun untuk semua varian data masukan praktis tidak mungkin dilakukan. Oleh karena itu, lamanya tahap pengujian hanya bersifat sementara. Mengingat sumber daya nyata dari setiap proyek dibatasi oleh anggaran dan waktu, dapat dikatakan bahwa seni pengujian terletak pada pemilihan pengujian dengan dampak maksimal.

Kesalahan dalam program dan data dapat muncul pada setiap tahap pengujian, serta selama pengoperasian sistem. Informasi yang dicatat dan diproses harus digunakan untuk mengidentifikasi penyimpangan dari persyaratan pelanggan atau spesifikasi teknis. Untuk mengatasi masalah ini, digunakan sistem manajemen konfigurasi untuk versi komponen perangkat lunak, database untuk mendokumentasikan pengujian, hasil pengujian, dan penyesuaian program yang diselesaikan. Sarana untuk mengumpulkan pesan tentang kegagalan, kesalahan, usulan perubahan, penyesuaian yang dilakukan, dan karakteristik versi adalah yang utama untuk mengelola pengembangan dan pemeliharaan kompleks perangkat lunak dan terdiri dari log:

Perubahan yang diusulkan.

Ditemukan cacat.

Penyesuaian yang disetujui.

Perubahan yang diterapkan.

Versi khusus.

Bab ini menganalisis penyebab utama dan gejala kesalahan serta memperkenalkan parameter utama dan indikator keandalan perangkat lunak. Metode untuk memprediksi kegagalan perangkat lunak dan menguji program untuk meningkatkan keandalan juga dibahas. Untuk menilai keandalan perangkat lunak, digunakan model khusus berdasarkan parameter dan indikator yang diberikan di atas.

2. Analisis model untuk menilai keandalan perangkat lunak

Model matematika yang ada harus mengevaluasi karakteristik kesalahan dalam program dan memprediksi keandalannya selama pengoperasian. Model bersifat probabilistik, dan keandalan prakiraan bergantung pada keakuratan sumber data dan kedalaman prakiraan dari waktu ke waktu.

Model matematika ini dirancang untuk memperkirakan:

1. Indikator keandalan kompleks program selama proses debugging;

2. Jumlah kesalahan yang belum terdeteksi;

3. Waktu yang diperlukan untuk mendeteksi kesalahan berikutnya dalam program yang berfungsi;

4. Waktu yang diperlukan untuk mengidentifikasi semua kesalahan dengan probabilitas tertentu.

Ada sejumlah model matematika:

Model variasi kesalahan eksponensial tergantung pada waktu debugging.

Model variasi diskrit yang memperhitungkan peningkatan MTBF sebagai fungsi linier dari pengujian dan waktu pengujian.

model Schumann. Data masukan untuk model Schumann dikumpulkan selama pengujian perangkat lunak dalam interval waktu tetap atau acak.

Model La Padula. Menurut model ini, melakukan serangkaian pengujian dalam m tahap. Setiap tahapan diakhiri dengan koreksi terhadap perangkat lunak.

Model Dzelinski-Moranda. Data awal dikumpulkan selama proses pengujian perangkat lunak. Dalam hal ini, waktu hingga kegagalan berikutnya dicatat.

Model Schick-Wolverton. Modifikasi model Dzelinski-Moranda untuk kasus lebih dari satu kesalahan yang terjadi pada interval yang dipertimbangkan.

Model Musa. Selama proses pengujian, waktu yang diperlukan untuk mengeksekusi program (test run) hingga kegagalan berikutnya dicatat.

Model Probabilitas Transisi. Model ini didasarkan pada proses Markov yang terjadi dalam sistem diskrit dengan waktu kontinu.

Model pabrik. Penggunaan model ini mengandaikan perlunya memasukkan sejumlah kesalahan yang diketahui ke dalam program secara artifisial sebelum pengujian.

model Lipov. Modifikasi model Mills yang mempertimbangkan kemungkinan mendeteksi kesalahan saat menggunakan jumlah pengujian yang berbeda.

Model intuitif sederhana. Penggunaan model ini melibatkan pengujian oleh dua kelompok pemrogram secara independen satu sama lain, menggunakan set pengujian independen.

Model Corcoran. Model ini menggunakan probabilitas kegagalan yang bervariasi untuk berbagai jenis kesalahan.

model Nelson. Saat menghitung keandalan perangkat lunak, model ini memperhitungkan kemungkinan pemilihan kasus uji tertentu untuk eksekusi program berikutnya.

Dengan jumlah model yang begitu banyak, yang utama adalah model eksponensial dan variasi diskrit.

2.1 Model variabel diskrit

Dalam karya ini, model perubahan diskrit berarti model yang didasarkan pada peningkatan diskrit dalam waktu antar kegagalan. Model ini didasarkan pada asumsi berikut:

1. Menghilangkan kesalahan dalam program menyebabkan peningkatan waktu antara kegagalan T dengan jumlah yang sama, sama dengan:

T (1) =T (2) =…=T (i) = konstanta (2.1.1)

T(i) = T(i) - T(i-1) (2.2.2)

2. Waktu antara dua kegagalan berturut-turut:

saya = saya - saya -1 (2.1.3)

adalah variabel acak yang dapat direpresentasikan sebagai jumlah dari dua variabel acak:

saya = saya -1 + saya (2.1.4)

dimana i adalah variabel acak independen yang memiliki ekspektasi matematis yang sama M() ​​dan standar deviasi.

3. Interval waktu awal 0 sebanding dengan variabel acak 0, yaitu. 0 0 , karena pada periode awal pengoperasian program, kegagalan di dalamnya sangat sering terjadi.

Berdasarkan asumsi kedua, nilai interval antara kegagalan ke-i (i-1) dapat ditentukan oleh relasi:

saya = saya -1 + saya = 0 + j (2.1.5)

dari situ kita dapat memperoleh relasi untuk menentukan waktu terjadinya kegagalan ke-m dalam program:

t m = saya = (0 + j) (2.1.6)

Berdasarkan asumsi ketiga, maka hubungan yang dihasilkan akan berbentuk:

saya = 0 + j = j (2.1.7)

t m = (0 + j) = saya j (2.1.8)

Berdasarkan asumsi ini, waktu operasi rata-rata antara kegagalan program (m-1) dan bulan adalah sama dengan:

T 0 (m) = M( m -1 ) = M( j ) = saya j = m M(). (2.1.9)

Waktu rata-rata hingga kegagalan ke-bulan terjadi dapat ditentukan oleh hubungan:

T m = M(t m ) = saya jk) = M(). (2.1.10)

2.2 Distribusi eksponensial

Sekarang mari kita langsung ke analisis distribusi eksponensial itu sendiri.

Distribusi yang dipertimbangkan dicirikan oleh sejumlah sifat, seperti:

1. Kesalahan dalam kompleks program bersifat independen dan muncul secara acak. Properti ini mencirikan keteguhan waktu dari intensitas manifestasi dan deteksi kesalahan (yaitu osh =const) selama seluruh waktu eksekusi program (=t n -t 0).

2. Intensitas manifestasi dan deteksi kesalahan osh (intensitas kegagalan) sebanding dengan jumlah kesalahan yang tersisa di dalamnya:

()= Kn 0 () (2.2.1)

dimana K adalah koefisien proporsionalitas yang memperhitungkan kecepatan aktual komputer dan jumlah perintah dalam program.

3. Dalam proses perbaikan kesalahan program, tidak terjadi kesalahan baru. Artinya intensitas koreksi kesalahan dn/dt akan sama dengan intensitas pendeteksiannya:

Maka n 0 ()= N 0 - n(). (2.2.3)

Berdasarkan asumsi yang diperkenalkan di atas, kita memperoleh:

n()=N 0 (1-e - K); (2.5)

Jika kita menerimanya, kita mendapatkan:

2.3 Metodologi untuk menilai keandalan program berdasarkan jumlah kesalahan yang diperbaiki

Misalkan N 0 adalah jumlah kesalahan yang terjadi pada program sebelum pengujian.

n() - jumlah kesalahan yang dihilangkan selama pengujian (testing) program;

n 0 () - jumlah kesalahan yang tersisa dalam program pada akhir pengujian.

Maka n 0 ()= N 0 - n().

Berdasarkan asumsi pada paragraf 2.2.1 yaitu: dan () = Kn 0 () diperoleh:

K adalah koefisien yang memperhitungkan kecepatan komputer.

Solusi persamaan diferensial ini pada kondisi awal t=0 dan =0 adalah:

n()=N 0 (1-e -K); (2.3.2)

n 0 ()=N 0 - n()=N 0 e -K . (2.3.3)

Keandalan program berdasarkan hasil pengujian dari waktu ke waktu dapat dicirikan oleh waktu rata-rata antara kegagalan yang sama dengan:

Jika kita memasukkan nilai awal waktu rata-rata antara kegagalan sebelum pengujian sama dengan, kita memperoleh:

yang menunjukkan bahwa waktu rata-rata antara kegagalan meningkat ketika kesalahan diidentifikasi dan diperbaiki.

Dalam praktiknya, kesalahan baru mungkin masih muncul selama penyesuaian program. Misalkan B adalah koefisien pengurangan kesalahan, yang didefinisikan sebagai rasio intensitas pengurangan kesalahan dengan intensitas manifestasinya, atau dengan tingkat kegagalan, yaitu:

Jika kita menyatakan dengan m jumlah kegagalan yang terdeteksi, dan M 0 jumlah kegagalan yang harus terjadi agar n kesalahan terkait dapat diidentifikasi dan dihilangkan, yaitu:

maka waktu rata-rata antara kegagalan dan jumlah kegagalan yang terdeteksi ditentukan oleh hubungan berikut:

Jika kita menerimanya, kita mendapatkan:

Untuk penggunaan praktis, jumlah kesalahan m yang harus dideteksi dan diperbaiki untuk mencapai peningkatan waktu rata-rata antara kegagalan dari T 01 ke T 02 adalah hal yang menarik. Indikator ini dapat diperoleh dari rasio berikut:

Jadi, penilaian keandalan program berdasarkan jumlah kesalahan yang diperbaiki ditentukan dengan rumus:

2.4 Metodologi untuk menilai keandalan program berdasarkan waktu pengujian

Waktu pengujian tambahan yang diperlukan untuk memastikan peningkatan waktu rata-rata antara kegagalan dari T 01 ke T 02 ditentukan dari hubungan:

dimana T 01 dan T 02 ditentukan menurut rumus (2.3.9):

Penilaian reliabilitas program berdasarkan waktu pengujian ditentukan dengan rumus:

2.5 Metodologi untuk menilai keandalan program berdasarkan waktu pengoperasian

Waktu operasi antara kegagalan berturut-turut - variabel acak T (i) dapat direpresentasikan sebagai jumlah dari dua variabel acak:

T(i) = T(i -1) + T(i) (2.5.1)

Dengan menerapkan (3.3.1) secara konsisten pada seluruh periode waktu pengoperasian di antara kegagalan, kita peroleh :

T(i) = T(0) + T(?) (2.5.2)

Variabel acak T n - waktu pengoperasian hingga kegagalan program ke-n terjadi - sama dengan:

T n = T (i) = (2.5.3)

Mari kita perkenalkan asumsi berikut:

1) semua variabel acak T() independen dan memiliki ekspektasi matematis yang sama m? t dan standar deviasi? ? T ;

2) variabel acak T (0) dapat diabaikan dibandingkan dengan jumlah T (?)

Dasar asumsi kedua dapat berupa pertimbangan sebagai berikut: pada periode awal pengoperasian program, kesalahan sangat sering terjadi, yaitu waktu T (0) yang singkat. Jumlah (2.5.3) bertambah dengan cepat seiring bertambahnya n, dan pecahan T(0) turun dengan cepat. Kita asumsikan bahwa T (0) ? T(0) . Sesuai dengan asumsi kedua yang kita miliki:

T (n) = T (?) . (2.5.4)

Untuk T (?) yang sama, waktu operasi antara (n-1) dan n kegagalan - variabel acak T (n) - memiliki ekspektasi matematis:

mt (n) =M=nm ? t (2.5.6)

T(n) = ? ? T ; (2.5.7)

Untuk variabel acak T n ekspektasi matematisnya sama dengan:

M? T ; (2.5.8)

dan deviasi standar:

T ; (2.5.9)

Untuk menghitung nilai, dan, berdasarkan data kegagalan program selama periode pengamatan t n, perlu untuk menemukan perkiraan statistik dari karakteristik numerik dari perbedaan acak T (i):

n n - jumlah kegagalan program per waktu pengoperasian (0, t n).

Mengingat untuk t >t n jumlah kegagalan n n >> 1, dari (2.5.8) dan (2.5.9) kita mempunyai:

mt (n) ? M? t , (2.5.12)

T(n) = ? ? tn; (2.5.13)

Karena variabel acak T (n) dan T n menurut (2.5.4) dan (2.5.5) sama dengan jumlah banyak variabel acak, T (n) dan T n dapat dianggap terdistribusi normal dengan ekspektasi matematis dan varians ditentukan oleh (2.5.6) - (2.5.9), (2.5.12) dan (2.5.13). Karena waktu operasinya positif, dalam praktiknya digunakan distribusi normal yang dipotong pada interval (0, ?). Biasanya faktor normalisasinya adalah c?1.

Ketika n>n n kepadatan distribusi waktu operasi antara kegagalan berikutnya (n-1) dan n:

f (n) (?) = , (2.5.14)

Di mana? dihitung dari saat kegagalan terakhir (n-1).

Kesimpulan

Pekerjaan tersebut menunjukkan bahwa keandalan perangkat lunak puluhan kali lebih rendah daripada keandalan perangkat keras. Persyaratan keandalan perangkat lunak adalah definisi kebutuhan penyelesaian misi tempur setidaknya selama 1872 jam.

Dari analisis terlihat jelas bahwa dampak terbesar terhadap keandalan perangkat lunak diberikan oleh kesalahan internal dan kesalahan yang ditemukan pada awal pengoperasian program. Berdasarkan hal tersebut maka dilakukan analisis model reliabilitas, metode perhitungan dan penilaian reliabilitas perangkat lunak. Dengan menggunakan analisis ini, berdasarkan metode diskrit dan eksponensial, kami menghitung waktu yang diperlukan untuk pengujian perangkat lunak guna meningkatkan masa pakai program.

Referensi

perkiraan keandalan keandalan perangkat lunak

1.V.V. Lipaev Desain dukungan matematika untuk sistem kontrol otomatis. (rekayasa sistem, arsitektur, teknologi). M., “Burung hantu. radio", 1977.

2. RS. Zakharova Masalah dasar teori dan praktik keandalan.

3. V.A. Blagodatskikh, V.A. Volnin, K.F. PoskakalovStandarisasi pengembangan perangkat lunak.

4. A.A. Voronov Landasan teoretis untuk membangun sistem kendali otomatis. Perkembangan spesifikasi teknis. - M.: Nauka, 1997.

5. Dasar-dasar teori terapan keandalan sistem kendali otomatis. Buku Teks, Tver, VA Pertahanan Udara, 1995, n/s 32. 965.0-75. V.M. Ionov dkk., inv. Nomor 8856.

6. BN Gorevich. Perhitungan indikator keandalan sistem senjata dan elemen redundan. Catatan kuliah, VA Air Defense, 1998, n/s 68.501.4, G68, inv. №9100

Diposting di Allbest.ru

Dokumen serupa

Analisis metode untuk menilai keandalan perangkat lunak di semua tahap siklus hidup, klasifikasi dan jenisnya, persyaratannya. Perangkat lunak multiversi. Model dan algoritma modern untuk menganalisis keandalan perangkat lunak.

tesis, ditambahkan 03/11/2013


Tindakan yang dilakukan saat merancang SIA. Teknologi cluster, jenisnya. Metode untuk menghitung keandalan pada berbagai tahap desain sistem informasi. Perhitungan keandalan dengan redundansi. Pengujian keandalan perangkat lunak.

tugas kursus, ditambahkan 07/02/2013


Perangkat lunak sebagai produk. Ciri-ciri utama kualitas perangkat lunak. Konsep dasar dan indikator keandalan perangkat lunak. Faktor destabilisasi dan metode untuk memastikan keandalan pengoperasian perangkat lunak.

kuliah, ditambahkan 22/03/2014


Model keandalan perangkat lunak sebagai model matematika untuk menilai ketergantungan keandalan perangkat lunak pada beberapa parameter tertentu, jenis analisis. Karakteristik umum model intuitif sederhana, analisis area penggunaan.

presentasi, ditambahkan 22/03/2014


Permintaan klien untuk cakupan kemungkinan permintaan ke server. Sebuah program untuk memprediksi perilaku keandalan perangkat lunak berdasarkan metode Monte Carlo. Pengaruh jumlah program klien terhadap perilaku sistem perangkat lunak client-server.

tes, ditambahkan 03/12/2010


Fitur model analitis dan empiris keandalan perangkat lunak. Perancangan algoritma pengujian dan pengembangan program untuk mengetahui keandalan perangkat lunak menggunakan model Schumann, Mills, Lipov, menggunakan bahasa C# dan VisualStudio 2013.

tugas kursus, ditambahkan 29/06/2014


Keandalan suatu sistem kendali sebagai kombinasi keandalan sarana teknis, komputer, perangkat lunak, dan personel. Perhitungan keandalan sistem teknis, jenis kegagalan sistem kendali otomatis dan sistem kendali otomatis, peningkatan keandalan dan penyebab kegagalan sistem kendali otomatis.

mata kuliah perkuliahan, ditambah 27/05/2008


Metode eksak dan perkiraan untuk menganalisis keandalan struktural. Kriteria untuk menilai keandalan struktural menggunakan pemodelan statistik. Pengembangan algoritma dan program untuk menghitung keandalan struktur. Pedoman untuk bekerja dengan program ini.

tesis, ditambahkan 17/11/2010


Pernyataan masalah keandalan perangkat lunak dan alasan terjadinya. Karakteristik keandalan peralatan. Program komputer sebagai objek penelitian, keandalan dan kebenarannya. Model rangkaian uji Bernoulli.

abstrak, ditambahkan 21/12/2010


Keandalan sebagai karakteristik kualitas perangkat lunak. Metodologi untuk menghitung karakteristik keandalan perangkat lunak (seperti waktu terjadinya kegagalan, faktor ketersediaan, kemungkinan kegagalan), fitur-fitur yang memprediksi perubahannya dari waktu ke waktu.