BOŞLUK BIRAKMAK

Medeni tavırlar boşluk bırakmak ustalığına dayanır.

Bir kapıdan geçerken başkasına ya da bir bayana bizden önce geçebilmesi için boşluk bırakıp yol vermek ya da yaşlı bir insana otobüste yer vermek…

Konuşurken hiç kesintisiz ve yüksek sesle değil, karşımızdakinin gerek gördüğünde araya girebilişi için şans tanıyacak şekilde, zaman zaman biraz yavaşlayarak hatta durarak ve onu duyabileceğimiz şekilde hafifleyerek…

Otomobil kullanırken önümüzdeki şoförün hatalarına karşı öndeki araba ile bizimki arasında mesafe bırakarak…

Günlük hayatta ilişkilerimizde insanlara hata yapmak şansı tanımak için gerekli mesafe ve zararı telafi edecek maddi manevi payı bırakarak…

Diş fırçalarken diş macununun etkileyişi için zaman tanımak… Banyoda saç şampuanını sürüp köpürttükten sonra beklemek… Herhangi kimyasal bir işlemin gerçekleşişi için zaman tanıyarak…

İnsanlara davranışlarını açıklamaları ya da düzeltişleri için zaman tanımak…

Kendi bilinçaltımıza bilerek çözemediğimiz problemleri çözmek, ya da hatırlayamadığımız şeyleri bulup getirmek için bir an zaman tanımak, yaratıcılığımızı harekete geçirmek için sezgilerimize şans tanımak…

Kendimize zaman tanımak…

Medeni tavırlar yol vermek, yer bırakmak, mesafe bırakmak, zaman tanımak, pay bırakmak gibi nice boşluk bırakmak ustalıklarına dayanır.

Medeniyet ile boşluk bırakmak arasındaki ilişki yalnız soyut anlamda değil elle tutulur fiziki anlamda da geçerlidir, bir yaşlıya yer vermek gibi… Bunun bir başka örneği şehir planlamasında görülür. Roma ve Istanbul şehirlerini karşılaştırdığınızda: Her ikisi de Roma imparatorluğunun damgasını taşır. Bazı binalar hem işlevsel olarak hem de stil olarak aynıdır nerede ise… Günümüzde bu iki şehir karşılaştırıldığında ise, her ikisinde de eski şehirlere özgü benzer yapılaşmak görülür. Ancak günümüz Roma’sında meydanların alabildiğine genişliği şehrin o eski yapısına nefes aldıracak ‘boşluklara’ sağlar.

Bizden bir de olumlu örnek, belki pek o kadar kıymetini anlayamadığımız zaman zaman… Rumeli göçmenlerinde vardır ama sanıyorum bu adet Türk kültüründe yaygındır… Yemek yerken masadan yere kaşık düşerse ‘Yolda aç var’ denir… Masadaki her şeyin silip süpürülmemesini ve gelebilecek Tanrı misafirine de bir pay ayrılması gerektiğini hatırlatan ne güzel bir geleneğimiz… Belki hiç anlamını düşünmeden taşıya geldiğimiz…

Neden boşluk bırakmak?

Çünkü sınırlıyız… Algılayışımız sınırlı… Düşünüşümüz sınırlı… Hatırlayışımız sınırlı… Kavrayışımız sınırlı… Karar verişimiz sınırlı… Tepki gösterişimiz sınırlı…

Maddi manevi varlığımız hem miktar olarak, hem zaman olarak, hem kalite olarak, hem güzellik olarak, hem de doğruluk olarak sınırlı…İ

şte Miller 1956’da yazdığı TILSIMLI SAYI YEDİ, ARTI EKSİ İKİ:BİLGİ İŞLEYİŞ KAPASİTEMİZDE BAZI SINIRLAR adlı çığır açan makalesinde bu gerçeğe işaret ediyordu(The Magical Number Seven, Plus or Minus Two…). Şöyle bir düşününüz, kullandığımız bütün araçları, cihazları… Çamaşır makinası, ocak, buzdolabı, ütü, otomobil gibi… Yedi artı eksi iki kuralının nasıl titizlikle uygulandığını görürsünüz cihaz tasarımında…Ya da bu kuralın uygulanmadığı durumlarda, cep telefonları, TV kumandalarının nasıl insanı aşan, zorlayan, çoğu zaman sinir bozan etkileri olduğunu…

Miller bu makalesinde insan değerlendirişinde, dikkat edişinde, hatırlayışında, alglayışında ‘öğrenerek ya da sinir sistemlerimizin tasarımından kaynaklanan’ bir yedi artı eksi iki nesne sınırı olduğunu yazmıştı. Kısaca, yaklaşık en çok 6 – 7 nesneyi aynı anda görüp izleyebiliriz. Belirli koşullarda yapılan deneylerde en çok 6 – 7 şeyi hatırlayabiliriz, gibi…

Miller kuralı özellikle bilgisayar arayüzlerinin tasarımında kullanılır. Örneğin, dikkat edilirse rahat kullanılan programlarda, menu maddeleri hem yatay olarak hem de düşey olarak 6-7’yi geçmez. Geçtiği programlar vardır ama onları kullanan insanlar genel kullanıcılar değil daha çok uzman kişilerdir, örneğin Rational ile Lotus’ü karşılaştırabilirsiniz… Bir de donanımsal örnek, evinizdeki ocak-fırın ile bir pilotun önündeki kumanda panelellerini karşılaştırınız…

Bilgisayar arayüzlerinde çoğu zaman örneğin menu maddeleri 6 – 7’den çoktur. O zaman gruplamak(clustering) yoluna gidilir. Örneğin print ile ilgili menu maddeleri tek bir print menüsünde gruplanır… Miller sözkonusu makalesinde gruplamağı yeniden kodlayış(recoding) olarak adlandırır. ‘Giriş bilgisini gruplayışın ya da girişler dizisini birimlere ya da öbeklere(chunk) ayırışın önemini anlamalıyız.’ Mors kodu öğrenen bir insan ilk önce her dit – dat’ı ayrı bir bütün olarak algılar. Bir süre sonra onları harf olarak duymağa başlar. Daha sonra giderek harfleri de aşar ve doğrudan kelimeleri duymağa başlar… İletişim teorisi ağzında buna yeniden kodlamak denir.Printle ilgili bütün menüleri koymak yerine yalnız print anamenü maddesini koymak insanın yeniden kodlama eğilimine paraleldir.

Tabii, sınırlar yalnız algılamak, izlemek, hatırlamak, karar vermek konusunda değil…

Gönül ister ki, şimdi E5’e çıkıp hiç durmadan 150 ile gazlayabilelim… Ya da 200 ile, 300, 350 ile gazlayabilelim… Ya da akşam 5 bardak su ya da içen için rakı içebilelim… Hatta 9 bardak, dahası 12, 15, 20 bardak… İyice azdım… Denize gittiğimizde, hiç nefes almadan, bir saat suyun altında kalabilelim… Biraz da entel takılalım… Kitapçıya gittiğimizde, beğendiğimiz bir kitabı, en ufak ayrıntısına kadar, oracıkta ayakta 15 dakikada, sonuna kadar okuyabilelim… Zaman biraz tehlikeli gerçi ama… Zamanı istediğimiz hızda yaşayabilelim… İstediğimiz zaman uzatalım, istediğimiz zaman kısaltalım…

Son olarak, istediğim kadar uzun yazabileyim ama okuyucularım bir bakışta yazının uzunluğuna ve yoğunluğuna göre kapasitelerini ayarlayarak zevkle yazılarımı okuyabilsinler…

