Not: Bu derleme-çeviri-yazımı ileride olası bir nükleer santralın kontrol odasının Türkçeleştirlmesi çalışmasına küçük bir deneysel katkı olması amacı ile yaptım. Konuyla ilgili kişilerin eleştiri ve tavsiyelerine şiddetle ihtiyacım(ız) var. Bu yazının ne anlattığını kolaylıkla anlayabildiniz mi? Lütfen arsaral(at)yahoo.com adresine yadırgadığınız beğendiğiniz şeyleri ve önerilerinizi yazınız. Saygılar. Ali Riza SARAL
(WORK IN PROGRESS - İNŞA HALİNDE)
İşletim Odası Düzeni
1.1 Kontrol Cihazları
Çalışmaları için gerekli bilgiler bilgisayar tarafından sağlanan aşağıdaki cihazlar işletimsel hizmetler sağlanmasında kullanılır.
Radar Görüntüleyici (SDD – Syntetic Data Display) sentetik veri ekranı coğrafi veri(haritalar) ile eşlenmiş olarak suni radar görüntüsü sağlamak için kullanılır.
Hangi verinin gösterileceğinin ayrımı radar görüntüleyiciye (SDD) bağlı veri kontrol paneli (data control panel (DCP)) tarafından yapılır. Coğrafi konum ayrımı ise sabit mouse (Rolling Ball (RLB)) ile yapılır.
Elektronik Veri Ekranı(EDD – Electronic data display )- tablosal veriler göstermek için kullanılır.
Dokunmatik giriş cihazı (TID - Touch input device) – bir Elektronik Veri Ekranı(EDD)’yla yan yana kullanılarak hazır bir giriş emri vermek için kullanılır .
Bilgisayar terminali (KDS - Keyboard display station) - veri düzeltmek ve yazmak için kullanılan standart terminal.
Bilgisayar Yazıcısı (CPR - Computer printer) – Bilgisayar terminali (KDS) ekranının yazıya dökülmesi ve işletimsel/sistemsel mesajların yazılması için kullanılan kağıda dökücü yazıcı.
Şerit Yazıcısı (SPR - Strip printer) – uçuş ilerleme şeritlerini (flight progress strips) yazan özel yazıcı.
Nokta işleyici terminali (HPP teletype - Hardware plot processor teletype) – yedek radar görüntüleme sistemi için (fallback system radar display) giriş kod ve çağrı işareti ikililerinin (code callsign pair) kaydını tutar
ve/veya girişini yapar.
1.2 Kontrol Sektör Düzeni
Bir kontrol sektörü bir on-route kontrol kısmı ve bir off-route kontrol kısmından oluşur. Azami sektör tanımı şunları içerebilir:
a) On-Route
- Herbiri bir dokunmatik giriş cihazı (TID) ve Elektronik Veri Ekranı(EDD) donanımlı iki tane on-route planlama konumu, P1 ve P2
- Bir dokunmatik giriş cihazı (TID) ve Elektronik Veri Ekranı(EDD) donanımlı bir tane on-route icracı koordinatör konumu , CI
- Herbiri bir Radar Görüntüleyici (SDD) ve bağlı veri kontrol panali (DCP) ile sabit mouse(RLB) yanında dokunmatik giriş cihazı(TID) ve bilgisayar ekranı(EDD) ile donanımlı üç on-route icracı kontrolör konumu, E1, E2, E3
- Bir bilgisayar terminali (KDS-K1) ve bir bilgisayar yazıcısı (CPR-R1) donanımlı bir on-route yardımcı konumu (assistant position)
- İki tane on-route şerit yazıcısı , A1 and A2
b) Off-Route
- Bir dokunmatik giriş cihazı (TID) ve Elektronik Veri Ekranı(EDD) donanımlı bir off-route planlama konumu, P6
- Bir dokunmatik giriş cihazı (TID) ve Elektronik Veri Ekranı(EDD) donanımlı bir off-route icracı koorinatör konumu, C6
- Herbiri bir Radar Görüntüleyici (SDD) ve bağlı veri kontrol panali (DCP) ile sabit mouse(RLB) yanında dokunmatik giriş cihazı(TID) ve bilgisayar ekranı(EDD) ile donanımlı üç off-route icracı kontrolör konumu, E6, E7, E8
- Bir bilgisayar terminali (KDS-K2) ve bir bilgisayar yazıcısı (CPR-R2) donanımlı bir off-route yardımcı konumu (assistant position)
- Bir off-route şerit yazıcısı, B1
1.3 Sektörlü Olmayan Birimler (Non Sectorised Units)
a) Merkezi Bölüm (Central Section)
Merkezi bölüm esasen bir off-route bölümüdür ve şunlardan oluşur:
- Herbiri dokunamatik giriş cihazı(TID) ve bilgisyar ekranı(EDD) ile donanımlı iki off-route icracı koordinatör konumu, CC6 ve CC7
- Herbiri bir Radar Görüntüleyici (SDD) ve bağlı veri kontrol panali (DCP) ile sabit mouse(RLB) yanında dokunmatik giriş cihazı(TID) ve bilgisayar ekranı(EDD) ile donanımlı iki off-route icracı kontrolör konumu, CE6, CE7
- Bir bilgisayar terminali (KDS-CK2) ve bir bilgisayar yazıcısı (CPR-CR2) donanımlı bir yardımcı konumu (assistant position)
- İki tane off-route şerit yazıcısı ve bir on-route şerit yazıcısı
b) Merkezi Uçuş Veri Bölümü (Central Flight Data Section)
Merkezi uçuş veri bölümü esasen uçuş planı düzeltmek için kullanılır ve şunlardan oluşur:
- Herbiri birer bilgisayar terminali (KDS) ile donanımlı üç uçuş veri konumu
- Two HPP teletypes used for logging of code/callsign pairs and for possible code callsign input during fall back state
- One logging position equipped with a CPR used for the printing of all messages entering the system via the DCTS
c)Yönetim Bölümü (Supervisor Section)
Yönetim Bölümü bir bilgisayar terminali(KDS) ve bir bilgisayar yazıcısından (CPR) oluşur.
d) MET/AIS Section
MET/AIS bölümü bir bilgisayar terminali (KDS) ve bir bilgisayar yazıcısı (CPR) ‘ndan oluşur.
e) Teknik İzleme ve Kontrol Bölümü (Technical Monitoring and Control Section (TMCS))
Teknik İzleme ve Kontrol Bölümü bilgisayar odasında yer alır ve sistemin kontrolu için kullanılır.
Bu bölüm şunları içerir:
-Sistem kontrol mesajlarının girilmesi ve çıktılarının görülmesi için bir bilgisayar terminali(KDS)
- Bilgisayar kayıtlarının yazılıması için (logging) bir bilgisayar yazıcısı
-Bir Radar Görüntüleyici (SDD) ve bağlı veri kontrol paneli (DCP), mouse (rolling ball – RLB) yanında izleme amacı ile bir Elektronik Veri Ekranı(EDD) ve dokunmatik giriş cihazı (TID)
f) Askeri Gözlem Konumu
Bu bölüm hava savunma bildirimi(notification) amaçlı bir bilgisayar terminali/yazıcısı (KDS/CPR) çiftini içerir.
Thursday, February 22, 2007
Monday, February 12, 2007
A Few Corrections and Some Comments on ESARR 6 - Software in ATM Systems
A FEW CORRECTIONS and SOME COMMENTS
ON EUROCONTROL’s Safety Regulation Requirement
ESARR 6 – Software in ATM Systems
CORRECTIONS
I - Mandatory Provisions, 1. General safety Requirements, item 1.2
a) The software requirements correctly state what is required by the software, in order to meet safety objectives and requirements, as identified by the risk assessment and mitigation process;
should rather be
a) The software requirements correctly state what is required from the software,
II - Requirements applying to the software safety assurance system, item 2.4,
b) the assurances corresponding to each software assurance level shall give sufficient confidence that the ATM software can be operated tolerably safely.
The term tolerably safe is not explained in the document, safety is defined as “freedom from unacceptable risk”,
Should rather be
… can be operated with acceptable risk
or
… can be operated with safety. (the flexibility in the definition itself suffices)
III – Item 2.6,
… developmental and non-developmental are unnecessary new words which do not contribute to the jargon more than the overhead they create.
IV. Requirements applying to the software assurance level, item 3.2
… the architectural and/or procedural defences identified
defences should be precautions or precaution systems if you like. (would be nice if it were football;-)
IV – Appendix A
Accuracy: The required precision of the computed results.
Accuracy and precision and the relation between them should be clearly defined. Some university books define precision as the “repeatibility of results” regardless of their accuracy. Accuracy is only the correctness of a measurement nothing else… …
V - Resource usage: The amount of resources within the computer system that can be used by the application software.
Should be
by a specific application in the software
VI - The definition for the word ‘risk’ is a little bit cumbersome but perfact in meaning…
VII – Safety: Freedom from unacceptable risk
implies that freedom includes acceptable risk which is quiet clever… And after this, safety is referred to in‘acceptable or tolerable safety’, which means ‘acceptable or tolerable acceptable risk situation’ according to the definition of ‘safety.’
acceptable or tolerable safety
Should be either
Safety
Or
Acceptable or tolerable risk (situation)…
VIII – The term ‘Software Timing Performances’ may have been used to bring in meaning flexibility for future developments and it is also out of any jargon that I have heard of… The definition given points at exactly the term ‘response time’. It does not sound ‘just’ to do things like this unless they are done unintentionally.
COMMENTS
I - This is a difficult document to write. Many who are involved with ATC rather closely would choose not to write it at all…
II -The document has to set a framework so that assigned authorities, service providers etc. should be gently leaded to a more formal way of doing things and maybe doing them better as a natural result. The document is good in this respect.
III - On the other hand, the document misses conscientious aspect of software development and maintenance in ATC in the thick cloud of gentle politics, interest balancing etc. Bluntly, there is nothing in the document which ensures the identification of who has done which software change or development item. ESARRs have conscientiously protected anonymity of engineers who may have caused involuntary harm to the air traffic. ESARR 6 falls short of adressing the individual responsibility in retrograde of this.
should be
6.4 A person who has done an error in the ATM software should be easily identifiable through the use of Configuration management.
IV – Testing should have been mentioned explicitly
VII – Software inspection by peers and group leaders should have been mentioned explicitly
The last two items are no less important or relevant than traceability in software requirements.
APPENDIX
TURKISH TRANSLATION OF ESARR 6
WORK IN PROGRESS 20070221ARSver0.1.1
By Ali R+ SARAL
EUROCONTROL
Hava Seyrüseferi Güvenliği için Avrupa Kuruluşu
(EUROCONTROL-European Organisation for the Safety of Air Navigation)
EUROCONTROL Güvenlik Düzenleyici Şartnamesi
(ESARR–EUROCONTROL Safety Regulatory Requirement)
ESARR 6
Hava Trafik Yönetim Sistemlerindeki Yazılımlar
(Software in ATM Systems)
F.2 BELGE ÖZELLİKLERİ
ESARR6 yazılım güvenliği güvence sistemlerinin hayata geçirilmesi ile ilgilenir. Bu sistemler güvenlik ile ilgili yeryüzüne-konumlandırılmış ATM sistemlerindeki yazılımların kullanılmasına ilişkin risklerin hoş görülebilecek bir seviyeye indirilmesini güvenceye alır.
ESARR6 yazılım için herhangi bir destekleyici uyum yöntemi kullanılmasını öngörmez. Bunu yapmak yazılım güvencesi standartlarının payına düşer. Dolayısıyla, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.
Bu şartnamenin amacı ATM güvenlik düzenleyici kuruluşları ve ATM hizmet sunucularına ATM sistemlerinde yazılım kullanımı için kendi içinde bütünlük ve uyum taşıyan bir grup güvenlik düzenlemesi koşulu sağlamaktır.
…
F.6 YÖNETİMSEL ÖZET
Bu EUROCONTROL Güvenlik Düzenleyici Şartnamesi(ESARR) Güvenlik Düzenleyici Komisyon tarafından hazırlanmıştır.
ESARR6 yeryüzüne-konumlandırılmış ATM güvenlik sistemlerindeki yazılımların kullanım risklerinin hoş görülebilecek bir seviyeye indirilmesinden emin olmak için yazılım güvencesi sisteminin hayata geçirilmesi ile ilgilenir.
Bu yüzden, bu ESARR’ın amacı ATM sistemlerinde yazılım kullanımı için bir grup uyumlu güvenlik düzenleyici koşul sağlamaktır. Hiçbir yazılım güvencesi standardını kendi zorunlu koşullarını karşılamak için kabul edilebilir bir uyum yöntemi olarak belirlemez. Buna bağlı olarak, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.
Bu ESARR’ın koşulları EUROCONTROL Daimi Komisyonu tarafından onaylandıktan sonra 3 yıl içinde uygulamaya girecektir.
…
…
TANITICI MALZEME
Bu kısımdaki koşullar zorunlu değildir.
A. KAPSAM
i. ESARR 6, sivil hava trafiğine ATM hizmetleri sağlamak için kullanılan, güvenlik ile ilgili, yeryüzüne konumlandırılmış ATM(hava trafik yönetimi) sistemlerinde yazılım kullanımıyla (cutover / hot swapping gibi tüm işletimsel yazılım değiştirme işlemleri dahil) ilişkilidir.
ii. ESARR 6’nın kapsamı ATM hizmet-sağlayıcının idari kontrolü altındaki yeryüzüne konumlandırılmış CNS gibi destek hizmetleri dahil, ATM’in yeryüzü bileşeni ile sınırlıdır. Değiştirilmediği ve uygun bir şekilde yeniden gözden geçirilmediği takdirde ESARR6 gökte ya da uzayda uçan ATM sistemi bileşenleri için uygulanamaz.
iii. Bu güvenlik düzenleyici şartnamenin koşulları, yazılım tarafından icra edilen ATM işlevleri dahil ATM’in tüm sahalarının gereğince değerlendirilmesinden emin olmak için, a priori, önkoşul olarak, etkin risk değerlendirme ve uygun bir seviyeye risk azaltması çalışması yapılması temelinde geliştirilmiştir.
iv. ESARR 6 yazılım için herhangi bir destekleyici uyum yöntemi öngörmez. Bunu yapmak yazılım güvencesi standartlarının payına düşer. Buna bağlı olarak, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.
B. GEREKÇE
i. SRC’nin 6/8/5 kararı SRC İş Programı içinde yazılım temelli ATM sistemleri için bir EUROCONTROL Güvenlik Düzenleyici Şartnamesi geliştirilmesini içermeyi onayladı. Aynı zamanda, ICAO standartları ve tavsiye edilen ICAO uygulamalarında ilk örnek teşkil edecek hiçbir şeyin var olmadığı olgusu da kabul edildi.
ii. ESARR 3(Güvenlik Yönetim Sistemlerinin ATM hizmet sağlayıcıları tarafından kullanımı) ATM sistemine yapılan değişikliklerin önemlerine göre değerlendirilmesini ve ATM sistem işlevlerinin ciddiyetlerine göre sınıflandırılmasını güvenceye almak için güvenlik yönetim sistemlerinin Risk Değerlendirme ve Azaltma içermelerini şart koşar.
iii. ESARR 4 (Hava Trafik Yönetiminde Risk Değerlendirme ve Azaltma – Risk Assessment and Mitigation in ATM) Risk Değerlendirme ve Azaltma üzerinde ESARR3’ün şartlarını genişletir ve Hava Trafik Yönetimi sistemini insanlar, işlemler ve cihazlar (yazılım ve donanım) açısından ve onların ATM sisteminde değişiklik yapmaları / tasarlamaları açısından ele almak için her yönden kapsayıcı bir işlemler dizisi sağlar.
iv. ESARR 6 bu güvenlik düzenleyici geliştirme sürecinin devamıdır ce ATM sistemlerinin yazılım yanına ilişkin olarak ESARR 4’ü genişletir. Donanım yanı için tamamlayıcı güvenlik düzenleyici şartname değerlendirme altındadır.
v. Güvenlik ATM sistemlerinin temel bir özelliğidir. İşletimsel etkinlik üzerinde ağırlıklı bir çarpıcı etkiye sahiptir. Yığınsal ve sistemli yazılım kullanımı, daha önce elle icra edilen işletimsel işlevlerin otomasyonu ve sürekli büyüyen tümleşik ortamlarda önemli etkileşimler içeren ATM sistemleri güvenlik elde edilmesinde daha resmi-formal yaklaşımlar talep etmektedir.
vi. Bu ESARR’ın amacı ATM sistemlerinin kullanımı için ATM güvenlik kuruluşları ve ATM hizmet sunucularına bütünsel ve uyumlu bir grup güvenlik düzenleyici şart sağlamaktır.
C. GÜVENLİK HEDEFİ
Yazılım içeren ATM sistemlerinin sağlaması gereken birincil yazılım güvenlik amacı
ATM yazılımı kullanımı ile ilişkilendirilmiş risklerin hoş görülebilir bir seviyeye indirilmesinden emin olunmasıdır.
ZORUNLU KOŞULLAR
1. GENEL GÜVENLİK ŞARTLARI
1.1 Güvenlik Yönetim Sistemi yapısı içinde ve risk değerlendirme - azaltma faaliyetlerinin bir parçası olarak, ATM hizmet-sağlayıcısı sorunun yazılım ile ilgili yanlarını ele almak için (cutover/hot swapping gibi bütün kullanım sırasındaki işletimsel yazılım değişiklikleri dahil) bir Yazılım Güvencesi Sistemini uygulamaya koymalıdır.
1.2 ATM hizmet-sağlayıcı, Yazılım Güvenlik Güvencesi Sisteminde, en azından, şunlardan emin olmalıdır;
a) Yazılım şartnamesi, risk değerlendirme – azaltma sürecinde belirlendiği şekilde, güvenlik amaçlarını ve şartlarını sağlamak için yazılımın(?) yapması gereken şeyleri doğrulukla belirtir.
b) İzsürülebilirlik–traceability bütün yazılım şartları açısından ele alınmış;
c) Yazılım gerçekleştirliş şekli güvenliği olumsuz etkileyecek hiçbir işlev içermez;
d) ATM kendi yazılım şartnamesini yazılımın hayatiyeti ile tutarlı bir güvenlik seviyesi yüksekliğinde sağlar;
e) Yukarıdaki Genel Güvenlik Şartnamesi’nin sağlandığına ilişkin güvencelerin ve gereken güvencelerin sağlandığına ilişkin tartışmaların her zaman aşağıdakilere dayandırılması;
i. yazılımın belirli bir icra edilebilir sürümü
ii. bir dizi yapısal-kurulum–configuration verisi
iii. belirli bir grup yazılım ürünü ve o sürümün üretilişinde kullanılmış tanımlar(tarifnameler dahil).
1.3 ATM hizmet-sağlayıcısı Atanmış Otoriteye, yukarıda bölüm 1.2’deki şartların sağlandığına ilişkin gerekli güvenceleri sağlamalıdır.
2. YAZILIM GÜVENLİK GÜVENCESİ SİSTEMİNE UYGULANAN ŞARTLAR
ATM hizmet-sağlayıcı, Yazılım Güvenlik Güvencesi Sisteminin en azından şunları sağladığından emin olmalıdır;
2.1 Belgelenmiş olmalı, özellikle genel Risk Değerlenirme – Azaltma Belgeleme Sisteminin parçası olarak.
2.2 Bütün işletimsel ATM yazılım yazılım güvence seviyeleri ataması.
2.3 Aşağıdakilerin güvencelerine sahiptir;
a) Yazılım şartları geçerliliği–software requirements validity
b) yazılım geçerliliğini doğrulama–software verification
c) yazılım yapısal-kurulum yönetimi–software configuration management
d) yazılım şartnamesi izsürülebilirliği – software requirements traceability
2.4 Güvencelerin hangi azim ve ısrar ile gerçekleştirildiğini belirler. Azim ve ısrar her yazılım güvencesi seviyesi için tanımlanmalı ve yazılımın hayatiyeti ile doğru orantılı artmalıdır. Bu amaçla;
a) Her yazılım güvencesi seviyesi başına güvence azim ve ısrarındaki değişim aşağıdaki kriterleri içermelidir:
i. bağımsız olarak başarılması gerekir
ii. başarılması gerekir
iii. şart değil.
b) Her yazılım güvence seviyesine denk düşen güvenceler ATM yazılımının hoş görülebilir(?) şekilde güvenli işletilebileceğine yeterli güven vermelidir.
2.5 Yazılı Güvenlik Güvencesi Sisteminin ve güvence seviyelerinin atamasının uygun ve geçerli olduğunun doğrulanması için ATM yazılım tecrübesinden geri dönerek faydalanır. Bu amaçla, ESARR 2’ye göre raporlanmış ATM işletimsel tecrübesinden herhangi bir hata veya yazılım arızası sonucu etkiler ESARR 4 yapısı bağlamında değerlendirilmelidir.
2.6 Atanmış Otorite tarafından seçilmiş ve kabul edilmiş herhangi bir yöntem ile, eşit yazılım güvencesi seviyelerindeki, geliştirilmiş ya da hazır alınmış ATM yazılımları için(COTS vb.), eşit güvenlik seviyesi sağlar.
3. YAZILIM GÜVENCESİ SEVİYESİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
3.1 Yazılım güvencesi seviyesi, yazılım güvencelerinin azim ve ısrarını ATM yazılımının hayatiyetine, ESARR 4 ciddiyet sınıflama şeması ile belirli bir olumsuz etkinin oluşması olasılığını birleştirerek, ilişkilendirir. 1. yazılım güvencesi seviyesi en hayati seviyeyi belirtmek üzere, en az 4 yazılım güvencesi seviyesi tanımlanmalıdır.
3.2 Ayrılmış bir yazılım güvencesi seviyesi ESARR 4’e göre yazılım arızaları ve hatalarının neden olabileceği en olumsuz etki ile denk düşmelidir. Bu, yazılım arızaları ve hataları ile ilişkili riskleri ve belirlenmiş yapısal ve/veya işlem-dizisel-procedural savunmaları(?-tedbirleri demek istiyor-ARS) hesaba katmalıdır.
3.3 Birbirlerinden bağımsız oldukları gösterilemeyen ATM yazılım unsurları bağımlı unsurlar arasındaki en hayati yazılım güvencesi seviyesine ayrılmalıdır.
4. YAZILIM ŞARTNAMESİ GEÇERLİLİK GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından yazılım şartlarının:
4.1 ATM yazılımının (normal ve geriseviyelendirilmiş-downgraded çalışma türlerinde) işlevsel davranışını, icra hız(?) seviyeleri, kapasite, doğruluk, hedef bilgisayarda yazılımın kaynak kullanımı, anormal işletimsel durumlarda ayakta kalma yeteneği - robustness
ve aşırı yüklenmeye dayanıklılık, uygun şekilde belirlemesi.
4.2 Tam ve doğru olmaları ve sistem güvenlik şartnamesi koşullarına uymaları gerekir.
5. YAZILIM GEÇERLİLİĞİ DOĞRULAMA GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
5.1 ATM yazılımının işlevsel davranışının, icra hız(?) seviyeleri, kapasite, doğruluk, hedef bilgisayarda yazılımın kaynak kullanımı, anormal işletimsel durumlarda ayakta kalma yeteneği - robustness ve aşırı yüklenmeye dayanıklılığının yazılım şartnamesi koşullarını sağlar.
5.2 ATM yazılımının geçerliliği, Atanmış Otorite ile mutabakata varıldığı gibi, analiz ve/veya deneme ve/veya eşdeğer yöntemlerle uygun bir şekilde doğrulanır.
5.3 ATM yazılımının geçerliliği doğru ve tamdır.
6. YAZILIM KURULUM-YAPISI(configuration) YÖNETİMİ GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
6.1 Yapısal-kurulum–configuration belirlemesi, iz-sürülebilirlik ve durum takibi-status accounting vardır öyle ki, ATM yazılım yaşam-döngüsü-lifecycle boyunca yazılım yaşam-döngüsü verilerinin yapısal-kurulum kontrolü altında olduğu gösterilebilir.
6.2 Sorun raporlama, takip ve düzeltici eylemler vardır öyle ki yazılıma ilişkin güvenlik ile ilgili sorunların azaltıldığı gösterilebilir.
6.3 Öyle yeniden ele alma ve hizmete sunma eylem dizileri-procedure vardır ki ATM yazılım yaşam-döngüsü sırasında yazılım yaşam-döngüsü verileri yeniden canlandırılabilir ve teslim edilebilir.
7. YAZILIM ŞARTNAMESİ İZSÜRÜLEBİLİRLİK GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
7.1 Sağlandığı gösterilmiş olan her tasarım seviyesine her bir yazılım şartının izi-sürülebilir.
7.2 Tasarımdaki her seviyede, sağlandığı gösterilmiş olan her bir yazılım şartının bir sistem şartına kadar izi-sürülebilir.
8. UYGULANABİLİRLİK
8.1 Bu güvenlik şartnamesi idari kontrolleri altındaki, yeryüzüne-konuşlandırılmış ATM sistemleri ve destek hizmetleri (CNS gibi)’nden sorumlu olan sivil ve askeri ATM hizmet sağlayıcıları için geçerlidir.
8.2 Askeri ATM kuruluşunun doğrudan idari kontrolü altındaki ATM sistemlerinin zaten var olan yazılım güvencesi sistemi, ESARR 6’nın zorunlu koşulları ile denk düşmek şartı ile geçerli kabul edilebilir.
8.3 Bu ESARR’ın zorunlu koşulları milli güvenlik düzenleyici şartnamelerin asgari koşulu olacaktır.
9. GERÇEKLEŞTİRME
9.1 ESARR 6’nın koşulları EUROCONTROL komisyonu tarafından onaylandığı tarihten itibaren 3 yıl içinde etkin olacaktır.
…
APPENDIX
…
ON EUROCONTROL’s Safety Regulation Requirement
ESARR 6 – Software in ATM Systems
CORRECTIONS
I - Mandatory Provisions, 1. General safety Requirements, item 1.2
a) The software requirements correctly state what is required by the software, in order to meet safety objectives and requirements, as identified by the risk assessment and mitigation process;
should rather be
a) The software requirements correctly state what is required from the software,
II - Requirements applying to the software safety assurance system, item 2.4,
b) the assurances corresponding to each software assurance level shall give sufficient confidence that the ATM software can be operated tolerably safely.
The term tolerably safe is not explained in the document, safety is defined as “freedom from unacceptable risk”,
Should rather be
… can be operated with acceptable risk
or
… can be operated with safety. (the flexibility in the definition itself suffices)
III – Item 2.6,
… developmental and non-developmental are unnecessary new words which do not contribute to the jargon more than the overhead they create.
IV. Requirements applying to the software assurance level, item 3.2
… the architectural and/or procedural defences identified
defences should be precautions or precaution systems if you like. (would be nice if it were football;-)
IV – Appendix A
Accuracy: The required precision of the computed results.
Accuracy and precision and the relation between them should be clearly defined. Some university books define precision as the “repeatibility of results” regardless of their accuracy. Accuracy is only the correctness of a measurement nothing else… …
V - Resource usage: The amount of resources within the computer system that can be used by the application software.
Should be
by a specific application in the software
VI - The definition for the word ‘risk’ is a little bit cumbersome but perfact in meaning…
VII – Safety: Freedom from unacceptable risk
implies that freedom includes acceptable risk which is quiet clever… And after this, safety is referred to in‘acceptable or tolerable safety’, which means ‘acceptable or tolerable acceptable risk situation’ according to the definition of ‘safety.’
acceptable or tolerable safety
Should be either
Safety
Or
Acceptable or tolerable risk (situation)…
VIII – The term ‘Software Timing Performances’ may have been used to bring in meaning flexibility for future developments and it is also out of any jargon that I have heard of… The definition given points at exactly the term ‘response time’. It does not sound ‘just’ to do things like this unless they are done unintentionally.
COMMENTS
I - This is a difficult document to write. Many who are involved with ATC rather closely would choose not to write it at all…
II -The document has to set a framework so that assigned authorities, service providers etc. should be gently leaded to a more formal way of doing things and maybe doing them better as a natural result. The document is good in this respect.
III - On the other hand, the document misses conscientious aspect of software development and maintenance in ATC in the thick cloud of gentle politics, interest balancing etc. Bluntly, there is nothing in the document which ensures the identification of who has done which software change or development item. ESARRs have conscientiously protected anonymity of engineers who may have caused involuntary harm to the air traffic. ESARR 6 falls short of adressing the individual responsibility in retrograde of this.
should be
6.4 A person who has done an error in the ATM software should be easily identifiable through the use of Configuration management.
IV – Testing should have been mentioned explicitly
VII – Software inspection by peers and group leaders should have been mentioned explicitly
The last two items are no less important or relevant than traceability in software requirements.
APPENDIX
TURKISH TRANSLATION OF ESARR 6
WORK IN PROGRESS 20070221ARSver0.1.1
By Ali R+ SARAL
EUROCONTROL
Hava Seyrüseferi Güvenliği için Avrupa Kuruluşu
(EUROCONTROL-European Organisation for the Safety of Air Navigation)
EUROCONTROL Güvenlik Düzenleyici Şartnamesi
(ESARR–EUROCONTROL Safety Regulatory Requirement)
ESARR 6
Hava Trafik Yönetim Sistemlerindeki Yazılımlar
(Software in ATM Systems)
F.2 BELGE ÖZELLİKLERİ
ESARR6 yazılım güvenliği güvence sistemlerinin hayata geçirilmesi ile ilgilenir. Bu sistemler güvenlik ile ilgili yeryüzüne-konumlandırılmış ATM sistemlerindeki yazılımların kullanılmasına ilişkin risklerin hoş görülebilecek bir seviyeye indirilmesini güvenceye alır.
ESARR6 yazılım için herhangi bir destekleyici uyum yöntemi kullanılmasını öngörmez. Bunu yapmak yazılım güvencesi standartlarının payına düşer. Dolayısıyla, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.
Bu şartnamenin amacı ATM güvenlik düzenleyici kuruluşları ve ATM hizmet sunucularına ATM sistemlerinde yazılım kullanımı için kendi içinde bütünlük ve uyum taşıyan bir grup güvenlik düzenlemesi koşulu sağlamaktır.
…
F.6 YÖNETİMSEL ÖZET
Bu EUROCONTROL Güvenlik Düzenleyici Şartnamesi(ESARR) Güvenlik Düzenleyici Komisyon tarafından hazırlanmıştır.
ESARR6 yeryüzüne-konumlandırılmış ATM güvenlik sistemlerindeki yazılımların kullanım risklerinin hoş görülebilecek bir seviyeye indirilmesinden emin olmak için yazılım güvencesi sisteminin hayata geçirilmesi ile ilgilenir.
Bu yüzden, bu ESARR’ın amacı ATM sistemlerinde yazılım kullanımı için bir grup uyumlu güvenlik düzenleyici koşul sağlamaktır. Hiçbir yazılım güvencesi standardını kendi zorunlu koşullarını karşılamak için kabul edilebilir bir uyum yöntemi olarak belirlemez. Buna bağlı olarak, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.
Bu ESARR’ın koşulları EUROCONTROL Daimi Komisyonu tarafından onaylandıktan sonra 3 yıl içinde uygulamaya girecektir.
…
…
TANITICI MALZEME
Bu kısımdaki koşullar zorunlu değildir.
A. KAPSAM
i. ESARR 6, sivil hava trafiğine ATM hizmetleri sağlamak için kullanılan, güvenlik ile ilgili, yeryüzüne konumlandırılmış ATM(hava trafik yönetimi) sistemlerinde yazılım kullanımıyla (cutover / hot swapping gibi tüm işletimsel yazılım değiştirme işlemleri dahil) ilişkilidir.
ii. ESARR 6’nın kapsamı ATM hizmet-sağlayıcının idari kontrolü altındaki yeryüzüne konumlandırılmış CNS gibi destek hizmetleri dahil, ATM’in yeryüzü bileşeni ile sınırlıdır. Değiştirilmediği ve uygun bir şekilde yeniden gözden geçirilmediği takdirde ESARR6 gökte ya da uzayda uçan ATM sistemi bileşenleri için uygulanamaz.
iii. Bu güvenlik düzenleyici şartnamenin koşulları, yazılım tarafından icra edilen ATM işlevleri dahil ATM’in tüm sahalarının gereğince değerlendirilmesinden emin olmak için, a priori, önkoşul olarak, etkin risk değerlendirme ve uygun bir seviyeye risk azaltması çalışması yapılması temelinde geliştirilmiştir.
iv. ESARR 6 yazılım için herhangi bir destekleyici uyum yöntemi öngörmez. Bunu yapmak yazılım güvencesi standartlarının payına düşer. Buna bağlı olarak, özgün milli ve uluslararası yazılım güvencesi standartlarını harekete geçirmek bu şartnamenin sınırları dışındadır.
B. GEREKÇE
i. SRC’nin 6/8/5 kararı SRC İş Programı içinde yazılım temelli ATM sistemleri için bir EUROCONTROL Güvenlik Düzenleyici Şartnamesi geliştirilmesini içermeyi onayladı. Aynı zamanda, ICAO standartları ve tavsiye edilen ICAO uygulamalarında ilk örnek teşkil edecek hiçbir şeyin var olmadığı olgusu da kabul edildi.
ii. ESARR 3(Güvenlik Yönetim Sistemlerinin ATM hizmet sağlayıcıları tarafından kullanımı) ATM sistemine yapılan değişikliklerin önemlerine göre değerlendirilmesini ve ATM sistem işlevlerinin ciddiyetlerine göre sınıflandırılmasını güvenceye almak için güvenlik yönetim sistemlerinin Risk Değerlendirme ve Azaltma içermelerini şart koşar.
iii. ESARR 4 (Hava Trafik Yönetiminde Risk Değerlendirme ve Azaltma – Risk Assessment and Mitigation in ATM) Risk Değerlendirme ve Azaltma üzerinde ESARR3’ün şartlarını genişletir ve Hava Trafik Yönetimi sistemini insanlar, işlemler ve cihazlar (yazılım ve donanım) açısından ve onların ATM sisteminde değişiklik yapmaları / tasarlamaları açısından ele almak için her yönden kapsayıcı bir işlemler dizisi sağlar.
iv. ESARR 6 bu güvenlik düzenleyici geliştirme sürecinin devamıdır ce ATM sistemlerinin yazılım yanına ilişkin olarak ESARR 4’ü genişletir. Donanım yanı için tamamlayıcı güvenlik düzenleyici şartname değerlendirme altındadır.
v. Güvenlik ATM sistemlerinin temel bir özelliğidir. İşletimsel etkinlik üzerinde ağırlıklı bir çarpıcı etkiye sahiptir. Yığınsal ve sistemli yazılım kullanımı, daha önce elle icra edilen işletimsel işlevlerin otomasyonu ve sürekli büyüyen tümleşik ortamlarda önemli etkileşimler içeren ATM sistemleri güvenlik elde edilmesinde daha resmi-formal yaklaşımlar talep etmektedir.
vi. Bu ESARR’ın amacı ATM sistemlerinin kullanımı için ATM güvenlik kuruluşları ve ATM hizmet sunucularına bütünsel ve uyumlu bir grup güvenlik düzenleyici şart sağlamaktır.
C. GÜVENLİK HEDEFİ
Yazılım içeren ATM sistemlerinin sağlaması gereken birincil yazılım güvenlik amacı
ATM yazılımı kullanımı ile ilişkilendirilmiş risklerin hoş görülebilir bir seviyeye indirilmesinden emin olunmasıdır.
ZORUNLU KOŞULLAR
1. GENEL GÜVENLİK ŞARTLARI
1.1 Güvenlik Yönetim Sistemi yapısı içinde ve risk değerlendirme - azaltma faaliyetlerinin bir parçası olarak, ATM hizmet-sağlayıcısı sorunun yazılım ile ilgili yanlarını ele almak için (cutover/hot swapping gibi bütün kullanım sırasındaki işletimsel yazılım değişiklikleri dahil) bir Yazılım Güvencesi Sistemini uygulamaya koymalıdır.
1.2 ATM hizmet-sağlayıcı, Yazılım Güvenlik Güvencesi Sisteminde, en azından, şunlardan emin olmalıdır;
a) Yazılım şartnamesi, risk değerlendirme – azaltma sürecinde belirlendiği şekilde, güvenlik amaçlarını ve şartlarını sağlamak için yazılımın(?) yapması gereken şeyleri doğrulukla belirtir.
b) İzsürülebilirlik–traceability bütün yazılım şartları açısından ele alınmış;
c) Yazılım gerçekleştirliş şekli güvenliği olumsuz etkileyecek hiçbir işlev içermez;
d) ATM kendi yazılım şartnamesini yazılımın hayatiyeti ile tutarlı bir güvenlik seviyesi yüksekliğinde sağlar;
e) Yukarıdaki Genel Güvenlik Şartnamesi’nin sağlandığına ilişkin güvencelerin ve gereken güvencelerin sağlandığına ilişkin tartışmaların her zaman aşağıdakilere dayandırılması;
i. yazılımın belirli bir icra edilebilir sürümü
ii. bir dizi yapısal-kurulum–configuration verisi
iii. belirli bir grup yazılım ürünü ve o sürümün üretilişinde kullanılmış tanımlar(tarifnameler dahil).
1.3 ATM hizmet-sağlayıcısı Atanmış Otoriteye, yukarıda bölüm 1.2’deki şartların sağlandığına ilişkin gerekli güvenceleri sağlamalıdır.
2. YAZILIM GÜVENLİK GÜVENCESİ SİSTEMİNE UYGULANAN ŞARTLAR
ATM hizmet-sağlayıcı, Yazılım Güvenlik Güvencesi Sisteminin en azından şunları sağladığından emin olmalıdır;
2.1 Belgelenmiş olmalı, özellikle genel Risk Değerlenirme – Azaltma Belgeleme Sisteminin parçası olarak.
2.2 Bütün işletimsel ATM yazılım yazılım güvence seviyeleri ataması.
2.3 Aşağıdakilerin güvencelerine sahiptir;
a) Yazılım şartları geçerliliği–software requirements validity
b) yazılım geçerliliğini doğrulama–software verification
c) yazılım yapısal-kurulum yönetimi–software configuration management
d) yazılım şartnamesi izsürülebilirliği – software requirements traceability
2.4 Güvencelerin hangi azim ve ısrar ile gerçekleştirildiğini belirler. Azim ve ısrar her yazılım güvencesi seviyesi için tanımlanmalı ve yazılımın hayatiyeti ile doğru orantılı artmalıdır. Bu amaçla;
a) Her yazılım güvencesi seviyesi başına güvence azim ve ısrarındaki değişim aşağıdaki kriterleri içermelidir:
i. bağımsız olarak başarılması gerekir
ii. başarılması gerekir
iii. şart değil.
b) Her yazılım güvence seviyesine denk düşen güvenceler ATM yazılımının hoş görülebilir(?) şekilde güvenli işletilebileceğine yeterli güven vermelidir.
2.5 Yazılı Güvenlik Güvencesi Sisteminin ve güvence seviyelerinin atamasının uygun ve geçerli olduğunun doğrulanması için ATM yazılım tecrübesinden geri dönerek faydalanır. Bu amaçla, ESARR 2’ye göre raporlanmış ATM işletimsel tecrübesinden herhangi bir hata veya yazılım arızası sonucu etkiler ESARR 4 yapısı bağlamında değerlendirilmelidir.
2.6 Atanmış Otorite tarafından seçilmiş ve kabul edilmiş herhangi bir yöntem ile, eşit yazılım güvencesi seviyelerindeki, geliştirilmiş ya da hazır alınmış ATM yazılımları için(COTS vb.), eşit güvenlik seviyesi sağlar.
3. YAZILIM GÜVENCESİ SEVİYESİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
3.1 Yazılım güvencesi seviyesi, yazılım güvencelerinin azim ve ısrarını ATM yazılımının hayatiyetine, ESARR 4 ciddiyet sınıflama şeması ile belirli bir olumsuz etkinin oluşması olasılığını birleştirerek, ilişkilendirir. 1. yazılım güvencesi seviyesi en hayati seviyeyi belirtmek üzere, en az 4 yazılım güvencesi seviyesi tanımlanmalıdır.
3.2 Ayrılmış bir yazılım güvencesi seviyesi ESARR 4’e göre yazılım arızaları ve hatalarının neden olabileceği en olumsuz etki ile denk düşmelidir. Bu, yazılım arızaları ve hataları ile ilişkili riskleri ve belirlenmiş yapısal ve/veya işlem-dizisel-procedural savunmaları(?-tedbirleri demek istiyor-ARS) hesaba katmalıdır.
3.3 Birbirlerinden bağımsız oldukları gösterilemeyen ATM yazılım unsurları bağımlı unsurlar arasındaki en hayati yazılım güvencesi seviyesine ayrılmalıdır.
4. YAZILIM ŞARTNAMESİ GEÇERLİLİK GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından yazılım şartlarının:
4.1 ATM yazılımının (normal ve geriseviyelendirilmiş-downgraded çalışma türlerinde) işlevsel davranışını, icra hız(?) seviyeleri, kapasite, doğruluk, hedef bilgisayarda yazılımın kaynak kullanımı, anormal işletimsel durumlarda ayakta kalma yeteneği - robustness
ve aşırı yüklenmeye dayanıklılık, uygun şekilde belirlemesi.
4.2 Tam ve doğru olmaları ve sistem güvenlik şartnamesi koşullarına uymaları gerekir.
5. YAZILIM GEÇERLİLİĞİ DOĞRULAMA GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
5.1 ATM yazılımının işlevsel davranışının, icra hız(?) seviyeleri, kapasite, doğruluk, hedef bilgisayarda yazılımın kaynak kullanımı, anormal işletimsel durumlarda ayakta kalma yeteneği - robustness ve aşırı yüklenmeye dayanıklılığının yazılım şartnamesi koşullarını sağlar.
5.2 ATM yazılımının geçerliliği, Atanmış Otorite ile mutabakata varıldığı gibi, analiz ve/veya deneme ve/veya eşdeğer yöntemlerle uygun bir şekilde doğrulanır.
5.3 ATM yazılımının geçerliliği doğru ve tamdır.
6. YAZILIM KURULUM-YAPISI(configuration) YÖNETİMİ GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
6.1 Yapısal-kurulum–configuration belirlemesi, iz-sürülebilirlik ve durum takibi-status accounting vardır öyle ki, ATM yazılım yaşam-döngüsü-lifecycle boyunca yazılım yaşam-döngüsü verilerinin yapısal-kurulum kontrolü altında olduğu gösterilebilir.
6.2 Sorun raporlama, takip ve düzeltici eylemler vardır öyle ki yazılıma ilişkin güvenlik ile ilgili sorunların azaltıldığı gösterilebilir.
6.3 Öyle yeniden ele alma ve hizmete sunma eylem dizileri-procedure vardır ki ATM yazılım yaşam-döngüsü sırasında yazılım yaşam-döngüsü verileri yeniden canlandırılabilir ve teslim edilebilir.
7. YAZILIM ŞARTNAMESİ İZSÜRÜLEBİLİRLİK GÜVENCELERİNE UYGULANAN ŞARTLAR
ATM servis-sağlayıcısı Yazılım Güvenliği Güvence Sistemi içinde, en azından şunlardan emin olmalıdır:
7.1 Sağlandığı gösterilmiş olan her tasarım seviyesine her bir yazılım şartının izi-sürülebilir.
7.2 Tasarımdaki her seviyede, sağlandığı gösterilmiş olan her bir yazılım şartının bir sistem şartına kadar izi-sürülebilir.
8. UYGULANABİLİRLİK
8.1 Bu güvenlik şartnamesi idari kontrolleri altındaki, yeryüzüne-konuşlandırılmış ATM sistemleri ve destek hizmetleri (CNS gibi)’nden sorumlu olan sivil ve askeri ATM hizmet sağlayıcıları için geçerlidir.
8.2 Askeri ATM kuruluşunun doğrudan idari kontrolü altındaki ATM sistemlerinin zaten var olan yazılım güvencesi sistemi, ESARR 6’nın zorunlu koşulları ile denk düşmek şartı ile geçerli kabul edilebilir.
8.3 Bu ESARR’ın zorunlu koşulları milli güvenlik düzenleyici şartnamelerin asgari koşulu olacaktır.
9. GERÇEKLEŞTİRME
9.1 ESARR 6’nın koşulları EUROCONTROL komisyonu tarafından onaylandığı tarihten itibaren 3 yıl içinde etkin olacaktır.
…
APPENDIX
…
Friday, February 02, 2007
HATA YAPMAK - TO MAKE A MISTAKE
HATA YAPMAK
Sevgili ortaokul edebiyat öğretmenim Münevver YARDIMSEVER’e…
46 yaşındayım. Ömrüm boyunca bir çok işi yanlış yaptım. Biliyorum bunu böyle söylemek bir hata ama yaptığım yanlışlar, doğrulardan çok daha fazla oldu hep… İnsan davranışı zaman zaman doğru(accuracy) olabiliyor ama ‘kesin’ (precision) olması imkansiz.
YNLIŞLr önemli değil. İnsan daha (af buyrun) çişini tutamadığı zamandan ölünceye kadar sürekli aynı grup yanlışları tekrarlayıp duruyor… Önemli olan yanlışların sonuçları… Maalesef yaptığımız bir çok yanlıştan bir kısmı kötü sonuçlar doğuruyor. Bu yanlışlar hatalara dönüşüyor.
Bir yanlışın hataya dönüşmesini(*) belirleyen, yalnız bizim tutumumuz değil, çevrenin de tutumu… Bilimsel dille söylersek, hatanın ağırlığını belirleyen bağlam(context)’dır. Bu kadar çok yanlış yapabilmemizi sağlayan da bu…
Maalesef, ömrüm boyunca yalnız bir çok yanlış değil o kadar olmasa da bir çok hata da yaptım. Ama hep yaptığım hataları, verip te tutmadığım sözleri, kırdığım kalpleri tamir etmeye çalıştım. Çünkü bir iki istisna dışında kastım yoktu. Belki biraz dikatsiz, belki düzensizdim. Eksiklerim, tutarsızlıklarım vardı ama çevremin sevgisi, hoşgörüsü ve vicdanı beni pek kabahatli bulmadı şimdiye kadar… Bir iki istisna dışında…
Bir şirkette, bir okulda, bir fabrikada, bir hva yolunda, bir Hava Trafik Kontrolü merkezinde kısacası irili ufaklı bir büyük sistemde, nerede olursanız olun hata, yanlış ve kusur, bu üç öğeyi yönetmek zorundasınız. Aslında iş kanunu bu konuda her ilgilinin okuması gereken güzel bir kaynak…
Yeri gelmişken EUROCONTROL(European Agency for the Safety of Air Navigation)’da edindiğim birkaç hoş anımı da nakletmek isterim. Karlsruhe UAC(Upper Air Control)’de operasyonel sistemin bakım ve geliştirilmesinde çalıştım. Yaptığım hatalar-yanlışlar-kusurlar havadaki yüzlerce uçağın güvenliğini etkiledi. Beş yıl içinde iki defa bütün sistemin çökmesine neden oldum. Uçaklar havada tur atıp yirmi dak. sistemin yeniden açılmasını beklemek zorunda kaldılar.
Bunların birincisinde, test ve operasyonel cihazların kontrol kısmında, cihazların üzerinde ‘operasyonel’ yazmadığı için, işe yeni başladığım sıralar, kontrolörlerin o anda kullandığı sistemin kapat düğmesine bastım. Onu test cihazı zannetmiştim ve bana yeterli bilgi verilmemişti. Zarar vermiştim… Ama tek kelime azar işitmedim.2-3 ay sonra laf arasında, aletlerin üstüne yeni uyarılar konmasıının nedeninin ben (ve İngiliz yöneticim Christopher WARREN) olduğunu öğrenmiştim.
İkincisinde durum vahimdi… Aşırı tartışmalar ve politika nedeni ile yıpranmış ve demotive olmuştum. Üstünde çalıştığım programda, test sırasında bütün sistemi durduran komutlar gördüm. Benim yaptığım test amaçlı değişiklik bunları da tetikleyebilecek olasılıktaydı… Yoğun tartışmalı test süreci sırasında operasyonel müdürümüz Van Der SLUIS ve Alman hava trafik kontrolör arayüzü EHRENBERGER iş bitti deyip almak istediler. Takatın tükenmişti, riskli durumu o an unutmuştum. Aln sizin olsun dedim… Bir ay kadar sonra, komşum SARGENT, sabah sekiz civarında, trafik yoğunken sistemin göçtüğünü haber verdi. Yaptığım Operational Deficiency işinin üstünden çok zaman geçtiği için hiç üstüme alınmadım. Bir iki saat sonra bu sefer sistem grubundan, ama grubun en genç Alman üyesi benim değişiklik yaptığım program ile yanıma geldi. Ben, bazı Avrupalı arkadaşların aksine yaptığım her şeye, yazdığım her satıra kullanıcı kmliğimi(kısa ismimi) koyarım. Tabii, hata olunca, önce hata yerini bulmuşlar sonrada ismimi görüp hemen beni bulmuşlar. Kısa bir tartışma oldu… Genç ve yumuşak bir arkadaş olduğu için ben sesimi yükselttim fakat fazla uzatmadım. O da sesini yükseltmek zorunda kaldı. Sonra hatayı en kısa zamanda düzelltik ve iş tatlıya bağlandı. Bu olayda başka hiç kimseden (sistem grup başkanı MÜHLSTROH dahil) laf işitmedim çünkü yaptığım hatanın altına imza atacak kadar dürüst ve iyi niyetliydim.
Bir de kusur ile ilgili hoş bir EUROCONTROL masalı… Evvel zaman içinde kalbur saman içinde bir hava tarfik kontrol merkezi varmış… Burada çalışan bir yazılım ekibi ile operasyonel ekip arasında çalışan bir hava tarfik kontrolörü varmış. Bu arayüz kontrolör bir gün bir başka ve güzel kontrolöre tutulmuş. Dayanamayıp, pır pır uçağı ile kontro merkezinin üzerinde uçağıyla ilanı aşk etmiş. Şimdi sorun, adamı cezalandırırsanız türünün yeganesi bir kontrolörün ehliyetiini kaybetmesine neden olursunuz… Arayüz kontrolörler haftada az da olsa gerçek kontrol işi yapmak zorunda… Sonuçta, herhalde bir hakime gitmişler… Hakim bizim ateşli aşık hava traik kontrolü – sistem arayüzünü iki maaşını cocuk esirgeme kurumuna bağışlamaya mahkum etmiş…
Onlar ermişler muratlarına yolcular varmışlar sağlımen evlerine…
Yazıma başlarken bir yanlış, hatta hata yapmıştım. Özür dilerim ama ne kadar ağır olursa olsun her yanlış hatta her hata daha iyisini daha güzelini yapmak için bir fırsata dönüştürülemez mi?
Size bol yanlışlı, bol hatalı, üstelik bol kusurlu ve çalışkan ve üretken ve uzun bir yaşam dilerim.
Ali Rıza SARAL
Editöre Not(Ağabeyim olurlar): Bu yazıdaki hataları düzelymeyiniz, bu hafta onlar da lazım.
(*) The Detection of Fault-Prone Programs ,Manson, Khoshgaffaar(HoşGaffar?),
IEEE Transactions on Software Engineering May 1992
Sevgili ortaokul edebiyat öğretmenim Münevver YARDIMSEVER’e…
46 yaşındayım. Ömrüm boyunca bir çok işi yanlış yaptım. Biliyorum bunu böyle söylemek bir hata ama yaptığım yanlışlar, doğrulardan çok daha fazla oldu hep… İnsan davranışı zaman zaman doğru(accuracy) olabiliyor ama ‘kesin’ (precision) olması imkansiz.
YNLIŞLr önemli değil. İnsan daha (af buyrun) çişini tutamadığı zamandan ölünceye kadar sürekli aynı grup yanlışları tekrarlayıp duruyor… Önemli olan yanlışların sonuçları… Maalesef yaptığımız bir çok yanlıştan bir kısmı kötü sonuçlar doğuruyor. Bu yanlışlar hatalara dönüşüyor.
Bir yanlışın hataya dönüşmesini(*) belirleyen, yalnız bizim tutumumuz değil, çevrenin de tutumu… Bilimsel dille söylersek, hatanın ağırlığını belirleyen bağlam(context)’dır. Bu kadar çok yanlış yapabilmemizi sağlayan da bu…
Maalesef, ömrüm boyunca yalnız bir çok yanlış değil o kadar olmasa da bir çok hata da yaptım. Ama hep yaptığım hataları, verip te tutmadığım sözleri, kırdığım kalpleri tamir etmeye çalıştım. Çünkü bir iki istisna dışında kastım yoktu. Belki biraz dikatsiz, belki düzensizdim. Eksiklerim, tutarsızlıklarım vardı ama çevremin sevgisi, hoşgörüsü ve vicdanı beni pek kabahatli bulmadı şimdiye kadar… Bir iki istisna dışında…
Bir şirkette, bir okulda, bir fabrikada, bir hva yolunda, bir Hava Trafik Kontrolü merkezinde kısacası irili ufaklı bir büyük sistemde, nerede olursanız olun hata, yanlış ve kusur, bu üç öğeyi yönetmek zorundasınız. Aslında iş kanunu bu konuda her ilgilinin okuması gereken güzel bir kaynak…
Yeri gelmişken EUROCONTROL(European Agency for the Safety of Air Navigation)’da edindiğim birkaç hoş anımı da nakletmek isterim. Karlsruhe UAC(Upper Air Control)’de operasyonel sistemin bakım ve geliştirilmesinde çalıştım. Yaptığım hatalar-yanlışlar-kusurlar havadaki yüzlerce uçağın güvenliğini etkiledi. Beş yıl içinde iki defa bütün sistemin çökmesine neden oldum. Uçaklar havada tur atıp yirmi dak. sistemin yeniden açılmasını beklemek zorunda kaldılar.
Bunların birincisinde, test ve operasyonel cihazların kontrol kısmında, cihazların üzerinde ‘operasyonel’ yazmadığı için, işe yeni başladığım sıralar, kontrolörlerin o anda kullandığı sistemin kapat düğmesine bastım. Onu test cihazı zannetmiştim ve bana yeterli bilgi verilmemişti. Zarar vermiştim… Ama tek kelime azar işitmedim.2-3 ay sonra laf arasında, aletlerin üstüne yeni uyarılar konmasıının nedeninin ben (ve İngiliz yöneticim Christopher WARREN) olduğunu öğrenmiştim.
İkincisinde durum vahimdi… Aşırı tartışmalar ve politika nedeni ile yıpranmış ve demotive olmuştum. Üstünde çalıştığım programda, test sırasında bütün sistemi durduran komutlar gördüm. Benim yaptığım test amaçlı değişiklik bunları da tetikleyebilecek olasılıktaydı… Yoğun tartışmalı test süreci sırasında operasyonel müdürümüz Van Der SLUIS ve Alman hava trafik kontrolör arayüzü EHRENBERGER iş bitti deyip almak istediler. Takatın tükenmişti, riskli durumu o an unutmuştum. Aln sizin olsun dedim… Bir ay kadar sonra, komşum SARGENT, sabah sekiz civarında, trafik yoğunken sistemin göçtüğünü haber verdi. Yaptığım Operational Deficiency işinin üstünden çok zaman geçtiği için hiç üstüme alınmadım. Bir iki saat sonra bu sefer sistem grubundan, ama grubun en genç Alman üyesi benim değişiklik yaptığım program ile yanıma geldi. Ben, bazı Avrupalı arkadaşların aksine yaptığım her şeye, yazdığım her satıra kullanıcı kmliğimi(kısa ismimi) koyarım. Tabii, hata olunca, önce hata yerini bulmuşlar sonrada ismimi görüp hemen beni bulmuşlar. Kısa bir tartışma oldu… Genç ve yumuşak bir arkadaş olduğu için ben sesimi yükselttim fakat fazla uzatmadım. O da sesini yükseltmek zorunda kaldı. Sonra hatayı en kısa zamanda düzelltik ve iş tatlıya bağlandı. Bu olayda başka hiç kimseden (sistem grup başkanı MÜHLSTROH dahil) laf işitmedim çünkü yaptığım hatanın altına imza atacak kadar dürüst ve iyi niyetliydim.
Bir de kusur ile ilgili hoş bir EUROCONTROL masalı… Evvel zaman içinde kalbur saman içinde bir hava tarfik kontrol merkezi varmış… Burada çalışan bir yazılım ekibi ile operasyonel ekip arasında çalışan bir hava tarfik kontrolörü varmış. Bu arayüz kontrolör bir gün bir başka ve güzel kontrolöre tutulmuş. Dayanamayıp, pır pır uçağı ile kontro merkezinin üzerinde uçağıyla ilanı aşk etmiş. Şimdi sorun, adamı cezalandırırsanız türünün yeganesi bir kontrolörün ehliyetiini kaybetmesine neden olursunuz… Arayüz kontrolörler haftada az da olsa gerçek kontrol işi yapmak zorunda… Sonuçta, herhalde bir hakime gitmişler… Hakim bizim ateşli aşık hava traik kontrolü – sistem arayüzünü iki maaşını cocuk esirgeme kurumuna bağışlamaya mahkum etmiş…
Onlar ermişler muratlarına yolcular varmışlar sağlımen evlerine…
Yazıma başlarken bir yanlış, hatta hata yapmıştım. Özür dilerim ama ne kadar ağır olursa olsun her yanlış hatta her hata daha iyisini daha güzelini yapmak için bir fırsata dönüştürülemez mi?
Size bol yanlışlı, bol hatalı, üstelik bol kusurlu ve çalışkan ve üretken ve uzun bir yaşam dilerim.
Ali Rıza SARAL
Editöre Not(Ağabeyim olurlar): Bu yazıdaki hataları düzelymeyiniz, bu hafta onlar da lazım.
(*) The Detection of Fault-Prone Programs ,Manson, Khoshgaffaar(HoşGaffar?),
IEEE Transactions on Software Engineering May 1992
Subscribe to:
Posts (Atom)
