17 Ekim 2016 Pazartesi

Mühendislik temelleri üzerinde çalışılmalı!

Kimse yenilik ve buluşların hayati olduğunu reddetmiyor, ama aynı zamanda mühendislik temeller üzerinde çalışmak gerekir:
Temel kuralları, ilkeleri ve yapısı
Değerlendirme kriterleri
Karşılaştırma yoluyla
Teorik sınırlarını ve yeteneklerini belirle
Üretim araçlarını belirle
Matematiksel modeller kullan ama gerçek dünyada örnekler üzerine kullanılacağını unutma.

Sorgulanan yeni yöntemler.

"Örgün yöntemlerde matematik vardır. Doğru matematik yöntemleri süreçleri iyileştirir. Bu nedenle, biçimsel yöntemler yazılım kalitesini arttıracaktır. “
Bunun doğru olduğunu net değil!
Hangi yöntem ile yazılım geliştirilecek?
Uygulayıcıların eğitim?
Siyasi konular? Maliyeti? Ölçek?
Aracı olgunluk ve uygunluğu?
Daha iyi sonuç sistemleri var mı? Güvenli? Daha küçük?
Büyük? Daha anlaşılır?

Analogies

Buhar motorları teknolojisi kazan geliştirilme teknolojisinin gerisinde kaldı.
Yazılım ile olan ilişkisi………………………….....

Ne yapılmalı?
Zaman testleri yapılmalı ve iyi mühendislik ilkeleri kullanılmalı:
Doğrulama testleri, onaylama testleri yapılmalı. İkili ve üçlü kontrol sistemleri kullanılmalı.
Süreçleri durdurmadan süreçler üzerinde kontroller yapılmalı.

Yazılım Mühendisliği Temelleri.
Kazan patlamaların nedenleri; çok az bilimsel anlayış vardı. Benzer şekilde, Yazılım mühendisliği disiplini çok yeni ve biz hala temeller üzerinde çalışıyoruz.
İyi bir tasarım nedir?
Yazılım bileşenlerinin belirleme.
Güvenlik kritik sistemler.
Formüllerle ve resmi yöntemlerin rolü
Doğrulama ve onaylama
Sistem evrim

Sorunlar
Bilginin paylaşılmaması (Şirketlerin bilgi paylaşımlarından korkmaları.) Analitik veri yok yada çok az!!!
Bilgi teknolojisi çok hızlı ilerliyor. Bunun sonucu pek çok farklı alanda yazılımlar kullanılıyor. (İsterler artıyor karmaşıklık artıyor.)
Yazılımları kontrol etmek,değerlendirmek ve geliştirmek için çok kısa bir zamanımız var.

Buhar motorları kısa tarihi

İskenderiye’de Heron, 60 MS buhar gücünü kullanmayı denedi.
Thomas Savery ilk buhar gücü ile çalışan motoru üretti.
16-17 YY. buhar motorlarına olan ilgi arttı.
Newcomen 1700 yılında bu motorların yaygın kullanımını için bir silindir ve piston tasarladı.
1786, James Watt büyük Newcomen diye adlandırılan motoru üretti.

Bu arada İngiltere’nin kuzeyinde sanayi devrimi ile ilgili büyük bir potansiyel vardı. Watt and Matthew Boulton isimli üreticiler yeni motor tasarımlarını bu bölgede geliştirdiler (Ağır sanayi atılımı). 1800 yılında Watt’ın patent süresi sona erdi ve yüksek basınçlı buhar motorlarını isteyen herkes üretebilecek hale geldi. (HPSEs). İki tasarım geliştirildi. UK & USA. Ayrı kondansatörler yerine buharın direk pistonları itebilecek şekilde geliştirilmesi sağlandı.

İlk başarılı kullanım buharlı teknelerde oldu.
Oldukça başarılı idi.
Verimliydi, Ucuzdu.
Tekne yolculukları ucuzlamıştı.
Ekonominin büyümesini sağlamış ve tekne şirketleri bu işlerden büyük paralar kazanmışlardı.
BOOM!!!!
Buharlı teknelerdeki yolcular ve mürettabat havaya uçtu.
Tekne içerisindeki basınç miktarı olması gereken oranı aştı….

Sorun neydi?

Yeterli eğitimi olmayan kişiler tarafından kullanım.
Hızlı ve ucuz malzeme kullanımı ve üretimi.
Kötü eğitimli operatörler.
Kötü kalite kontrolü.

Niye böyle oldu?
Sadece para odaklı olarak üretim yapıldı.

Patlamadan sonra neler oldu?

USA’da akademisyenlerden ve mühendislerden oluşan bir grup. Kallite standartları belirlemeye çalıştı. UK’da Watt and Boulton  şirketi bir erken uyarı sistemi geliştirdi. Ancak geliştirdikleri bu sistemi kendi buhar motorları sistemine adapte edemediler.