Evet, yazımın başında belirttiğim gibi,

Medeni tavırlar boşluk bırakmak ustalığına dayanır.

Çünkü sınırlıyız.

Çünkü var olan herşey sınırlı.

Evet, medeni tavırlar boşluk bırakmak ustalığına dayanır.

Çünkü medeniyet sınırlar içinde, sınırlara karşın ve gerektiğinde onları var ya da yok kabul ederek yaşamak ustalığıdır.

KISACA IEEE/EIA 12207 YAZILIM YAŞAM DÖNGÜSÜ SÜREÇLERİ STANDARDI NE YAPAR?

IEEE/EIA 12207 ABD Savunma Bakanlığı tarafından 1998’de kabul edilerek MIL-STD-498’in yerini aldı. Üç kısım halinde düzenlenmiştir:

IEEE/EIA 12207.0, Bilgi Teknolojisi Standardı-yazılım yaşam-döngüsü süreçleri. ISO/IEC 12207’yi özgün şeklinde ve altı eki ile birlikte içerir.

IEEE/EIA 12207.1, Bilgi Teknolojisi Standardı - yazılım yaşam-döngüsü süreçleri –Yaşam döngüsü verileri. Yaşam-döngüsü verilerinin kayıt edilişi için ek yönlendirim sağlar.

IEEE/EIA 12207.2, Bilgi Teknolojisi Standardı - yazılım yaşam-döngüsü süreçleri –Gerçekleştirim değerlendirişleri. Yaşam-döngüsü süreçlerinin ABD’de uygulanışından çıkartılan ekleyişler, seçenekler, ve açıklayışlar sağlar.

ISO/IEC 12207 Ne Yapar?ISO/IEC 12207 tüm yazılım yaşam-döngüsünün önde gelen süreçlerini, bunların birbirleri ile arayüzlerini ve etkileşimlerini düzenleyen üstdüzey ilişkilerini anlatır. Şekil 1 (fSingh [1]’den) onun içeriğini özetler.

Şekil 1 kuruluşların (genellikle) bir sözleşmenin parçası olan projeler aracılığı ile yazılım temin ettiklerini ve alım, tedarik, geliştirim, işletim ve bakım ile ilişkili faaliyet ve görevler yaptıklarını gösterir. Bunu yaparken, projeler birleşik gözden geçirimler, denetimler, kalite güvencesi, ve doğrulayış ile geçerlik kontrolü süreçlerini de gerçekleştirirler. Aynı zamanda belgeleyiş, kurulum-dağılımı yönetimi, sorun çözümü ve ihtiyaç uyarlayışı süreçlerini de uygularlar. Bu arada, kuruluş gerekli geliştirim altyapısını ve proje elemanlarına eğitim sağlayarak ve projenin yazılım sürecini iyileştirerek projeyi yönetir. Bu alt-parça süreçlerin ve Şekil 1 ‘deki ilişkileri ISO/IEC 12207 teknik içeriğinin kuşbakışı bir özetini sağlamaktadır.

Şekil 1. ISO/IEC 12207’nin teknik içeriği.

Şekil 2. Yazılım Yaşam-döngüsü Süreçlerinin Farklı Bakışaçılarından Görünümleri.

Şekil 2 (Singh [1]’den ) süreçlerin bir çok farklı bakış açısını göstermektedir. Şekil 2’nin ileri sürdüğü gibi alımcılar ve tedarikçiler yazılım geliştirimini sözleşme bakış açısından görürler. Bir alımcı ve bir tedarikçi arasında yazılım tedarik etmek amacı ile bir sözleşme ilişkisi oluştuğunda tedarik süreci başlar. Sözleşmenin koşullarına bağlı olarak, tedarik süreci yeni yazılım geliştirmek için geliştirim sürecini kullanabilir, yazılım işletim hizmetleri sağlamak için işletim sürecini, veya yazılımı onarmak ve iyileştirmek için bakım sürecini… Bu şekil aynı zamanda işleticiler ve kullanıcıların, geliştirici ve bakımcıların, ve diğerlerinin yaşam-döngüsüne ilişkin kendi ayrıcalıklı bakış açılarına sahip olduklarını gösterir.

Kaynaklar:
1. Singh, Raghu, "Introduction to International Standard ISO/IEC 12207: Software Life Cycle Processes," tutorial slides, Oct. 2, 1995.
2. Jim Wells, Software Engineering Process Office at SPAWAR Systems Center San Diego

“MÜDÜRÜM, DAYANAMIYORUM, BENİ HASTAHANEYE GÖTÜRÜN!”

VÜCUT BULUŞ ve KULLANICI ARAYÜZÜNÜN İNSAN SAĞLIĞINA ETKİSİ
(EMBODIMENT and EFFECT of USER INTERFACE on the HUMAN HEALTH)

Ali Rıza SARAL

Hiç kimse acı çekmek istemez! Hiç kimse yaptığı iş nedeniyle hastahaneye düşmek istemez. Yine de her yıl dünyanın her yerinde çok sayıda itfaiyeci, doktor, asker, mühendis, öğretmen, hava trafik kontrolcüsü müdürüne bu yazının başlığındaki sözleri söylemek zorunda kalır. BBC’de ilk jet motorunu yapan Whitney ile ilgili bir dizi seyretmiştim. Whitney’in bir yaştan sonra aktif mühendisliği bıraktığını anlatırken ‘her başarılı mühendisin karşılaştığı stress vb. aşırı zorlanmaların psikolojik sağlığını bozduğunu’ ifade etmişlerdi. Üstelik Whitney makine mühendisi idi ve daha o zamanlar Yazılım Mühendisliği yoktu…

Maastricht Hava Trafik Kontrolü merkezinde ~3oo Hava Trafik Kontrolörü çalışır. Her yıl %1’i zihinsel sağlık problemleri ile iş göremez hale gelir. EUROCONTROL’ün doktoru Herr VERMEIREN’e göre hastalanan kişiler işe başlamadan önce sağlık kontrolünden geçerler ve başlangıçta tam sağlıklıdırlar. Benzeri bir durum Yazılım mühendisleri ve öğrencileri için geçerli. Bir Bilgisayar bölümü Başkanı tanıdığım, zihinsel sorunların ne kadar sık karşısına çıktığından yakınmıştı…

Bazen işi başarmak her şeyden önemli olabilir… Örneğin askerlik, itfaiye gibi fedakarlık ya da kahramanlık gerektiren durumlar… Bazen risk alınmadığı halde bakarsınız ekibinizde insanlar hastalanmağa sonra da intihar etmeğe ya da kasıtlı olmayan trafik kazaları geçirmeğe başlarlar…
Hiç kimse acı çekmek istemez! Fakat işin bireysel ya da ekip olarak yapılış şekli, yürütülüş mantığı tatsız sonuçlar doğurabilir, mühendislikte…

Her insanın genel bir kişiliği var. Eğer dikkatli bakılırsa bu kişilik aslında birden çok kişiliğin bileşkesinden oluşur. Baba, mühendis, oğul, arkadaş, vatandaş, ahbap, oynadığımız tüm rollere ait, bazan benzer bazan çok farklı kişilikler… Aynı kişinin mühendisliği ile yöneticiliği bile farklı kişilikler taşıyabilir… Sorun bunların varlığı değil yeri ve zamanı, yanlış bağlamlarda etkilerinin devam edişidir.

