Tasarım veya uygulamaların geliştirme/gerçekleştirme aşamasında hatalar yapmak adeta kaçınılmazdır. Yapılan hatalar bazen kolayca bulunur, bazen uzun uğraşlar sonucu bulunur; bazen hiç bulunamadığı da olur. Bulunan her hata tecrübeyi artırır. Ancak metotsuzca hata bulmaya çalışmak çok zaman kaybına yol açabilir, çalışma şevkini kırar ve araştırmacı/geliştirmeciyi şaşkın bir vaziyette bırakabilir. Hatta o işin ya da o araştırmacı/geliştirmecinin gözden çıkarılmasıyla sonuçlanabilir. İşi bir başkasına yaptırma çözümü de “neden yeterince gelişemiyoruz?” sorusunun cevaplarından birisi olur. Halbuki ister hesaplamalarda, ister yazılımda, ister mekanik veya devre tasarımında veya bunların simülasyonu veya fiziksel gerçekleştirilmesinde olsun, karşılaşılan hataları bulmanın ortak bir metodu vardır.
Üstten yüzeysel ve hızlı bir bakışla bariz bazı hatalar görülebilir. Mesela devrede yanıp kararmış bir eleman veya yazılımda açıkça anlaşılan hata mesajı gibi. Sisteme enerji gelmemesi de genellikle yüzeysel bakışla fark edilebilecek hatalardandır. Tecrübelere göre mevcut problem için en sık karşılaşılan hata nedenlerine bakmak da bu sınıftan sayılabilir.
Aslında bu maddede sayılanlar belirli bir metot değil, biraz zaman alabilen asıl metoda hiç girmeden, varsa kısa yoldan hatayı görme ihtimallerini değerlendirmektir. Kısa yoldan yüzeysel bakışla bulunamayan hatalar için asıl metot, sonraki adımlardadır.
Bir mühendisin bir sistem hakkında, “neden çalışmıyor?” sorusundan önce, “neden çalışsın ki?” sorusunun cevabına ulaşması gerekir. Zira normalde bir sistemin çalışması için pek çok şartın birden sağlanması gerekir; çalışmaması için ise küçük bir şartın sağlanmaması yeterli olabilir. Tasarlayıcı kendimiz isek bu soru daha da önem kazanır. Çünkü önceden doğrulanmamış çalışma için tasarımda yanlışlar olması kuvvetle muhtemeldir. Başkaları tarafından tasarlanmış ve doğrulandığı söylenen bir sistem için ise çalışmama nedeni muhtemelen bizim bir hatamız veya eksiğimizdir.
Sonuç olarak “neden çalışmıyor?” sorusu üzerine özgüvenle gidebilmek için önce eldeki sistemin çalışma prensibine vakıf olunuz. Sistemi yeterince anlayarak çalışması gerektiğini düşünüyorsanız sonraki adıma geçebilirsiniz.
İnsanların en iyi mantık yürüttüğü konulardan birisi, maddi menfaatlerini kaybetmenin söz konusu olmasıdır. Bu yüzden kurduğunuz sistem çalışmadığında yapmanız gerekenleri bulmak için şu durumda olduğunuzu varsayın:
Birine aracılar eliyle para gönderdiniz; fakat alıcı paranın gelmediğini veya eksik geldiğini söylüyor. Ne yapardınız?
Muhtemelen aracıları sorgulardınız. Peki ama ya yüze yakın sayıda aracı varsa? Üstelik para tek koldan değil de birkaç koldan aracılarla gönderilmişse? Hepsini tek tek sorgulamakla zaman kaybeder miydiniz? Yoksa daha hızlı bir yöntem mi uygulardınız?
Okumaya devam etmeden önce biraz düşünüp bir yöntem geliştirmeye çalışınız.
Yeterince düşündüyseniz okumaya devam edebilirsiniz. Aşağıda anlatılandan farklı ve daha iyi bir yöntem bulduğunuzu düşünüyorsanız bilmek isterim.
Bulduğunuz yöntem muhtemelen ara sorgulamalar yapmaktır. Şöyle ki:
Hangi ana kollarda para akışının aksadığına bakarsınız. Aksayan kolda ortadan bir aracıyı sorgularsınız. Onda problem olmamışsa onunla o kolun sonunun ortasından bir aracıyı, problem olmuşsa onunla o kolun başının ortasından bir aracıyı sorgularsınız. Böyle böyle devam ederek bir kolda yüz aracı olsa bile birkaç sorgulama ile aksama noktasını veya noktalarını bulursunuz.
Tabii bu sorgulamaları yapabilmek ve yorumlayabilmek için sistemin nasıl işlediğini bilmeniz ve ara sorgulamalar yapmaya yetkili olmanız gerekir. Mesela bu yöntem İngiliz bankalarında işlemiyor. Benim başıma geldi ve İngiliz bankası paranın alıcının hesabına ulaşıp ulaşmadığının, alıcının kişisel bilgisi olduğunu ve göndericiye bile söylenemeyeceğini iddia etti!
İşte bu yüzden "sistem neden çalışmıyor?" sorusundan önce "sistem neden çalışsın ki?" sorusuna cevabınız hazır olmalıdır. Bundan sonra yukarıdakine benzer yöntemle ister yazılım ister donanım olsun, sisteminizde ara ölçümler veya incelemeler yaparak hatayı teşhis etmeye çalışırsınız.
Bu sorgulamalarda tek tek her elemanı sorgulamak pek kullanışlı bir yöntem değildir. Zira sistemin çalışmasını çok iyi bilseniz bile tek tek her eleman üzerindeki ölçümlerin ne olması gerektiğini bulmak için çok kafa yormanız gerekebilir. Sistemleri blok şemalarla tasarlamak veya incelemenin avantajlarından birisi işte budur. Blok blok sorgulama yaparsınız. Problemli blok teşhis edildikten sonra gerekirse içindeki esas problem çıkaran eleman ayrıca alt sorgulamalarla teşhis edilebilir. Blok içi teşhisle uğraşmak pek ekonomik olmayacaksa o blok toptan değiştirilebilir, bozuk elektronik kartı tamirle uğraşmak yerine sağlamıyla değiştirmek gibi.
Hata, kâğıt üzerinde formüllerle yapılan bazı işlemlerde de olabilir. Burada yapılacak başlıca ara sorgulama yöntemlerinden birisi “birim doğrulama”dır. Eşitlik veya eşitsizliklerin her bir toplam terimi ve tarafları aynı birimli olmalıdır. Buna uymayan formülde hata olduğu anlaşılır. Birimlerle ilgili ayrıntılar, bu derste sonraki bir konu olarak anlatılacaktır.
Peki sorgulamanın dibine kadar ulaşıp halen sorunu teşhis edememek mümkün müdür? Mümkündür; ama sakın pes etmeyin, işte burası tecrübenize tecrübe katacağınız aşamadır. Sorguladığınız en dip eleman, teoride varsayılana uymayan davranış gösteriyorsa doğal olarak onu sağlam biriyle değiştirmeyi düşünürsünüz. Ama değiştirmenize rağmen sorun devam edebilir. İyi kurulmuş bir teori ile pratik arasında ciddi bir uyuşmazlık olamaz. Uyuşmazlık varsa teori eksik varsayılmıştır ve şimdi o eksiği giderme zamanıdır. İşte bazı örnekler:
● Teoride opampın +/- giriş uçları arasında sıfır volt gerilim olduğu varsayarsınız. Ama istediğiniz gibi çalışmayan opampın +/- uçları arasında sıfırdan farklı voltaj ölçebilir ve opampın bozuk olduğunu düşünebilirsiniz. Ama yeni opamp takınca da aynı ölçümleri alabilirsiniz. Çünkü varsayılan bu teori eksiktir. Doğrusu “normal beslenen opampın çıkışı doyumda değilse, +/- uçları arasındaki gerilim yaklaşık sıfırdır”.
● Benzer şekilde BJT’lerin beyz-emiter arasında 0,7V gibi bir voltaj olduğunu varsayarsınız; ama bunun kesimdeki BJT için geçerli olmadığını unutmuş olabilirsiniz.
● Yine benzer şekilde MOSFET’lerin geçidinden kayda değer bir akım çekilmediğini varsayarsınız; ama aslında bu DC çalışma için doğrudur. AC çalışmada ise, geçit kapasitans gibi davranarak kayda değer bir kapasitif akım çekebilir. Hatta güç MOSFET’lerini anahtarlarken geçitten ciddi değerde bir akım çekilir.
● Simetrik olmayan, Mesela 0-12V ile beslenen bir opampın alt doyumda sıfır volt vermesini beklersiniz, ama o 2V civarı bir çıkış verebilir. Çünkü ister simetrik ister tek yönlü besleyin, ki opamp bununla değil kendi uçları arasındaki voltaj farklarıyla ilgilenir, alt doyumda alt besleme voltajının “output voltage swing” kadar üstünde, üst doyumda da üst besleme voltajının “output voltage swing” kadar altında çıkış voltajı verir. “Output voltage swing” ise genellikle 1-2V civarıdır.
● Yazılımda "ve"/"veya" gibi karşılaştırmaların veya karşılaştırma sonucuna göre işlemlerin yanlış yapıldığını düşünebilirsiniz. Bu durumda şu fıkrayı hatırlayınız:
Bir yazılımcıya bir sabah karısı demiş ki “Bakkala gidip 2 ekmek al. Taze yumurta gelmişse bir düzine al”. Adam gider ve biraz sonra elinde 12 ekmekle döner. Sebebini soran karısına, “Taze yumurta gelmiş!” der.
Yani bazı mantık yorumları derleyici tarafından sizin zannettiğinizden farklı sırayla işleniyor olabilir. Bu yüzden çoklu karşılaştırmalarda veya işlem gruplarında parantez kullanmak anlam kargaşasını önler.
● Yazılımda, özellikle mikrodenetleyici yazılımında bazı çarpım hataları bulabilirsiniz. Aslında .lst dosyasını incelerseniz veya derleyici ayarlarını bilirseniz, değişkenlere ayrılan bayt veya bit sayısının sınırlı olmasından dolayı taşma olabildiğini ve üst bayt tarafından kırpıldığını anlayabilirsiniz. Benzer problem bazı hazır fonksiyonlarla da yaşanabilir.
● Simülasyon veya deneylerde alınan ölçümlerin temel sistem formüllerinden birini sağlamadığını görebilirsiniz. Bunun başlıca sebepleri, işin içine karışan ölçüm gürültüsü, parametre veya modelleme belirsizliklerine aşırı duyarlılık, veya teoride sonsuz küçük kabul edilen dt, dx gibi diferansiyel adımların simülasyonlarda yeterince küçük seçilmemesi olabilmektedir.
Bazen hata noktasını bulursunuz fakat nedenini anlayamazsınız. Hatta hatanın, hata gözlenen noktanın öncesinden mi sonrasından mı kaynaklandığına karar veremeyebilirsiniz. Böyle durumlarda hata gözlenen noktanın hemen öncesindeki veya sonrasındaki blokların veya elemanların bağlantılarını ayırarak test etmek faydalı olabilir. Eğer ayrıldıkları zaman iki taraf da sağlıklı çalışıyor, fakat bağlanınca problem çıkarıyorsa uyum problemi düşünülebilir. Birbirine uyumlu eleman veya bloklar kullanılarak bu sorunu aşmak denenebilir. Ancak geribesleme gibi etkileşimler de birlikte çalışmada sorun çıkarabileceğinden, durumu etraflıca değerlendirmeden büyük masrafa girecek denemeler tavsiye edilmez.
Burada sıralanan metotların hatayı bulmanızda ve çözmenizde yardımcı olması kuvvetle muhtemeldir. Ancak burada hesaba katılmayan pek çok hata mekanizmaları da mümkündür. Bu tecrübeler ve bilimsel yaklaşımlar ışığında düşünerek, çeşitli ihtimalleri değerlendirerek başka yöntemler de geliştirebilir, tecrübelerinizi artırabilirsiniz.
İnsanın başlıca özelliklerinden birisi hata yaparak öğrenmesidir. Önemlisi, hataların üzerine cesaretle giderek sorunu çözebileceğinize özgüven duymanızdır. Ancak özgüven, sağlam bir temeli olana yakışır. Temelsiz özgüven aldatıcıdır.