Buhar teknolojisi…

Bu teknolojinin zayıf noktası (Aşhil topuğu) kazanların buhar nedeni ile patlaya bilecekleri gerçeği.
Kazan teknolojisi buharlı motor teknolojisinin gerisinde kalmış olması.
Maliyeti uygun olmayan geliştirme çalışmaları yapılmış.

Süreç içerisinde
Yüksek basıncı altında çalışabilen, korozyona ve çürümeye dayanıklı malzeme kullanmaya ne gerek var;Ar-Ge çokta önemli değil.

Sonuç

Boom!!!
Buharlı kazanlar patlamaya devam etti.
Neden?
Mühendisler hala yüksek  basınç altında kazanların ne şekilde çalışması gerektiğini bilmiyorlardı. Ayrıca tasarım mühendisleri, sistemlerinin kullanımının nasıl olacağı anlamadı: - Yükleme ortamı - Operatör eğitimi
   - Açgözlülük, aşırı ve güven.

Peki kim suçlandı?
İşciler (Operatörler)

Peki kim suçlanmadı?
Tasarım Mühendisleri

Hükümetin müdahalesi
İşler çözümlenecek garantisi verildi.
Firmalar denetlenecek denildi.

Sonuç?
BOOM!!!
Sonrasında daha fazla buharlı motor üretildi.
1817 yılında UK’da komisyon kuruldu ve buharlı motorların tehlikeleri araştırıldı.
Komite kazanların daha fazla denetlenmesine karar verdi.

Ağır Kayıp
Sadece Amerika’da 1816 ile 1848 yılları arasında.
233  Kazan patladı
2562 İnsan öldü
2097 İnsan yaralandı
Yaklaşık $3,000,000 maddi kayıp oldu.


Araştırma
Philadelphia, the Franklin Institute 6 yıl patlamalar ile ilgili araştırma yapılır. USA devleti maddi olarak destekledi.

Araştırma Sonucunda
Üretimi düzenleyen bir mevzuat komite tarafından onaylandı.
Tararım için temel bazı kurallar geliştirildi.
Ölenlerin ailelerine tazminatlar verildi.
BOOM!!!
Patlamalar devam etti.
Toplumun hükümet üzerindeki baskısı arttı.
Ve mevzuata son şekli verildi!
Nihayet, 1852 yılında, ABD kongre vapur kazanları ile ilgili ağır şartlar gerektiren bir yasayı onayladı.Bu mevzuat ağır test şartlarını da içermekeydi.
Vapur kazan patlamaları azalmaya başlar! ... ancak güvensiz HPSEs hala lokomotif ve ağır sanayide kullanılıyor.


Daha sert standartları
Daha sonra, İngiltere'de parlamento standartları geliştiren bir tasarıyı onaylar.
1905 yılında, ölümlerin sayısı HPSE azalır. 14 Türkiye 383 Amerika Birleşik Devletleri En sonunda,
USA üretim ile ilgili standartları detaylandırır  ve test işine daha fazla önem veren bir standart oluşturur.

Yazılımlarla olan ilişkisi???
Biz bilgisayar çağındayız artık.
Bunların güvenlik açısından kritik yazılımla ne ilişkisi var. Paralelik nedir? (Yazılımlar patlar mı?)

Yazılım ve Güvenliği Kritik Uygulamalar

Güvenliğin önemli olduğu pek çok yerde(Hataya tahammülün olmadığı yada çok az olduğu yerlerde), “safety-critical” güvenlik açısından kritik yazılımlar kullanmaktayız. Eğer bu yazılımlar doğru olarak çalışmaz ise çok büyük sıkıntılarla karşılaşa biliriz. 

Bu yazılımların kullanıldığı yerlerden bazıları;
Nükleer reaktörler
Uçuş kontrol sistemleri
X-ray makinelerde yazılım kontrolörleri

Güvenlik öncelikli uygulamalarda; kapsamlı testler, kod incelemesi ve yazılım geliştirme yöntemleri daha titizlikle uygulanmalıdır. Şu ana kadar yapılan güvenlik öncelikli yazılımlardaki hata oranları diğer yazılımlara oranla daha düşüktür. Fakat bu yazılımların teknolojik olarak ve ekonomik olarak geliştirilmesi daha zordur. Bu yazılımları oluşturmak yıllar sürebilmektedir.

Yazılım Hataları