Bir eş hem kendisinin hem de eşinin ondan beklediği, ona aktardığı, onunla paylaştığı herşeyin, kısaca kendisinin ve eşinin kafasında var olan eş oluş bilincinin vücut buluşudur (embodiment). Bir mühendis te öyle… Ona okulda öğretilen, sonra iş hayatında kazandıklarının eklendiği mühendisliğe ilişkin her şeyin bir vücut buluşudur mühendis.

“Vücut buluş bir vücut içinde yaşamak süreci ya da durumudur.” Her bir vücut buluşun canlı bir nesneye ait olması gerekmez… Var olan her nesne bir vücuda sahip olabilir ve böylece belirlenebilir bir kimliğin vücut buluşu olabilir… İnsanın farklı bağlamlarda farklı kişiliklere sahip oluşu, bir nesnede birden çok şeyin vücut bulduğu durumdur. Bisiklete binen insan durumunda ise iki nesnenin oluşturduğu bütünlük, tek bir vücut buluşun, bisiklete binen insanın gerçekleşişidir. (Bkz 2)

Önemli bir sorun mühendisin mesleki olan kişiliğinin mesai bitiminde iş yerinde kalmayışı… Kalamayışı… Hatta proje planlayışında yapılan ‘hatalar’ yüzünden çok uzun sürelerle gece geç saatlere kadar çalışılışı… Mühendisin bir çok kişilikleri arasında var olan doğal dengenin bozuluşu…

Aslında bu ve benzeri sorunlar yalnız mühendislere özgü değil. Örn. bir cerrah olan GATTI(Bkz 3), cerrahi araçların giderek cerrahın gözünde saydamlaştığını ve görünmez hale gelip neredeyse onun vücudunun doğal bir parçası haline geldiğini yazar. GATTI makalesinde vücut buluş deyimini vücudumuzun sınırlarının yapısı olarak, ya da çevremiz ile temasımızı düzenleyiş şeklimiz olarak tanımlar. Zaman içinde sabit kalan bir vücudumuz yoktur, ya da dünya ile iletişimimizi yalnız çıplak vücudumuz ile kurmayız. Fakat, çok sıklıkla uygun arayüzler kullanırız, vücudumuzun sınırlarını değiştiren ve böylece bizim ile çevremiz arasındaki etkileşimi değiştiren arayüzler…

GATTI bu makalesinde mesleki amaçlı araç kullanımı ile ilgili olarak şu önemli uyarıyı yapar: “Alteration of our embodiment has strong consequences both on our sense of our self (Clark, 2003) and on the mechanisms of collecting and processing of information. A change in the structure of the boundaries of our body means a change in the structure of the boundaries of our mind”. yani; “Vücut buluşumuzun değiştirilişi hem kendi benlik duygumuz (Clark, 2003) hem de bilgi toplayış ve işleyiş mekanizmalarımız üzerinde güçlü sonuçlar doğurur. Vücudumuzun sınırlarının yapısında ki bir değişim zihnimizin sınırlarının yapısında bir değişim anlamına gelir”. GATTI bu makalesinde ‘laparoscopic video-surgery’yi cerrahide vücut buluşun değişime uğradığı bir durum olarak ele alır.

Mesleki amaçlarla kullandığımız araçlar, ustalığımız arttıkça vücudumuzun doğal bir parçası haline gelir, ama bu durum zihinsel yapımızda da küçümsenmeyecek değişimlere neden olabilir. Son on yılda, Yazılım mühendislerinin kullandıkları mesleki araçlar, RAD – Rapid Application Development Tool ya da IDE’ler - Integrated Development Environment gibi araçlar, çeşitli framework, kütüphaneler, DLL’ler vb. bir çok olanaklar açtı. Örneğin IBM Rational ’in çalışma masası ortamı bir çok olanaklara sahip. Bu araçların tasarımında, Miller’in yedi artı eksi iki kuralı çoğu kez kenara bırakılıyor… Karmaşıklığı yenmek için görsel olanaklar, spatial-konumsal boyutta sonuna kadar zorlanıyor… Ekranlar, kullanıcının seçeneğine bağlı olarak alabildiğine çeşitli parametrelerle doldurulabiliyor…

Yazılım mühendisi yalnız görsel algılayış açısından, büyük workstation’lar tarafından zorlanmakla kalmıyor… Yazılımcının uğraştığı programların karışıklığı ve boyutu da çok artmış durumda… Bu güçlüklerle baş edebilmek için yazılımcı görsel imkanlardan başka bir işletim sistemi gibi TODO, NOTES vb. Loglar, günlük işlerle ilgili küçük stack’ler, neyi ne kadar sürede yaptığının kayıtlarını tutmak durumunda… Son 1-2 senedir IDE’lere bu tür hazır log imkanları eklenmeğe başlandı. ISO12207, MIL498 gibi yazılım yaşam-döngüsü standartlarının yanlış uygulanışından kaynaklanan ‘zorunlu’ fakat gereksiz belgeleyiş çalışmaları da cabası…

“Protez cihazları vücudumuzun sınırlarını genişletir. Bu cihazlar tenimizin sınırlarından öteye bir devamlılık sağlarlar.” (Carolien HERMANS, 2002, Embodiment: the flesh and bones of my body). “BirVÜCUT ŞEMASIı bilinçaltı seviyesinde çalışır. Vücudun şeklini ve duruşunu (farkına varılmadan) kayıt eder. Kişinin vücut kısımlarının anlık durumlarını kayıt eder.”.

Rational gibi ‘mühendislik harikası’ IDE’ler ya da bileşik geliştirim ortamları yazılımcının elle yaparsa çok uzun sürede yapabileceği zihinsel işleri kolaylaştırır ve çabuklaştırır. Bir protez cihaz olarak yazılımcıların kullandığı IDE araçları onların zihinsel kapasite sınırlarını da geliştirir, yapılışı düşünülemeyecek şeyleri mümkün kılar. Burada IDE’nin aştığı güçlük zihinde tutulan şeylerin miktarı ve zihinde tutuş süresinin sınırlılığıdır. Ustalaşan bir yazılımcının kullandığı IDE giderek yazılımcının ‘vücut şemasının’ doğal bir parçası olur.

IDE araçları ile yazılımcının kapasitesinin artışı işleri azaltmaz. Aslında ileri IDE’lerin gelişitirilişinin nedeni yazılımcının yükünü azaltmak değil, tarihsel olarak donanımın çok ucuzlayışı sonucunda, yazılım karışıklığı ve büyüklüğünün artışı... GATTI’nin çaldığı uyarı çanlarının önemi burada ortaya çıkmakta... Büyük sistemlerde ya da yetersiz insan kaynakları ile küçük sistemlerde geliştirilen yazılımlarda, proje içinde öyle bir an gelir ki 1-2 kişi farkında olmadan, olamadan zihinsel tehlikeli bir eşik noktasını, hastalık noktasını geçerler.
Sorun üstünde çalışılan yeni ve karmaşık sistemlerin ve bunları geliştirmek için kullanılan araçların gerektirdiği mesleki kültürün henüz oluşmamış olmasıdır. 1980’lerin Quick Basic ya da FORTRAN’ı ile günümüzün C++, ADA ya da internet programlayışta kullanılan Csharp Visual Studio .NET ya da J2EE IBM Rational JAVA’sı ya da CORBA gibi framework’leri arasında karmaşıklık ve teknik imkanlar açısından dağlar kadar fark var.

Son 30 yılda HCI–insan bilgisayar etkileşiminde gerçekleşen gelişimlere karşın ve uluslararası eğitim standartlarında belirtilişine karşın hala ülkemizde sürekli olarak HCI dersi açan bir üniversitemiz yok(2004). Neurolog Bülent MADİ bir seminerinde son 10 yılda psikoloji alanındaki atılımların daha önce yazılan her şeyin yeniden düşünülmesini gerektirecek büyüklükte olduğunu söylemişti. HCI dersleri karmaşık–büyük sistemler (LARGE SYTEMS–COMPLEX SYSTEMS) için mühendis yetiştirilişinde hayati önemdedir. Dileğim hiç değilse BİLKENT üniversitesinin bu konunun da önemini görüp gerekli atılımı yapışı...

Büyük sistemlere bakıldığında da görülür ki operatörlerin altına girdikleri zihinsel yükün ölçüldüğü workload analysis çalışmaları son 5 – 10 yıldır yapılmakta(akademik)... Dünyadaki genel amaçlı bütün hava trafik kontrolü sistemlerinden hiç birinde kontrolör yükünü takip, gözetim ve kayıt işlemi yapılmamaktadır. Kanuni kayıtlarda(legal recording) sistemin her türlü bilgisi, uçuş sayısı, mesajlar, yükseklikler, planlar, bunların sayıları ve değişiklikleri kayıt edilmekte. Ama bu verilerden ayrık olarak kontrolörün iş yükünü çıkartan, bunları kişi bazında günlük haftalık döken programlar, deneysel amaçlı bir kaç öncül çalışma dışında yok. Daha kötüsü, gerçek zamanda, merkezi gözetim masasında oturan yöneticilerin kullandığı tümleştirici fonksiyonlar genel trafiğin radar görüntüsünden öte kontrolörlerin yükünü yalnız işe değil işi yapana göre de belirleyen tümleşik fonksiyonlardan yoksundur. Merkezi masada oturanlar ‘havayı koklayarak’ durumun tümleşik bir ‘izlenimini’ edinirler. Tabii bu ‘kokuyu’ kanuni olarak kayıt etmek mümkün değil...

Çoğu kez sorun, belirli bir işi yapmak için karmaşık bir IDE vb aracın seçilişi fakat bunun getireceği zihinsel yükün hesaplanmayışıdır. Bu tür yazılım araçlarında, yazılım mühendisinin üzerine binen yükü ölçen kolaylıklar henüz yok. Örn. gerçek çalışma süresi, kaç defa tuşlara basılmış, ne kadar compile edilmiş vb… Bu yüzden ne kadar sürede ne miktar iş yaparsanız uyarılışınızı gerektirecek, yoruluş sınırı, hastalanış sınırı gibi sınırlar henüz bilinmiyor. Bu sınırların belli olmadığı ve mühendislerin iş yükünün kontrol edilemediği günümüz yazılım dünyasında da çoğu kez FARKINDA OLMADAN, OLAMADAN sağlık sınırları aşılıyor. Biz ancak ekibimizde birisi hastalanınca ya da farkında olmadan trafik vb ciddi bir kazaya uğrayınca sanki bir şey ters gidiyor ya da ‘Abi bir uğursuzluk var’ anlayışına ulaşıyoruz.

Günümüz yazılım projelerinde büyüklük ve karmaşıklık ekip büyüklüğünün ve proje süresinin doğru belirlenişini güçleştirmekte... Bazı işler var ki bölemezsiniz. Eğer bölerseniz iş uzar ve kalitesi düşer. İşin karmaşıklığı fazla sayıda adam kullanmak şansınızı yok edebilir. Yazılım projelerinde süre tahmini yapmak o kadar güçtür ki örn. hava trafik kontrolünde bir iş öngörülenin iki misli kadar uzarsa bu normal karşılanır. Ayrıca ekonomik olarak elemanların ömür boyu ya da uzun sürelerle çalışması devri de geçmiştir. Yeni tanışılan mühendislerin kapasitesinin doğru belirlenişi güçtür. Bütün bu unsurlar yazılım mühendislerinin iş yükünü ölçen kolaylıkların yazılım araçlarına ve configuration management gibi tümleştirici yönetim araçlarına eklenişini zorunlu kılmaktadır. Change management, configuration management gibi harika araçlarımız var. Ama bunlarla bütünleşik, o programları yazanların durumlarını kontrol eden iş yükü yönetimi araçlarımız yok, henüz…

Hiç ORACLE için yazılmış gerçek bir karışık SQL komutu gördünüz mü? RENAULT Öneri Takip Sistemi için Rational RAD aracı ile bunlardan bir miktar yazdım… Tek bir SQL statement bu sayfadaki paragraflardan uzun olmak zorunda kalabiliyor işin gereği… Sonuç, uzun süreli olarak aşırı konsantre olmak zorundasınız… Düşünme şekliniz bugün ne giyeyim kravat takayım mı yüzeyselliğinden farklı bir boyut ve derinlikte olmak zorunda… Karlsruhe’de çalıştığım sistemde 800 bin satırlık bir problem alanında konusu sık sık değişen işletimsel yetersizlikleri(operational deficiency) düzeltmek zorunda idim. Bir dönem her gün yalnız aynı elbiseyi giydiğimi sonradan bir dostuma anlatmıştım. O da cerrahlar da farklı değildir demişti. Evde kullandıkları eşyaları hep aynı yere koyarlarmış… Uzman kişilerin kullandıkları araçlar, GATTI’nin de belirttiği gibi onların zihinlerinin çalışma şeklini değiştirirler.

“Protez cihazları vücut şeması içine emilip sindirilir. Tıpkı bir marangozun elindeki çekicin onun vücut şeması içine emilmesi gibi herhangi bir sanal vücut kısmı ya da arayüzü (klavye, fare, oyun sopası) vücut şemasının bir parçası haline gelebilir geçici ya da UZUN SÜRELİ olarak…”(Carolien HERMANS, 2002, Embodiment: the flesh and bones of my body).

VUCUT BULUS VE INSAN MAKINA ETKILESIMI adlı yazımda da belirttiğim gibi: Kazalar bileşik kimliklerin vücut buluşlarındaki bozukluklar yüzüden olur. Eğer bileşik kimlik yani kullandığı gelişmiş yazılım aracı ve elindeki iş ile bütünleşmiş ‘çalışan mühendis’ baskın hale gelirse, bir hedefe ulaşmak saplantısına kapılırsa ve bu durum elindeki işin ve bir baba, bir eş, bir oğul, sade bir insan olarak kendisinin ayrı ayrı yetenek ve sınırlarının unutulmasına neden olursa, bu sefer bileşik kimlik yüzünden bir kaza oluşur. Mühendis, bir insanın sağlıklı olarak iş yapabilmek sınırlarını farkında olamadan aşar. Rol oynarken kimlikleri şaşırmak ya da onları unutmak bileşik kimliğin başarısızlığına neden olur.

Başarılı mühendis iş yapmak için oluşturduğu teknik kişiliği ile kendinin diğer kişilikleri arasında ve güdüsel ön sınırlar dahilinde(prenoetic) en ideal dengeyi bulabilen kişidir.
Hiç kimse acı çekmek istemez! Ama hastahaneler de pek boş kalmıyor çeşitli nedenlerle…