Yazılım geliştirme sürecinin herhangi bir aşamasında (temel olarak analiz, tasarım, kodlama, test, bakım) yapılan insani hatalardır. Hiçbir yazılımcı veya programcı isteyerek hata yapmaz. Dolayısı ile programı kendi kendine test ederken yaptığı hatayı da görmemesi normaldir. Sıfır hatalı bir yazılım üretmek pratikte mümkün değildir. Ancak doğru hata yönetimi yaparak hata sayısını azaltabilir ve hata oluştuğunda müdahale için daha hızlı olabilirsiniz. 

Uygulama geliştirme aşamasında hatalar 3 grupta değerlendirilir:

Syntax Error – Sözdizimi Hataları
Yazılan programda programlama dili kurallarına aykırı bir takım ifadelerden dolayı karşılaşılabilecek hatalardır.  Düzeltilmesi basit hatalardır. Hatanın bulunduğu satır derleyici tarafından rapor edilir.
Günümüz IDE’lerinde bu sıkıntılar neredeyse yok denecek kadar azdır. Özelikle kod editörlerinin gelişmiş yazım denetimi sayesinde yazılımcılar söz dizimi hatalarını derlemeye gerek bile kalmadan fark edebiliyorlar. Eğer bir derlemede Syntax Error alındı ise obje kod üretilememiştir demektir.

Run-time Error – Çalışma Zamanı Hataları
Programın çalıştırılması sırasında karşılaşılan hatalardır. Programcının ele almadığı bir takım aykırı durumlar ortaya çıktığında programın işletim sistemi tarafından kesilmesi ile ortaya çıkar. Bu tip hatalarda hata mesajı çoğunlukla çalışan işletim sisteminin dili ile verilir.
Eğer bu tip hataları kullanıcı ele almışsa, program programcının vereceği mesajlarla ve uygun şekilde sonlandırılabilir. Bu tip hataların nerelerde ve hangi şartlarda ortaya çıkabileceğini bazen kestirmek zor olabilir.
Örneğin; olmayan bir dosyayı açmaya çalışmak, var olmayan bir dosyanın üzerine yazmaya çalışmak, olmayan bir bellek kaynağından bellek ayırmaya çalışmak, olmayan bir donanıma ulaşmaya çalışmak vs.

Logic Error (Bug) – Mantıksal Hatalar (Böcek)
Karşılaşabileceğiniz en tehlikeli hatadır. Programlama mantığında bir takım şeylerin yanlış düşünülmesinden kaynaklanır. Hata test aşamasında veya müşteri kullanımı sırasında ortaya çıkar.
Örneğin: Hesaplanması gereken veya bulunması gereken değerlerin eksik veya yanlış hesaplanması mantıksal bir hatadır. Bu sorunun giderilebilmesi için analiz aşamasına kadar geri dönülmesi gerekebilir. Bazen bu hatanın nereden kaynaklandığını bulabilmek çok zor olmaktadır. 
Gerek serbest yazılım gerek ticari yazılımların tümünde bug dediğimiz mantıksal hatalar bulunur.
Günümüzde en etkin yazılım firmaları bile yazılımlarında bug olduğunu kabul eder ve zaman zaman bu bugları giderebilmek için ya yazılımlarına yama yazılımlar (Update, Patch) üretirler ya da o yazılımın yeni bir versiyonunu piyasaya sürerler.

Debug (Bugdan arındırma)
Mantıksal hataları giderebilmek ve yazılımdaki hataları (bug) bulabilmek için yapılan işlemin adıdır. Genellikle yazılan programın adım adım ve denetim altında çalıştırılmasıdır.
Programın her adımında ilgili değişkenlerin hangi değere sahip olduğunu görmeyi sağlayarak anormal bir durumu daha kolay izleyip bulmanızı sağlar.






Bağlayıcı (Linker) ve Çalıştırma (Execute)

Bağlayıcı: Derleyici tarafından object dosyasına çevrilen bir veya birden çok dosyanın birbirleri ile ilişkilendirmesi ve tek bir çalıştırılabilir dosyaya (Örneğin Windows exe) çevrilmesini sağlayan yazılımdır. Çalıştırma: Oluşturulan makine dili programının çalıştırılması adımıdır.



Yorumlayıcı (Interpreter) nedir?

Yorumlayıcı, kaynak kodu kısım kısım ele alarak doğrudan çalıştırır. Yorumlayıcılar standart bir çalıştırılabilir kod üretmezler. Yorumlama işlemi aşama aşama yapılmadığı için genellikle ilk hatanın bulunduğu yerde programın çalışması kesilir. Derleyicilerin tersine kodun işlenmeyen satırları üzerinden hiç geçilmez ve buralardaki hatalar ile ilgilenilmezler. Yorumlayıcılar genelde kaynak koddan, makine diline anlık olarak dönüşüm yaptıkları için, derleyicilere göre daha yavaş çalışırlar. Ayrıca kodu iyileştirme (optimizasyon) imkanı da çoğu zaman yoktur.