“Olgusal teorisyenler (içinde yaşanılanı ve onunla tecrübe kazanılan) öznel vücut ile (gözlenen ve bilimsel olarak incelenen) nesnel vücut arasında ayrım yaparlar. Yaşanan vücud akıcı ve öngörerek yansıtıcı bir şekilde dünya ile içli dışlı olan birvücut bulmuş bilinç’tir. Günlük faaliyetlerimizle iştigal ettikçe, VÜCUTLARIMIZIN BİLİNCİNDE OLAMAMA ve onları hazır bulmak eğiliminde oluruz – sessizlik-içinde-iletilen-vücut (Jean-Paul SARTRE, 1943, Being and Nothingness)”.

Sorun mühendisin kullandığı araçların giderek onun “ vücut şemasının bir parçası haline gelişi”’dir.
Mühendis bir noktadan sonra yaptığı işin zorluğunu hissetmemeğe başlar. Oysa yapılan işin zihinsel yükü mühendisin algıladığı kadar hafif olmayabilir. Kullanılan araçların ‘ mükemmelliği’ ayrıca projede yapılan iş yükü tahminlerinde yanlış bir güvenlik duygusuna-false sense of safety kapılınmasına neden olur. Mühendisin bireysel sağlık riski sınırını geçtiğini fark etmeyişi yanında, sistem de proje planlaması sırasında yapılmış hatalar ya da çarpıklıklar içerebilir.

Yeni geliştirilen üretim araçları yazılım mühendisine ya da her türlü karmaşık sistem operatörüne eşsiz yetenekler kazandırmakta. Ancak bunların kullanıcı üzerinde yaptıkları etkiler sonradan edinilen tecrübeler ile öğrenilmekte… Kullanıcıların bu yeni duruma göre yetiştirilip eğitilişi ise ancak çok sonradan gelmekte… Oysa yeni yetenekler kazanan kullanıcılar bunlara uygun pedagojik psikolojik donanımlarla en kısa sürede donatılmalılar…

Bunun mümkün olmadığı durumlarda ise, örneğin büyük sistemlerde çalışan yalnız operatörler değil, operasyonel sorumluluk taşıyan herkes düzenli sağlık–psikolojik kontroller altında tutulmalı… Unutmayınız, günümüz imkanları ile bir psikiyatristin yeni bir hastasını tanıyışı 2-3 yıl zaman almakta. Eğer yaptığınız iş sizi zorluyorsa ya da zorluyabilecek bir iş ise, iyi bir doktor bulup onun öngöreceği sürelerle sohbete gitmenizi kuvvetle tavsiye ederim. Bu biraz Yahudi iş adamlarının ince ve cesur sağduyusuna benzer: İş sözleşmesi yapmadan önce, sözleşmeyi bir avukata götürünüz… Eğer iş batarsa en azından sizi savunacak bir kişi yanınızda olur(4)…

Son sözüm, ‘mühendis’lik mesleğinin vücut-buluşuna: Bütün kalbiyle çalışmak, büyük işler becermek vb saflıklarla insanları yetiştirmeği bırakınız. Mühendis çalışırken, kendi yanına oturup kendisini seyredebilen, yaptığı işin rasyonelliğini soruşturabilen meslek erbabıdır.

KAYNAKLAR:
1- Alberto Gatti :Sensing and Thinking through Technological Tools: The Impact on Cognitive Processes of a Change in the Organization of the Boundaries of Body. The Case of Laparoscopic Video-Surgery, Department of Philosophy and Social Sciences, University of Siena
2- Ali Rıza SARAL : VUCUT BULUS VE INSAN MAKINA ETKILESIMI, http://akademi.cizgi.com.tr/categories.aspx?id=30
3- Ali Rıza SARAL : FARKLILASAN BEYIN, http://akademi.cizgi.com.tr/categories.aspx?id=30
4- Avukat Mithat KORA’dan duydum.

ISO 12207 ve İlgili Yazılım Yaşam-Döngüsü Standartları

ISO 12207 ve İlgili Yazılım Yaşam-Döngüsü Standartları (1)

By Ali Rıza SARAL

ISO 12207’nin Kısa Tanıtımı

ISO12207 proje fikrinin ortaya atılışından projenin işletimden kaldırılışına kadar geçerli olacak yazılım yaşam-döngüleri için bir çerçeve-yapı önerir. Alım ve sağlayıcı rollerini dikkate aldığından özellikle alımlar için uygundur. Aslında, bu standart bir anlaşma ya da sözleşmenin geliştiriş, bakım, veya bir yazılım sisteminin işletilişini tanımladığı durumda her iki tarafın kullanımı için tasarlanmıştır. Ticari-raftan-alım yazılım ürünlerinin tedarikinde geçerli değildir.

ISO 12207 offers a framework for software life-cycle processes from concept through retirement. It is especially suitable for acquisitions because it recognizes the distinct roles of acquirer and supplier. In fact, the standard is intended for two-party use where an agreement or contract defines the development, maintenance, or operation of a software system. It is not applicable to the purchase of commercial-off-the-shelf (COTS) software products.

ISO 12207 ayrıcalıklı bir yaşam-döngüsü modeli veya yazılım geliştiriş yöntemini şart koşmaktansa her tarafın kabul ettiği deyim dağarcığını kullanarak bir süreçler dizi - yapısı sunar. Görece yüksek-seviyeli bir doküman olduğu için, 12207 bu süreçleri içine alan faaliyetlerin ve görevlerin ayrıntılarını belirlemez. Belgelerin, isim, biçim ve içeriklerini de önceden belirlemez. Bu yüzden, 12207’yi uygulamak yollarını arayan kuruluşlar bu ayrıntıları belirleyen ek standartları ve işlem süreçlerini kullanmak isteyebilirler.

ISO 12207 provides a structure of processes using mutually accepted terminology, rather than dictating a particular life-cycle model or software development method. Since it is a relatively high-level document, 12207 does not specify the details of how to perform the activities and tasks comprising the processes. Nor does it prescribe the name, format, or content of documentation. Therefore, organizations seeking to apply 12207 may want to use additional standards or procedures that specify those details.

ISO 12207 beş “ana işlem süreci” tarif eder – alım, tedarik, geliştiriş, bakım, ve işletim. Bu beş süreci “faaliyetlere” böler, ve faaliyetleri “görevlere” böler ve gerçekleştirilişleri üzerine şartlar koşar. Aynı zamanda sekiz tane “destek işlemi süreci” belirler – belgeleyiş, kurulum yapısı yönetimi, kalite güvencesi, doğrulayış, ortak inceleyiş, denetleyiş ve sorun çözüş – ve bunun yannda dört “kurumsal süreç” – yönetim, altyapı, geliştiriş, ve eğitim.

ISO 12207 :
primary processes: acquisition, supply, development, maintenance, and operation.
supporting processes: documentation, configuration management, quality assurance, verification, validation, joint review, audit, and problem resolution
organizational processes: management, infrastructure, improvement, and training.

Bu ISO standardı, kuruluşların yukarıda analatılan 17 işlem sürecini kendi projelerinin kapsamına uyacak şekilde uyarlamaklığını ve uygulanışı mümkün olmayan bütün faaliyetleri çıkartışını öngörür. O, 12207 uyumluluğunu, bu standardı uyarlamak için seçilmiş olan süreçleri, faaliyetler ve görevlerin başarısı olarak tanımlar…

The ISO standard intends for organizations to tailor these seventeen processes to fit the scope of their particular projects by deleting all inapplicable activities; and it defines 12207 compliance as the performance of those processes, activities, and tasks selected by tailoring.

Yaşam-Döngüsü Standartlarının Evrimi

ABD Savunma Bakanlığı kritik-görev çevreleri tarafından kullanılan DoD-STD-2167A ve bilgi işlem çevreleri tarafından kullanılan MIL-STD-7935’i birleştirip MIL-STD-498 adlı tek bir yaşam-döngüsü standardı yaratmak görevini üstlendi.

The Department of Defense - DoD undertook an effort to unify DoD-STD-2167A (used by the mission-critical community) and MIL-STD-7935 (used by the information systems community) to create one life-cycle standard--MIL-STD-498.

Tam 498 kabul edilmek üzereyken, nasılsa, ABD Savunma Bakanlığı tedarik politikalarını ticari standartlara dayanışa yönlendirdi. Sonuçta, 498 iki yıllık bir ara dönem için kabul edildi. IEEE ve Electronics Industry Association (EIA) 498’in yerine geçecek ticari bir eşdeğer üzerine ortak çaba başlattı. Bu çaba iki isimli tek bir standart ortaya çıkardı: bir IEEE Trial Use Standard 1498 ve bir EIA Interim Standard 640. American National Standards Institute (ANSI) bu belgeyi ANSI Joint Standard 016 olarak adlandırdı.

Just as 498 was nearing approval, however, the DoD shifted its acquisition policies toward more reliance on commercial standards. As a result, 498 was approved for an interim period of only two years. The IEEE and the Electronics Industry Association (EIA) then initiated a joint project to create a commercial replacement for 498. This effort produced one standard with two names: an IEEE Trial Use Standard 1498 and an EIA Interim Standard 640. Since both the IEEE and the EIA produced the standard, the American National Standards Institute (ANSI) designated the document as ANSI Joint Standard 016.

Bu arada, ISO12207 de yol almaya başlamıştı. J-016 yalnız geliştirmek sürecini ele alırken, 12207 yukarıda belirttiğimiz dört ana süreci de ele aldı. Dahası, 1992de, IEEE geliştiriş ve bakım faaliyetlerini ve bunların bağlantılarını sağlayan kendi yaşam-döngüsü standardını, 1074’ü tamamlamıştı. İlke olarak, 1074’ü kullanarak J-016 veya 12207’nin koşullarını sağlayan süreçler inşa edebilir. Şu anda yapmak gereken şey bu standartları ‘uyumlu’ kılmak ya da tek bir standart halinde birleştirmek.

Meanwhile, ISO 12207 was also underway. Whereas J-016 defined only the development process, 12207 described four additional primary processes, as discussed above. Furthermore, in 1992, the IEEE had completed its own life-cycle process standard, 1074, providing detailed descriptions of development and maintenance activities as well as their connections. In principle, one could use 1074 to construct processes that would comply with the requirements of either J-016 or 12207. The challenge now is to "harmonize" or otherwise converge these three different documents.

Kaynaklar :
1- Jim Moore, ISO 12207 and Related Software Life-Cycle Standards

STANDARTLARI UYGULAMAK

Yazılım müşterisi açısından işin özü şu. “Öngörülen süre içinde çalışır durumda teslim edilen bir proje başarılı bir projedir”. “Başka hiçbir şey, hiçbir doküman, hiçbir hizmet bunun yerini alamaz”. “Müşteri işinin görülmüş olmasına ve kendi üretim sürecinin başarılı akışına bakar, yoksa harika bir yazılım sistemi sahibi olmak ancak özel olarak hobi türünden meraklı bir müşteri için belirleyici”.

Yazılım üreticisi açısından: “İşin alınması yapılıp bitirilişinden önemlidir”. “Ülkemizde piyasa derinliği az olduğundan az sayıda büyük proje için çok sayıda yazılım firması rekabete girmekte. Bu durum ihalelerde aşırı fiyat düşüşüne neden olmakta, sonuçta değil standartların gerektirdiği üretim süreçlerini uygulamak, üstlenici firmalarda, iş yerini bulsun diye dökümantasyon yazdırtacak bütçe bile kalmayabilmekte”. Hele müşteri özel olarak dükümantasyon istemeyi akıl edemiyorsa, üretim sürecinin doğal bir parçası ve ürünü olarak değil, çalakalem program yazılmakta…

Yazılımcı firmalar açısından: “Nakit akışını sağlamak hayatidir”. “Bir proje ihalesi alındığı zaman gelen nakit genel bütçeye akmakta, nakit akışını sürdürme kaygısı, her çıkan fırsatta yeni yeni projeler yüklenilmesine neden olmakta… Şirketin ayakta durması yapılan işlerin kalitesinden daha önemlidir”…

“Proje süresi her iki taraf açısından gerçekte olmaklığı gerekenden daha kısa olmak zorunda. Müşteri genelde planlayıştaki ya da gereksinim belirleyişteki teknik güçlükler yüzünden ihaleyi belirlemekte ve sonuçlandırmakta gecikir. Yazılım firması ise çok sayıda proje ile uğraştığından ve projeyi kısa bir süreye sıkıştırıp işgücü maliyetlerini düşürmek amacı ile proje başlangıcını geciktirir”.

“Her projenin müşteri tarafında bir veya birkaç sahiplenicisi bulunur. Yazılımcı firma bu kişilerle ilişkilerini düzenlemek, ihale sürecini hızlandırmak için bu insanları teşvik ve ikna etmek zorunda... Bu ilişkilerin yönetim biçimi yalnız ihale sürecinde değil, projenin gerçekleştirilmesi boyunca hayati derecede önemli. Gereksinimler dökümanında belirlenmiş ama yapılışı zorunlu olmayan bir gereksinimin zamanında farkına varılışı projenin kritik bir anında yazılım ekibine altın değerinde zaman kazandırabilir”.

Projenin bitirilebildiği durumlarda: “Önemli olan, ne pahasına olursa olsun, eksik, topal, müşterinin üstün körü kontrolünü geçebilecek şekilde projeyi bitirip çalışır durumda teslim etmek”. “Bitmiş bir projenin zaman içinde eksiklerinin çıkması yalnız doğal değil aynı zamanda iyi. Bitirilmiş bir projenin üstüne çok sayıda kullanıcı isteği gelişi yazılım firmasının nakit akışına katkıda bulunur, ayrıca mühendisler açısından da fazla yorulmadan iş yapıp proje yorguluk atmak imkanını doğurur”.

“İhalede belirlenen koşulların kontrol edilişi kuvvetli bir denetleyiş mekanizması ve genel olarak ta yaygın bir denetleyiş kültürünün varlığını gerektirir. Eğer bir ülkede denetleyiş toplumun ve ekonominin her kademesinde zayıfsa ve bir firma ihaleye girerken standartlara uyuşun gereklerini tümüyle yerine getirirse diğer firmalara karşı zayıf duruma düşer, teklifi pahalı kalır”.

“Bir yazılım paketinin kullanım ömrü birkaç yılı geçmemelidir. Bakım yapmaktansa paketi tamamen yeniden yazmak ya da yeni bir release çıkarmak ekonomik açıdan daha uygun olur yazılımcı firma için”. Ülkemizdeki genel anlayışa göre bakım önemli ve kıymetli değildir. Eskiyen şeyi atar yenisini alırsınız.

Müşteri açısından: “Gereksinimleri belirlemek ve iyi bir proje şartnamesi hazırlamak uzman personel ve zaman gerektirir. Çoğu zaman müşteri ne istediğini yalnız çok kabaca bilir. Gereksinimleri önceden görmek ve belirleyebilmek gelişmiş bir soyut düşünüş yeteneği gerektirir. Soyut düşünüş yeteneği toplumumuzda ve kültürümüzde az bulunan bir vasıf… Gereksinimleri özellikle az ve ayrıntısız belirtmek sonradan içlerini doldurmak imkanını yaratır, hatta baştan konuşulmamış unsurları eklemek mümkün olur”.

Yazılım firması açısından: “Müşteriye dökümantasyon vermek risklidir. Mümkün olduğu kadar müşteri yazılım firmasına bağımlı kalmalı ve istediği her hizmet için ödeme yapmalıdır. Dökümantasyon iyi yapılırsa her zaman bir rakip şirketin eline geçebilir ya da müşteri tarafından bu tür şirketler pazarlık alternatifi olarak kullanılabilir”.

“Yazılım firması içinde liderliğin dediği kayıtsız şartsız uygulanmalı, tartışmak ve fikir almakla zaman kaybedilmemelidir. Proje zamanı çok sınırlıdır zaten… Configuration Manager, testing vb. unsurlar proje zamanını arttırır, üstelik ne kadar gerekli oldukları bile şüphelidir? Yönetim gücünün azalışı ve dağılışı yalnızca işi yavaşlatır. Matrix management kabul edilemez. Şirket liderliği karşılıklı ‘sevgi ve saygı’ içinde projeyi yönetir”.

“Her şeyin belirli oluşu, yazılı ve programlı oluşu iyi değildir. İşin yürütülüşünde esnekliği azaltır. Hem ekonomik olarak, hem planlayış olarak, hem yönetim açısından esneklik ne kadar çok ise o kadar iyidir. Standartlar şirketin esnekliğini azaltır”.

“Elemanlardan bazıları kendilerini vaz geçilmez kılmak ve bu şekilde pazarlık güçlerini arttırmak ister. Ayrıca herkesin herşeyi aynı şekilde yapışı pek gerçekçi bir beklenti değildir ülkemizde... Her yiğidin bir yoğurt yeyişi vardır memleketimizde”.

“Standartların uygulanabilişi için ilk önce okunuşu ve kavranışı zorunlu. Bunun için yeterli İngilizce’ye sahip mühendis sayısı çok az ülkemizde… Alman devleti HER üniversite öğrencisine ABD’de 1 yıl Master bursu veriyor. Yabancı dil devletin sistemli bir yatırım politikası izlemesini gerektirir. Standartları anlayabilmek Batı kültürünü anlamağı ve hazmetmiş olmağı gerektirir. Bu işi 4 yıl İngilizce eğitim veren bir üniversiteden mezun tecrübe ve görgüsü pek olmayan genç ve ucuz elemanlarla yapmak mümkün değil maalesef”.

“Standartlar İngilizce. Program kullanıcı arayüzü Türkçe. Yazanların İngilizce’leri zayıf, dolayısıyla programlar da Türkçe esaslı… Bu standartların uygulanışı daha baştan zorda… Tam olarak anlamadan, ihale koşulları sağlansın diye bir şeyler karalamaktan başka çare yok”…

“Standartlar yazılım üretim sürecinin çeşitli soyutlanışlarından oluşur. Soyut şeyler zordur. Bizim insanımız soyut şeyleri sevmez. Elle tutulur iş olarak, program yazmak varken, ne olduğu, geleceği belirsiz işlerle zaman kaybetmek doğru değildir. Standartlarla uğraşan kişilerin tekrar benzeri bir iş bulmak olasılıkları programcılara göre daha azdır”.

“Her şeyin yazılı ve belgeli oluşu güvenlik ve gizlilik açısından sakıncalıdır. Her programın ve üstündeki her değişikliğin sorumlusunun belirli oluşu insan güvenliği ile ilgili işlerde vicdani yükü aşırı arttırır. Ayrıca, zaten kimin neyi yaptığı ilgili grup şefi tarafından bilinir. Eğer bu bilgi yazılı olursa hukuki sorunlarla karşılaşıldığında firmanın esnekliği azalır”.

“Standartlara uymak kaygısı formaliteyi çok arttırır. Bir yığın kağıt, dosya dosya ortalıkta dolaşmağa başlar. Mühendisler kağıt işi yapmak istemezler. Hem ainesi iştir kişinin lafına bakılmaz. Bizim kültürümüzde yazmak önemli değildir. Mimar Sinan bile onca eserinin yanında, nasıl yaptığını anlatan pek bir yazılı metin bırakmamış”.

“İş yapmaktan kaçan, sonucu doğrudan etkileyen kritik işlerden kaçan, yükün altına kendi girmeyip başkalarını süren bazı mühendislerin sığınmak için kullandıkları pozisyonlar genelde standartların uygulanışı ile ilgili pozisyonlardır. Bu tür kişilerin standartları anlamadan ve geliştirilen uygulamanın özünü bilmeden yaptıkları dogmatik düzenlemeler proje maliyetlerini çok arttırıp kadronun üretken kesiminin moralini bozabilir”.


Standatları uygulamak ile ilgili yukarıda belirttiğim görüşlerin kimileri doğru kimisi yanlış, bazıları nesnel bazıları değil, kimisi gerçek hayattan kimisi varsayım… Ama şu kesin bir gerçek, eğer Türkiye’de bir yazılım firması ISO9000 almak istiyorsa, ya da girdiği bir ihalede ISO12207 ya da Mil498’e uyma yükümlülüğü var ise, beş aşağı beş yukarı bu tür sorunlarla karşılaşacak…

Üstelik bu standartlar dünyanın gelişmiş ülkelerinin ihtiyaçlarına, kültürel ve ekonomik birikimlerine göre hazırlanmıştır. Ülkemiz ve toplumumuzun gerçekleri bu standartları raftan alıp uygulamağa uygun değildir.
Unutmayınız, uçağa binme kültürü hiç olmayan ya da çok yeni olan bir kadroya manevra gücü yüksek uçakların uçuş kontrolu için işletim sistemi yazdırılan bir ülkede yaşıyoruz. Üstelik bu kadro Do178B ya da eşleniği Avrupa standardına uyumu hedeflerken gelen yabancı uzmanları izlemekte zorlanacak kadar kötü bir İngilizce seviyesine sahip. Çünkü izlenen personel politikaları, günü kurtarmak kaygısı-zorunluluğu ile, İngilizce’si çok iyi olan kesimi tutamıyor ya da eldeki elemanları yetiştirmek için hiç değilse lider kadroyu uzun süreli yurtdışı görgü görevlerine göndermiyor.

Daha bir çok olumsuz ama gerçekçi örnek vermek mümkün. Peki, o zaman evrensel standartları Türkiye’de uygulamak mümkün değil midir?

Bunun bir yolu var. Dağa doğrusu en az bir yolunu biliyorum, Almanya Karlsruhe Hava Trafik Kontrolü merkezinde EUROCONTROL-STK’de gördüklerim ve Türkiye’de edindiğim tecrübeler ışığında… Standartları Uygulamak-II adlı yazımda buna değineceğim…

Önemi olan ne yaptığınız ya da bir şeyi yapıp yapmadığınız değil, neyi ne kadar nerede ne zaman ve nasıl yaptığınızdır.

İnce dikkatlerinize.

Ali R+ SARAL

SAINT-EXUPERY SAVAŞ PİLOTU ÇEVİRİLERİ

ANTOINE de SAINT-EXUPERY’nin
SAVAŞ PİLOTU’nun
TÜRKÇE TERCÜMELERİNİN ELEŞTİREL BİR GÖZDEN GEÇİRİLİŞİ

A CRITICAL REVIEW OF ANTOINE de SAINT-EXUPERY’s
PILOTE DE GUERRE’s
TURKISH TRANSLATIONS FROM FRENCH


Bu notu Türkçe tercümelerin alabileceği kalite seviyelerini göstermek için yazdım. Bu not aynı zamanda var olan tercümeler arasında bir tercih yapmak için de kullanılabilir.

I have prepared this note to demonstrate the quality of Turkish translation may take… It can also be used to make a choice between them according to the reader’s taste.

An example from the beginning of UNIT 5.
Beşinci bölümün başlangıcından bir örnek.

Ex: Antoine de SAINT-EXUPERY
ODA: Nuriye YİĞİTLER
NEHİR: Ömer TURAN
ARS: Ali Rıza SARAL

Ex: L’angoisse est due a la perte d’une identite veritable.
ODA: Bunalım, gerçek bir kimliğin yitirilmesinden kaynaklanır.
NEHİR: Sıkıntılar gerçek kimliğinizi kaybetmeniz ile ilgilidir.
ARS: ENDİŞE GERÇEK KİMLİĞİN YİTİRİLİŞİNDENDİR.

Ex: Si j’attends un message dont depend mon bonheur ou mon desespoir, je suis comme rejete dans le neant.
ODA: Mutluluğum ya da umutsuzluğumla bağıntılı bir haber bekliyorsam, boşluğa atlıyormuş gibi olurum.
NEHİR: Saadetimin ya da umutsuzluğumun kaynağı olacak bir haber bekliyorsam sanki boşlukta kaybolmuş gibiyimdir.
ARS: MUTLULUĞUMUN YA DA HAYAL KIRIKLIĞIMIN BAĞLI OLDUĞU BİR HABER BEKLİYORSAM EĞER, BOŞLUĞA ATILMIŞ GİBİYİMDİR.

Ex: Tant que l’incertitude me tient en suspens, mes sentiments et mes attitudes ne sont plus qu’un deguisement provisoire.
ODA: Kararsızlık beni sallantıda bıraktığı sürece, duygularım ve davranışlarım, geçici olarak kılık değiştirir.
NEHİR: Bana belirsizlik hakim olduğu sürece, duygu ve tavırlarım, geçici bir kılık değiştirmeden ibarettir.
ARS: BELİRSİZLİK BENİ HAVADA ASILI TUTTUĞU TÜM SÜRECE BOYUNCA, DUYGU VE TAVIRLARIM GEÇİCİ BİR ALDATMACADAN, SAHTE BİR KOSTÜMDEN BAŞKA ŞEY DEĞİLDİR.

Ex: Le temps cesse de fonder, seconde par seconde, comme il batit l’arbre, le personnage veritable qui m’habitera dans une heure.
ODA: Zaman saniye saniye bir ağacı oluşturduğu gibi bir saat sonra içime yerleşecek olan gerçek kişiyi oluşturmaktan vazgeçer.
NEHİR: Zaman, bir ağacı oluşturduğu gibi, her geçen saniye, bir saatlik kişiliğimi oluşturmaktan vazgeçer.
ARS: ZAMAN TIPKI BİR AĞACI İNŞA ETTİĞİ GİBİ, SANİYE SANİYE, İÇİMDE BARINAN BU GERÇEK KİŞİLİĞİ AYAKTA TUTMAKTAN VAZGEÇER.

Ex: Ce moi inconnu marche a ma recontre, de l’exterieur, comme un fantome.
ODA: Bu bilinmeyen ben bir hayalet gibi bana gelmektedir dışarıdan.
NEHİR: Tanımadığımız bir ‘ben’, bir hayalet gibi, benim dışımdan bana doğru yürür.
ARS: YABANCI BİR BEN BANA KARŞI, DIŞARDAN İÇERİYE DOĞRU, BİR HAYALET GİBİ İLERLER.

Ex: Alors j’eprouve une sensation d’angoisse.
ODA: İşte o zaman bir sıkıntı duyarım.
NEHİR: O zaman büyük bir sıkıntıya kapılırım.
ARS: İŞTE O ZAMAN BİR ENDİŞE DUYGUSU HİSSEDERİM.

Ex: La mauvaise nouvelle provoque, non l’angoisse, mais la souffrance : c’est toute autre chose.
ODA: Kötü haber bunalım değil de acı yaratır : Bambaşka bir şeydir bu.
NEHİR: Kötü haber ise sıkıntıdan ziyade acı verir insana, bu tamamen başka bir şeydir.
ARS: KÖTÜ HABER ENDİŞEYİ DEĞİL AMA ONUN YERİNE ACIYI HAREKETE GEÇİRİR: BU TAMAMEN BAŞKA BİR KONUDUR.

HOW TO PREDICT AIR MISSES

HOW TO PREDICT AIR MISSES

by Ali R+ SARAL

ABSTRACT : A method to predict the number of air-misses in a certain time duration and region based on performance, reliability, complexity and weather factors of an Air Traffic Control system.
KEYWORDS : ATC, air traffic control, vertigo, metrics, airmiss









ADDRESS: Ali R. SARAL
Barbaros Mah. Sedef Sok. Onur Sit. 13/13
Uskudar ISTANBUL
TURKEY-(TURKIYE)

MAIL ADDRESS: arsaral(at)yahoo.com
TELEPHONE: 0090-(216)-474 8818




It is fatally important to ponder on the issues of Air Traffic Control (ATC) where the development pace of the available technologies may have overcome the development of the systems available and the belief in the unity of support to the people in the air is incidentally hurt in the wake of the recent air traffic accidents. I believe it is critically important to have the scientific communities' support and wide contribution in order to overcome the challenges that are coming ahead, the difficulties in the cooperation of Short Term Conflict Alert displays this alone.

This article proposes a prediction method to find the number of air misses in a given duration of time in a certain region. If it is applied concurrently and coherently it may point at where the first accident lying ahead is likely to happen. It depends on the fair and precise measurement of the controllers', ATC centers', airlines', technical support and systems' performance factors and the weather factors. The details of these metric values may be the subject of another article.

Air traffic control (ATC) system is a dynamic system. ATC system's behaviour changes through time according to the changes in the input and system parameters. In fact, 'the evolution of ATC system in time depends on the complex interactions of the timing of various discrete events' (1), such as the entry of many aircrafts in a certain period of time into a certain control region and the exit flowing rate of these aircrafts and how the ATC system reacts to this traffic both psychologically on the control team basis and the availability of the technical infra-structure of the system as a whole.

A mathematical model of an ATC system is given in equation [1]. This equation provides a metrical method, which may help to overcome the 'vertigo effect' of ATC, namely 'the false sense of safety'. Similar to any metrical value this equation may help to indicate the direction if not the value of the change of safety in the air provided that it is applied with vigorous consistency.
a*c
amiss = [ 1 - K * p * r * (1 - e * w ] * trd * dur (1)

amiss # of air misses for dur
trd average # of flights per day for the controlled duration and region [real num / day ]
dur total flight duration
p performance factor
r reliability factor
c complexity factor
w weather factor

K is a constant determined by the complex interaction of p, r, c, w. It reflects the composite effect of these factors. K can be determined and improved by using legal recording and other data.

a is a constant that determines the sensitivity of the traffic problem domain to the complexity of the ATC system. It may be determined heuristically in the beginning.

p,r,c,w are assumed constant for dur

0 < p =" 0," p =" 1," r =" 0," r =" 1," c =" 0," c =" 1," w =" 0," w =" 1" s =" amiss" safety =" number" s =" [" f =" amiss">