DESENLER II
Desen ( pattern – Advanced Learner’s Dictionary, Hornby et all. ): Süsleme tasarımı; örnek; bir şeyin gerçekleştiği, geliştiği, düzenlendiği etc. şekil..
Desen ( Türk Dil Kurumu ): Bir kumaşı süsleyen çizgi, çiçek gibi şekillerin tümü, örnek.
Bir halı deseni tekrar eden düzenli unsurlardan oluşur. Aynı çiçek resminin tekrarı yani belirli bir motifin tekrarı düzen etkisini güçlendirir. Simetri aynı motifin bir referans noktası ya da çizgisine göre farklı bir şekilde çizilişi… Simetri bir yanı ile düzen hissini güçlendirirken öte yandan da ona bir çeşitlilik, bir farklılık katarak, zenginlik hissini arttırır.
Renk kullanımı da ilginçtir halılarımızın… Genellikle aynı şekil hep aynı renklerle boyanır. Bu şekilde motiflerin kişilikleri güçlendirilir. Şekillerin özellikle alt parçacıklarından bazıları farklı motiflere ait olsalar bile aynı renge boyanabilir. Bu yöntemle, şekiller arasında bir aynı bütüne ait oluş hissi kuvvetlendirilir. Renkler arasındaki zıtlıkve uyum da bütünlük hissini kuvvetlendirir.
Herhangi bir Anadolu halısına bakınız… Örneğin bir gül hep aynı şekilde sınırlı sayıda tekrarlanırken, yapraklar halı üzerinde bir çok farklı şekilde tekrarlanır… Anadolu halısının güzelliği tekrar edilen unsurlarla, tekrar edilmeyen unsurlar arasındaki ustaca ilişkiye, düzenle düzensizlik arasındaki dengeye dayanır…
Geçen hafta bu sütunda yayınlanan DESENLER I başlıklı yazımda, haddim olmayarak, yaşamımızdaki zaman desenleri, söz desenleri, kavram desenleri ve düşünüş desenlerine dikkatinizi çekmiştim. Yaşamımız düzenli düzensiz tekrar eden olaylarla dolu… Çoğu kez bir olayın tekrar edişi günlük yaşamımızı kolaylaştırıyor. Öte yandan toplu yaşayışın disiplini zaman zaman bizleri zorunlu düzenler içinde yaşamaya hapsediyor… Peki doğru olan ne? İnsan yaşamını güzel kılan ne?
Doğal dengeye bakarsak, tekrar eden düzenli olaylar, gece gündüz, mevsim yıl gibi çerçeve olaylar var. Tekrarlayan bu çerçeveler içinde ise, örn. her günün belirli rasgelelikleri, bazen bir sürprizi ya da tesadüfü yer alıyor. Tıpkı bir Anadolu halısında ana motiflerin hep aynı tekrar edişi, yaprak vb. detayların ise daha düzensiz, daha çeşitli oluşu gibi…
Hayatımızda tekrar eden unsurları bir süre sonra görmemeğe, hissetmemeğe, düşünmeden yapmağa başlarız. Boğaz köprüsünden her gün geçen bir kişinin Istanbul karşısındaki duyarsızlığı ile bir turistin hayranlığı arasındaki tezattır, belki de güzelliği yaratan bir başka unsur…
Bir piyanist egzersiz olarak o kadar çok temrin ya da tekrar yapar ki çalacağı parçayı artık hiç düşünmeden, otomatik olarak icra eder. Piyanistin çektiği zorluk, icra zorluğu, beynine yerleştirdiği schemata-kalıp ve otomatik süreçlerin devreye girdiği konser sırasında kendi duygusal sistemi ile bu mekanik süreçleri kontrol edişindedir belki de…
Yaşamımızda tekrar eden unsurlar bizim işimizi kolaylaştırıcı bir etki yaratırlar. Beynimizin tekrar tekrar kullanılan schemata-kalıplar ve bunları kullanan otomatik süreçlerle çalışışı, işlerimizi düzenli, tekrarlı yapmağa sevk eder bizi… Sorun otomatik süreçlerin, düşünüş, davranış ve duyuş kalıplarının yaratıcılık, uyanıklık, etki – tepki gibi süreçleri bastırışı geriletişidir. Zihinsel kalıpların ve otomatik süreçlerin ağırlığının artışı beynimizin düşünüş şeklinde katılığa yol açar. Hep aynı kalıplara, dogmalara bağlı düşünüş paranoyaya kadar varabilen hastalıklı bir yapıya yol açabilir.
Unutmayınız, bir düşünceye ya da inanca yapılacak en büyük kötülük ona karşıtı ile etkileşerek gelişmek hakkı, nefes almak hakkı, kısaca yaşamak hakkı tanımamak, o fikri ya da inancı gözü kara bir şekilde şiddetle savunmaktır.
Büyük sistemlerde yapılan ve felaketlere yol açan hatalara bakalım… Tekrar eden ve yoğun olmayan sistem girdileri, operatörün gelişen olayları gerçekte olduğu gibi değil kendi kafasında geliştirdiği desenlere göre algılayışına neden olur. Örneğin pilotlar, hava trafik kontrolörleri vb. sistemin en yüklü olduğu dönemlerden çok, işlerin azaldığı, yeknesaklığın arttığı dönemlerde ciddi hatalar yaparlar. Erken gece uçuşlarının risklerini arttıran bir unsur da budur. Hava trafik kontrolörünün başetmek zorunda olduğu bir güçlük te, her an için tıpkı bir piyano icracısı gibi hem kendi kafasındaki bir takım kalıpları kullanmak hem de bu sırada zihinsel tazeliğini koruyabilmek…
Yaşamımızdaki tazeliği koruyabilmek için tekrar eden faaliyetlerimiz ile kural dışı olan, düzensiz şeylerimizi dengeleyişimiz, bazen güzel bir sürpriz espri yapabilişimiz, bazen her şeyi her zamankinden biraz daha önce ya da sonra yapışımız, Istanbul’umuza hep aynı gözle değil bir radar ekranındaki gibi, farklı farklı, küçük büyük ölçekli pencerelerden bakabilişimiz, acaba kişisel güzelliğimizi de arttırmaz mı?
Ali Rıza SARAL
Koşuyolu, ISTANBUL
Bazı kaynaklar:
Doğan CÜCELOĞLU, İnsan ve Davranışı
Michael W. EYSENCK, Mark T. KEANE, Cognitive Psychology
Steven L. TANIMOTO, The Elements of Artificial Intelligence
Wednesday, May 23, 2007
Sunday, May 13, 2007
DİNAMİK SEVİYE BÖLÜNMESİ - DINAMIC LEVEL SPLIT
DİNAMİK SEVİYE BÖLÜNMESİ - DINAMIC LEVEL SPLIT
Düzenleyen: Ali Rıza SARAL
Hava trafik kontrolünde trafiği bölme, kısımlara ayırma işlemleri kontrolör üzerindeki yükü azaltmak ve eminliği arttırmak amacı ile yapılır.
Aynı coğrafi konum üzerinde yer alan hava sahasının üst üste yeralan iki sektöre ayrılmasına seviye bölünmesi denir.
Kontrol edilen hava sahasının bölünmesi yalnız düşey olarak değil coğrafi olarak ta yapılabilir. Bu durumda söz konusu coğrafi bölgeye ilişkin hava sahası yatay olarak yeryüzü üzerindeki belirlenen bir referans çizgisine göre bölünür.
Bir başka bölünme şekli de fonksiyonel bölünmedir. Bu durumda örneğin askeri amaçlarla kullanılan bir bölge genel hava trafiğine yasaklanır.
Güçlükleri aşmak için yalnız trafik yükünü bölmek yetmez. Çünkü her bölünme daha çok miktarda kaynağın, örn. hava trafik kontrolörünün kullanılmasını ya da başka kaynakların bu yöne yönlendirilmesine neden olur... Oysa bir hava trafik kontrolü merkezinin bile kaynakları belirli süreler için sabit ve sınırlıdır. Bu yüzden yükün bölünmesi işleminin dinamik olarak yapılması gerekir.
Bu yazı bir örnek olarak, dinamik seviye bölünmesi konusunu ele alacak, konunun teknik yönlerini inceleyecektir. Dinamizm kontrol mekanizmasına ilişkin karmaşıklığı arttır fakat kaynakların daha randımanlı kullanılmasını sağlar.
EUROCONTROL Experimental Center - EEC'nin DHMI için hazırladığı 396 no'lu raporunda "Günün 24 saati boyunca ve mevsimsel olarak trafik yükünün değişe durduğunu, sektörlerin birleştirilmesi ve bölünmesinin sürekli bir işlem olduğunu ve bunun mümkün olduğunca çok dinamik yapılması gerektiğini" belirtir. "2015 seneryosu için yapılan başka deneylerde uçuş acentalarının yol seçimleri sektör yüklenmesini önemli derecede etkilemiştir. Ek sektörleşme yeteneği geçici yükü rahatlatabilmek için mümkün olduğunca çok dinamik yapılmalıdır."
Yazımın bir amacı da dinamizmin yan etkileri ve üstünlükleri üzerine günlük faydaları olabilecek soyutlamalar yapmak, pratik dersler, rule-of-thumb'lar çıkarmaktır.
1. Bugün bir hava trafik kontrol sisteminin çalışmasından anlaşılan yapılacak işlerin otomatik olarak ilgili kişilere atanmasıdır.
1. Coğrafik yer (sektor)
2. Uçuş türü (sivil / askeri)
3. E1, E2, E3(Executive controller)'e statik veri bankası kanalı ile yol kısmı ilişkilendirmesi
- route segment association
4. Var olan operasyonel pozisyonların yönetimi Operational Position Management
Dinamik Seviye Bölünmesi on route uçuş kısımları için yukarıda 3. maddedeki statik veri bankası kanalı ile belirlenen yol kısmı ilişkilendirmesi unsurunun yerini alacaktır. Off-route yani askeri trafik değişmeyecektir. Bu kavramı gerçekleştirebilmek için bir on-route sektor içindeki çalışma konumlarını dinamik olarak tanımlayabilmek gerekir. Böylece sektör ayrı ayrı iki bağımsız kısım, alt ve üst kısımlar şeklinde kullanılabilir. Ayrıca üst ve alt kısımların tek tek kapatılabilirliği gereklidir.
Görevlerin üst ve/veya alt kısımlara atanması bir uçuş kayıdının Bölünüş Uçuş Seviyesi – (DFL-Division Flight Level) ile ilişkisine göre kontrol edilecektir. Bu Uçuş Bölünüş Seviyesi uçuş bölgesinin (LIR ya da UIR-Upper Information Region) tümüne uygulanan bir parametre olacaktır, yani bu parametre SDB(Statik veri bankası) aracılığı ile değiştirilebilecek fakat verilmiş bir coğrafi sektör için ayrıcalıklı olarak belirlenemeyecektir.
Seviye bölünmesinin var olan bir sistem üzerinde gerçekleştirilişi pozisyon sayıları vb. o anda var olan özelliklerin belirleyeceği sınırlar içinde yapılabilir.
Seviye bölünüşünün gerçekleştirilişi şu sistem özelliklerini etkiler:
a) OPM
b) bir kısımdan diğerine geçişlerin(transitions) tanımı
c) Şeritler(strips)
d) Elektronik Veri Ekranı (EDD-electroninc data display) çağrı işaretleri(callsigns)
e) Dokunmatik giriş cihazı (TID-touch input device) input orders
2. OPM
2.1 Şu anda var olan on-route sektor tanımları aşağıdaki özellikleri kaplar.
a) P6 function (on- or off-route) Yani bir dokunmatik giriş cihazı (TID) ve Elektronik Veri Ekranı(EDD) donanımlı bir off-route planlama konumu, P6
b) konu olan sektor (eğer açıksa kendisi)
c) kontrolör konumları (P1, P2, C1, E1, E2, E3)
d) strip makinaları (P ve E)
e) uçuş veri cihazları (PA1, PA2, KDS, CPR)
Burada bir modern kontrol merkezinde bulunması gereken on-route sistem konfigurasyonu belirtilmiştir. Yani on-route için:
(( 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 , C1
- 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))
Seviye bölünüşü için değiştirilmiş hali aşağıdaki gibidir:
a) P6 fonksiyonu değiştirilemez ve off-route olarak kalır.
b) söz konusu iki sektör alt ve üst olarak giriş alacaklardır.
c) kontrolör konumları P1, C1, E1 ve E2 ile sınırlandırılmıştır.
d) şerit kanalları aynı kalacaktır.
e) uçuş veri ciahazlarında hiçbir değişikik yoktur.
Off-route sektor değişmeden aynı kalacaktır.
2.2 Grup Yapısal Dağılımları Üzerine
Bir on-route grup içinde arzulanan “İş birimleri” P1, E1 birlikte ve C1, E2 birlikte olmasıdır. Dönüşüm ile P1, E1 “üst kısım” C1,E2 ise “alt kısım” olacaktır. OPM-İşletimsel Konum Yönetimi aracılığı ile bir sektor şu durumlardan birine sahip olarak tanımlanabilir.
Kapalı - hem alt hem üst her iki sektor de baska bir sektor üzerine kapatılmış.
Birleşik - sektör açık ve bir sektör hem alt hem üst her iki kısımın yükünü taşıyor
Üst yalnız - bir kısım açık ve yalnız üst görevlerini taşıyor alt kısım başka bir sektör üzerine kapatılmış
Alt yalnız - bir kısım açık ve yalnız alt görevlerini taşıyor üst kısım başka bir sektör üzerine kapatılmış
Bölünmüş - her iki kısım açık ve ayrı ayrı alt ve üst görevlerini taşıyor
Bir sektörün durumu alt ve üst iki sektör alt-kimliğinin atanışı ve sektör içindeki “açık” kontrol konumları tarafından belirlenir. Bu amaçla “geçerli sektör düzeni” adlı tablo yapılır.
Arzu edilmeyen görev bileşimlerinin oluşmaması için kısımların kapanışına da bazı sınırlamalar uygulanır, örn. birleştirilmiş sektör bir sektörden üst diğer sektörden alt kısım görevleri içermemelidir.
Aşağıdaki tablo geçerli üst ve alt kısım bileşimi iptallerini vermektedir.
Üst kısım
-------------
Kendi AY ÜY BLŞ AYRI
----------------------------- --------- --------- ----------
Kendi E H E H E
------------------------------ --------- --------- ----------
AY E H E H E
------------------------------ --------- --------- ----------
Alt kısım ÜY H H H H H
------------ ------------------------------ --------- --------- ----------
BLŞ H H H E* H
------------------------------ --------- --------- ----------
AYRI E H E H E
------------------------
S = self (not collapsed in other sector)
AY = Alt yalnız
ÜY = Üst yalnız
BLŞ = Birleşik
SPL = Split
Alt ve üst kısım aynı sektöre ait olmalı
3. DFL geçişleri tanımı
3.1 Sektör üstünden geçişler üst ya da alt kısıma atanır.
Bir sektör içinde on route-yol üzerinde DFL’i kesen uçuşler her iki kısım tarafından ele alınacaktır. Belirli bir sektör içinde bir uçuş hem on-route hem de off-route(hybrid-karışık) olabilir. Bir uçuşun belirli bir sektör içindeki kısmına Sektör Yol Dizisi – Sector Route Sequence(SRS) denir. Belirli bir SRS içinde aynı tür (on veya off route)’e sahip uçuş parçasına Kontrol Yol Dizisi -Control Route Sequence(CRS) denir. Bu yüzden, karma bir uçuş sektör için bir SRS ve en az iki CRS’e sahip olacaktır. CRS’lerin sayısı bir sektör içindeki tür değişimi geçişlerinin sayısına bağlı olacaktır. DFL geçişleri yalnız on-route CRS’leri ile ilgilidir.
3.2 DFL geçişleri uçuş kesiti(profili) CRS giriş seviyesi (NFL-entry level) ve CRS çıkış seviyesi(XFL-exit level)ni dikkate alarak tespit edilir.
Uçuş kesiti en azından alt kesimler için görev atamasını zorunlu kılmak için kullanılır, yani bir ayrılış – departure’un ilk SRS’i veya bir RFL giriş kesiti içindeki CRS’ler her zaman DFL’den daha az bir giriş seviyesine sahip kabul edileceklerdir. Bir varışın son SRS’indeki veya RFL çıkış kesitindeki CRS’ler her zaman DFL’den daha düşük bir çıkış seviyesine sahip kabul edileceklerdir. CRS giriş seviyesi (NFL) ve çıkış seviyesi(XFL), tahmin-estimate ve TID uçuş seviyesi(TFL) girişi olarak CFL ve KFL’in fonksiyonlarıdırlar.
Uçuş seviyesi yayılımı-propagation aşağıdaki gibidir:
Aktif bir uçuş en azından giriş seviyesi olarak değerlendirilen girilmiş bir CFL’e sahiptir. KFLi eğer bir tahmin-estimate ile girilmişse bir nokta ile ilişkilendirilmiştir. Bu seviye, KFL, ilgili noktadan sonra geçerli kabul edilir ve CRS’in sonuna kadar geçerli kabul edilir ve burada gelecek CRS’in CFL’i bu KFL değerini alır.
TID(TFL) ile girilmiş bir uçuş seviyesi doğrudan doğruya noktalarla ilişkili değildir ve seviye hangi CRS için giriliyorsa onun ilk noktası ile ilişkilendirilir. Seviye daha sonra LRS’in sonuna kadar(genellikle sektör sınırı) ya da bir TFL değeri önceden girilmiş olan herhangi bir CRS’e kadar yayılarak taşınır. TFL bir CRS’ten çıkış seviyesi olarak kabul edilir.
3.3 Genel olarak bir geçiş CRS’i DFL’in giriş seviyesi(NFL-entry FL) ve çıkış seviyesi (XFL) arasında kaldığı bir CRS olarak tanımlanır. Uçuş kesiti kurallarının doğru bir durum yaratmayacağı, çift DFL geçişli özel hallerde dikkate alınmalıdır.
3.4 Uçuş kesiti, CFL ve KFL’in hazır olduğu uçuş planı harekete geçirimi(flight plan activation)nde DFL geçişi CRS’leri başlangıçtan işaretleneceklerdir. Ondan sonra bir CRS TID KFL aracılığı ile geçiş CRS’ine dönüşebilir. Geçiş CRS’i olmayan CRS’ler alt ya da üst CRS olarak işaretlenecektir.
4. Uçuş İlerleme Şeritleri (Flight Progress Strips)
4.1 PA şeritleri olası bir üst, alt yada her ikisi için üretileceklerdir. Üretilen şeritlerin sayısı, şerit kalıpları ve mantıksal-logical yazıcı konumları SRS içindeki CRS durumları ve işletim yapısı dağılımı ile belirlenecektir. Şeritin ait olduğu sektörü ve hangi kısım için üretildiğinin belirtileceği öngörülmektedir.
4.2 Uyarı Şeritleri - Warning Strips
Yalnız PA şeritlerinin üretimine neden olan W2 eylemleri için değişiklikler yapılır. CRS durumları harekete geçirmeye(activation) kadar CRS durumları belirlenmediği için, üst kısım kullanılıp kullanılmayacağına karar vermek için RFL’ler kullanılır. Her SRS için, bugün alt kısım için olduğu gibi W2 PA şeritleri üretilir. Eğer sektör çıkış noktası(SPX) DFL’den yukarıda ise PA şeritleri ”üst” yazım kalıbına-format uygun olarak tekrar basılır ve ilgili üst kısım yazıcısına yönlendirilir-routed – eğer (yalnızca bu koşul altında) söz konusu üst sektör “bölünmüş” ya da “yalnız üst kısım” olarak tanımlı ise.
4.3 Gerçek Şeritler - Real Strips
Gerçek PA - Real PA şeritleri şunların sonucunda üretilir:
a) Sektör için normal PA olayı -Normal PA event for sector
b) TID yolu ile gerçek hiç bir şerit basılmamış olan bir kısımda değişikliğe neden olan uçuş seviyesi girişi nedeni ile oluşan tekrar basım
c) KDS tekrar basımı istendiğinde -reprint request
4.3.1 Sektör için normal PA olayı - Normal PA Event for sector
Söz konusu SRS için on-route CRS’ler değerlendirilir ve CRS durumu üst, alt ya da geçiş olarak sonuçlandırılır.
4.3.2 TFLtekrar Basımları
Aktif bir uçuş için TID aracılığıyle bir uçuş seviyesi girildiğinde, TFL girişi yapan kontrolörler ilgili CRS’ten bir çıkış seviyesi olarak kabul edilir. CRS durumları giriş yapılan CRS’ten LRS içindeki son CRS’e kadar CRS durumları yenniden hesaplanır. Şeritleri basılmış olan her SRS 4.3.1’de olduğu gibi yeniden gözden geçirilir. Eğer bir SRS durumu bir şerit kalıbının basılmadığını gösterirse, ilgili şerit basılır, not edilir ve ilgili yere yönlendirilir.
4.3.3 KDS Tekrar Basımı
KDS tekrar basımlarının felsefesi korunur yani istenen sektör için asılmış şeritler yeniden basılır. Ayrık sektörlerde kesim geçiş uçuşları durumunda hem alt hem de üst bilgi kalıpları basılır.
4.4 Şerit Yazıcılarının Kullanımı - Use of Strip Printers
Eğer bir on-route(yol üstü) sektör grubu birleşik veya yalnız başına çalışrken, şu anda var olan 2 PS şerit yazıcısını kullnım felsefesi devam ettirilir. Bir on-route sektör grubu ayrık türde-mode çalışıyorsa, PA1 yazıcısı alt kısım şeritleri için PA2 yazıcısı üst şeritler için kullanılır.
5. EDD/TID ÇAĞRI İŞARETİ DAĞITIMI - EDD/TID CALLSIGN DISTRIBUTION
5.1 Şu anda, bir on-route CRS için dört çağrı işareti olayı vardır, yani P1, P2, C1, E.
P1 ve P2 olayları yok edilecek. C1 ve E olayları tutulacak ve olay işlenmesi – event processing seviye bölünüşü şartlarını sağlamak için değiştirilecek. C1 olayı her on-route CRS için vardır. CRS durumu hangi mantıksal pozisyonların-logical positions çağrı işaretini alacağını belirler.
Yani,
CRS üst - mantıksal P1
CRS alt - mantıksal C1
CRS geçiş - mantıksal P1 + mantıksal C1
E olayı her IRS -intermediate route sequence için vardır. On-route uçuşları için, bir EC tipi için yol kısımlarını-route segments tanımlama yeteneği iptal edildiği için IRS bir CRS ile aynı kapsama sahip olacaktır. IRS’in ebeveyn CRS’i kullanılarak hangi mantıksal konumların çağrı işaretini alacağı belirlenir.
Yani;
CRS üst - mantıksal E1
CRS alt - mantıksal E2
CRS geçiş - mantıksal E1 + mantıksal E2
Çağrı işaretini alacak gerçek konum OPM ile belirlenir yani üst kısım için mantıksal P1, E1
ve alt kısım için mantıksal C1, E2.
OPM tarafından kullanılan konumlar için yerine geçiş düzeni şöyledir:
P1 - P1, E1, C1, E2 (üst konu sektör)
C1 - C1, E2, P1, E1 (alt konu sektör)
E1 - E1, E2 (üst konu sektör)
E2 - E2, E1 (alt konu sektör)
5.2 Seviye bölünmesi kavramından önce, her uçuş kısmı yalnızca bir yetkili kontrolör (EC-executive controller)’e verildiği için belirli bir LRS için geçerli EC sıralamasına katı kurallar uygulanırdı. Bu felsefe CRS geçişlerinin olduğu durumlarda artık geçerli değildir. Artık sistemin belirli bir CRS için iki EC’yi devreye sokması gerekmektedir. Sistemin, bir CRS geçişi için seçilecek ilk EC’yi CRS giriş seviyesinden bulması gerekmektedir. Bir çok durumda ikinci EC’nin bulunması için çıkış seviyesi kullanılabilir fakat ilk EC’nin aynı zamanda üçüncü EC olduğu durumlar da vardır.
It is suggested that the system should set the first EC according to the NFL and allow automatic assume to function for this first EC. No automatic assume would be made to the second ( or third ) EC. Here the "hybrid rule" could apply ie. if no manual assume is made then the flight would be automatically assumed in the next geographical sector.
If the second EC makes a manual assume then data is cleared down from the first EC and coupled coordinator .
Düzenleyen: Ali Rıza SARAL
Hava trafik kontrolünde trafiği bölme, kısımlara ayırma işlemleri kontrolör üzerindeki yükü azaltmak ve eminliği arttırmak amacı ile yapılır.
Aynı coğrafi konum üzerinde yer alan hava sahasının üst üste yeralan iki sektöre ayrılmasına seviye bölünmesi denir.
Kontrol edilen hava sahasının bölünmesi yalnız düşey olarak değil coğrafi olarak ta yapılabilir. Bu durumda söz konusu coğrafi bölgeye ilişkin hava sahası yatay olarak yeryüzü üzerindeki belirlenen bir referans çizgisine göre bölünür.
Bir başka bölünme şekli de fonksiyonel bölünmedir. Bu durumda örneğin askeri amaçlarla kullanılan bir bölge genel hava trafiğine yasaklanır.
Güçlükleri aşmak için yalnız trafik yükünü bölmek yetmez. Çünkü her bölünme daha çok miktarda kaynağın, örn. hava trafik kontrolörünün kullanılmasını ya da başka kaynakların bu yöne yönlendirilmesine neden olur... Oysa bir hava trafik kontrolü merkezinin bile kaynakları belirli süreler için sabit ve sınırlıdır. Bu yüzden yükün bölünmesi işleminin dinamik olarak yapılması gerekir.
Bu yazı bir örnek olarak, dinamik seviye bölünmesi konusunu ele alacak, konunun teknik yönlerini inceleyecektir. Dinamizm kontrol mekanizmasına ilişkin karmaşıklığı arttır fakat kaynakların daha randımanlı kullanılmasını sağlar.
EUROCONTROL Experimental Center - EEC'nin DHMI için hazırladığı 396 no'lu raporunda "Günün 24 saati boyunca ve mevsimsel olarak trafik yükünün değişe durduğunu, sektörlerin birleştirilmesi ve bölünmesinin sürekli bir işlem olduğunu ve bunun mümkün olduğunca çok dinamik yapılması gerektiğini" belirtir. "2015 seneryosu için yapılan başka deneylerde uçuş acentalarının yol seçimleri sektör yüklenmesini önemli derecede etkilemiştir. Ek sektörleşme yeteneği geçici yükü rahatlatabilmek için mümkün olduğunca çok dinamik yapılmalıdır."
Yazımın bir amacı da dinamizmin yan etkileri ve üstünlükleri üzerine günlük faydaları olabilecek soyutlamalar yapmak, pratik dersler, rule-of-thumb'lar çıkarmaktır.
1. Bugün bir hava trafik kontrol sisteminin çalışmasından anlaşılan yapılacak işlerin otomatik olarak ilgili kişilere atanmasıdır.
1. Coğrafik yer (sektor)
2. Uçuş türü (sivil / askeri)
3. E1, E2, E3(Executive controller)'e statik veri bankası kanalı ile yol kısmı ilişkilendirmesi
- route segment association
4. Var olan operasyonel pozisyonların yönetimi Operational Position Management
Dinamik Seviye Bölünmesi on route uçuş kısımları için yukarıda 3. maddedeki statik veri bankası kanalı ile belirlenen yol kısmı ilişkilendirmesi unsurunun yerini alacaktır. Off-route yani askeri trafik değişmeyecektir. Bu kavramı gerçekleştirebilmek için bir on-route sektor içindeki çalışma konumlarını dinamik olarak tanımlayabilmek gerekir. Böylece sektör ayrı ayrı iki bağımsız kısım, alt ve üst kısımlar şeklinde kullanılabilir. Ayrıca üst ve alt kısımların tek tek kapatılabilirliği gereklidir.
Görevlerin üst ve/veya alt kısımlara atanması bir uçuş kayıdının Bölünüş Uçuş Seviyesi – (DFL-Division Flight Level) ile ilişkisine göre kontrol edilecektir. Bu Uçuş Bölünüş Seviyesi uçuş bölgesinin (LIR ya da UIR-Upper Information Region) tümüne uygulanan bir parametre olacaktır, yani bu parametre SDB(Statik veri bankası) aracılığı ile değiştirilebilecek fakat verilmiş bir coğrafi sektör için ayrıcalıklı olarak belirlenemeyecektir.
Seviye bölünmesinin var olan bir sistem üzerinde gerçekleştirilişi pozisyon sayıları vb. o anda var olan özelliklerin belirleyeceği sınırlar içinde yapılabilir.
Seviye bölünüşünün gerçekleştirilişi şu sistem özelliklerini etkiler:
a) OPM
b) bir kısımdan diğerine geçişlerin(transitions) tanımı
c) Şeritler(strips)
d) Elektronik Veri Ekranı (EDD-electroninc data display) çağrı işaretleri(callsigns)
e) Dokunmatik giriş cihazı (TID-touch input device) input orders
2. OPM
2.1 Şu anda var olan on-route sektor tanımları aşağıdaki özellikleri kaplar.
a) P6 function (on- or off-route) Yani bir dokunmatik giriş cihazı (TID) ve Elektronik Veri Ekranı(EDD) donanımlı bir off-route planlama konumu, P6
b) konu olan sektor (eğer açıksa kendisi)
c) kontrolör konumları (P1, P2, C1, E1, E2, E3)
d) strip makinaları (P ve E)
e) uçuş veri cihazları (PA1, PA2, KDS, CPR)
Burada bir modern kontrol merkezinde bulunması gereken on-route sistem konfigurasyonu belirtilmiştir. Yani on-route için:
(( 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 , C1
- 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))
Seviye bölünüşü için değiştirilmiş hali aşağıdaki gibidir:
a) P6 fonksiyonu değiştirilemez ve off-route olarak kalır.
b) söz konusu iki sektör alt ve üst olarak giriş alacaklardır.
c) kontrolör konumları P1, C1, E1 ve E2 ile sınırlandırılmıştır.
d) şerit kanalları aynı kalacaktır.
e) uçuş veri ciahazlarında hiçbir değişikik yoktur.
Off-route sektor değişmeden aynı kalacaktır.
2.2 Grup Yapısal Dağılımları Üzerine
Bir on-route grup içinde arzulanan “İş birimleri” P1, E1 birlikte ve C1, E2 birlikte olmasıdır. Dönüşüm ile P1, E1 “üst kısım” C1,E2 ise “alt kısım” olacaktır. OPM-İşletimsel Konum Yönetimi aracılığı ile bir sektor şu durumlardan birine sahip olarak tanımlanabilir.
Kapalı - hem alt hem üst her iki sektor de baska bir sektor üzerine kapatılmış.
Birleşik - sektör açık ve bir sektör hem alt hem üst her iki kısımın yükünü taşıyor
Üst yalnız - bir kısım açık ve yalnız üst görevlerini taşıyor alt kısım başka bir sektör üzerine kapatılmış
Alt yalnız - bir kısım açık ve yalnız alt görevlerini taşıyor üst kısım başka bir sektör üzerine kapatılmış
Bölünmüş - her iki kısım açık ve ayrı ayrı alt ve üst görevlerini taşıyor
Bir sektörün durumu alt ve üst iki sektör alt-kimliğinin atanışı ve sektör içindeki “açık” kontrol konumları tarafından belirlenir. Bu amaçla “geçerli sektör düzeni” adlı tablo yapılır.
Arzu edilmeyen görev bileşimlerinin oluşmaması için kısımların kapanışına da bazı sınırlamalar uygulanır, örn. birleştirilmiş sektör bir sektörden üst diğer sektörden alt kısım görevleri içermemelidir.
Aşağıdaki tablo geçerli üst ve alt kısım bileşimi iptallerini vermektedir.
Üst kısım
-------------
Kendi AY ÜY BLŞ AYRI
----------------------------- --------- --------- ----------
Kendi E H E H E
------------------------------ --------- --------- ----------
AY E H E H E
------------------------------ --------- --------- ----------
Alt kısım ÜY H H H H H
------------ ------------------------------ --------- --------- ----------
BLŞ H H H E* H
------------------------------ --------- --------- ----------
AYRI E H E H E
------------------------
S = self (not collapsed in other sector)
AY = Alt yalnız
ÜY = Üst yalnız
BLŞ = Birleşik
SPL = Split
Alt ve üst kısım aynı sektöre ait olmalı
3. DFL geçişleri tanımı
3.1 Sektör üstünden geçişler üst ya da alt kısıma atanır.
Bir sektör içinde on route-yol üzerinde DFL’i kesen uçuşler her iki kısım tarafından ele alınacaktır. Belirli bir sektör içinde bir uçuş hem on-route hem de off-route(hybrid-karışık) olabilir. Bir uçuşun belirli bir sektör içindeki kısmına Sektör Yol Dizisi – Sector Route Sequence(SRS) denir. Belirli bir SRS içinde aynı tür (on veya off route)’e sahip uçuş parçasına Kontrol Yol Dizisi -Control Route Sequence(CRS) denir. Bu yüzden, karma bir uçuş sektör için bir SRS ve en az iki CRS’e sahip olacaktır. CRS’lerin sayısı bir sektör içindeki tür değişimi geçişlerinin sayısına bağlı olacaktır. DFL geçişleri yalnız on-route CRS’leri ile ilgilidir.
3.2 DFL geçişleri uçuş kesiti(profili) CRS giriş seviyesi (NFL-entry level) ve CRS çıkış seviyesi(XFL-exit level)ni dikkate alarak tespit edilir.
Uçuş kesiti en azından alt kesimler için görev atamasını zorunlu kılmak için kullanılır, yani bir ayrılış – departure’un ilk SRS’i veya bir RFL giriş kesiti içindeki CRS’ler her zaman DFL’den daha az bir giriş seviyesine sahip kabul edileceklerdir. Bir varışın son SRS’indeki veya RFL çıkış kesitindeki CRS’ler her zaman DFL’den daha düşük bir çıkış seviyesine sahip kabul edileceklerdir. CRS giriş seviyesi (NFL) ve çıkış seviyesi(XFL), tahmin-estimate ve TID uçuş seviyesi(TFL) girişi olarak CFL ve KFL’in fonksiyonlarıdırlar.
Uçuş seviyesi yayılımı-propagation aşağıdaki gibidir:
Aktif bir uçuş en azından giriş seviyesi olarak değerlendirilen girilmiş bir CFL’e sahiptir. KFLi eğer bir tahmin-estimate ile girilmişse bir nokta ile ilişkilendirilmiştir. Bu seviye, KFL, ilgili noktadan sonra geçerli kabul edilir ve CRS’in sonuna kadar geçerli kabul edilir ve burada gelecek CRS’in CFL’i bu KFL değerini alır.
TID(TFL) ile girilmiş bir uçuş seviyesi doğrudan doğruya noktalarla ilişkili değildir ve seviye hangi CRS için giriliyorsa onun ilk noktası ile ilişkilendirilir. Seviye daha sonra LRS’in sonuna kadar(genellikle sektör sınırı) ya da bir TFL değeri önceden girilmiş olan herhangi bir CRS’e kadar yayılarak taşınır. TFL bir CRS’ten çıkış seviyesi olarak kabul edilir.
3.3 Genel olarak bir geçiş CRS’i DFL’in giriş seviyesi(NFL-entry FL) ve çıkış seviyesi (XFL) arasında kaldığı bir CRS olarak tanımlanır. Uçuş kesiti kurallarının doğru bir durum yaratmayacağı, çift DFL geçişli özel hallerde dikkate alınmalıdır.
3.4 Uçuş kesiti, CFL ve KFL’in hazır olduğu uçuş planı harekete geçirimi(flight plan activation)nde DFL geçişi CRS’leri başlangıçtan işaretleneceklerdir. Ondan sonra bir CRS TID KFL aracılığı ile geçiş CRS’ine dönüşebilir. Geçiş CRS’i olmayan CRS’ler alt ya da üst CRS olarak işaretlenecektir.
4. Uçuş İlerleme Şeritleri (Flight Progress Strips)
4.1 PA şeritleri olası bir üst, alt yada her ikisi için üretileceklerdir. Üretilen şeritlerin sayısı, şerit kalıpları ve mantıksal-logical yazıcı konumları SRS içindeki CRS durumları ve işletim yapısı dağılımı ile belirlenecektir. Şeritin ait olduğu sektörü ve hangi kısım için üretildiğinin belirtileceği öngörülmektedir.
4.2 Uyarı Şeritleri - Warning Strips
Yalnız PA şeritlerinin üretimine neden olan W2 eylemleri için değişiklikler yapılır. CRS durumları harekete geçirmeye(activation) kadar CRS durumları belirlenmediği için, üst kısım kullanılıp kullanılmayacağına karar vermek için RFL’ler kullanılır. Her SRS için, bugün alt kısım için olduğu gibi W2 PA şeritleri üretilir. Eğer sektör çıkış noktası(SPX) DFL’den yukarıda ise PA şeritleri ”üst” yazım kalıbına-format uygun olarak tekrar basılır ve ilgili üst kısım yazıcısına yönlendirilir-routed – eğer (yalnızca bu koşul altında) söz konusu üst sektör “bölünmüş” ya da “yalnız üst kısım” olarak tanımlı ise.
4.3 Gerçek Şeritler - Real Strips
Gerçek PA - Real PA şeritleri şunların sonucunda üretilir:
a) Sektör için normal PA olayı -Normal PA event for sector
b) TID yolu ile gerçek hiç bir şerit basılmamış olan bir kısımda değişikliğe neden olan uçuş seviyesi girişi nedeni ile oluşan tekrar basım
c) KDS tekrar basımı istendiğinde -reprint request
4.3.1 Sektör için normal PA olayı - Normal PA Event for sector
Söz konusu SRS için on-route CRS’ler değerlendirilir ve CRS durumu üst, alt ya da geçiş olarak sonuçlandırılır.
4.3.2 TFLtekrar Basımları
Aktif bir uçuş için TID aracılığıyle bir uçuş seviyesi girildiğinde, TFL girişi yapan kontrolörler ilgili CRS’ten bir çıkış seviyesi olarak kabul edilir. CRS durumları giriş yapılan CRS’ten LRS içindeki son CRS’e kadar CRS durumları yenniden hesaplanır. Şeritleri basılmış olan her SRS 4.3.1’de olduğu gibi yeniden gözden geçirilir. Eğer bir SRS durumu bir şerit kalıbının basılmadığını gösterirse, ilgili şerit basılır, not edilir ve ilgili yere yönlendirilir.
4.3.3 KDS Tekrar Basımı
KDS tekrar basımlarının felsefesi korunur yani istenen sektör için asılmış şeritler yeniden basılır. Ayrık sektörlerde kesim geçiş uçuşları durumunda hem alt hem de üst bilgi kalıpları basılır.
4.4 Şerit Yazıcılarının Kullanımı - Use of Strip Printers
Eğer bir on-route(yol üstü) sektör grubu birleşik veya yalnız başına çalışrken, şu anda var olan 2 PS şerit yazıcısını kullnım felsefesi devam ettirilir. Bir on-route sektör grubu ayrık türde-mode çalışıyorsa, PA1 yazıcısı alt kısım şeritleri için PA2 yazıcısı üst şeritler için kullanılır.
5. EDD/TID ÇAĞRI İŞARETİ DAĞITIMI - EDD/TID CALLSIGN DISTRIBUTION
5.1 Şu anda, bir on-route CRS için dört çağrı işareti olayı vardır, yani P1, P2, C1, E.
P1 ve P2 olayları yok edilecek. C1 ve E olayları tutulacak ve olay işlenmesi – event processing seviye bölünüşü şartlarını sağlamak için değiştirilecek. C1 olayı her on-route CRS için vardır. CRS durumu hangi mantıksal pozisyonların-logical positions çağrı işaretini alacağını belirler.
Yani,
CRS üst - mantıksal P1
CRS alt - mantıksal C1
CRS geçiş - mantıksal P1 + mantıksal C1
E olayı her IRS -intermediate route sequence için vardır. On-route uçuşları için, bir EC tipi için yol kısımlarını-route segments tanımlama yeteneği iptal edildiği için IRS bir CRS ile aynı kapsama sahip olacaktır. IRS’in ebeveyn CRS’i kullanılarak hangi mantıksal konumların çağrı işaretini alacağı belirlenir.
Yani;
CRS üst - mantıksal E1
CRS alt - mantıksal E2
CRS geçiş - mantıksal E1 + mantıksal E2
Çağrı işaretini alacak gerçek konum OPM ile belirlenir yani üst kısım için mantıksal P1, E1
ve alt kısım için mantıksal C1, E2.
OPM tarafından kullanılan konumlar için yerine geçiş düzeni şöyledir:
P1 - P1, E1, C1, E2 (üst konu sektör)
C1 - C1, E2, P1, E1 (alt konu sektör)
E1 - E1, E2 (üst konu sektör)
E2 - E2, E1 (alt konu sektör)
5.2 Seviye bölünmesi kavramından önce, her uçuş kısmı yalnızca bir yetkili kontrolör (EC-executive controller)’e verildiği için belirli bir LRS için geçerli EC sıralamasına katı kurallar uygulanırdı. Bu felsefe CRS geçişlerinin olduğu durumlarda artık geçerli değildir. Artık sistemin belirli bir CRS için iki EC’yi devreye sokması gerekmektedir. Sistemin, bir CRS geçişi için seçilecek ilk EC’yi CRS giriş seviyesinden bulması gerekmektedir. Bir çok durumda ikinci EC’nin bulunması için çıkış seviyesi kullanılabilir fakat ilk EC’nin aynı zamanda üçüncü EC olduğu durumlar da vardır.
It is suggested that the system should set the first EC according to the NFL and allow automatic assume to function for this first EC. No automatic assume would be made to the second ( or third ) EC. Here the "hybrid rule" could apply ie. if no manual assume is made then the flight would be automatically assumed in the next geographical sector.
If the second EC makes a manual assume then data is cleared down from the first EC and coupled coordinator .
Wednesday, April 25, 2007
DESENLER (I)
Küçükken yolları boyu arabacılık oynadığımız Isparta halıları… Banyomuzun önündeki holde duran Anadolu kilimi… Perdeler, perdeler, perdeler…
Evimizin tavanlarını süsleyen kontrpiyeler… Mutfak ve hollerimizdeki taşları süsleyen çiniler… Küçüklüğümdeki yemek masamızın yollu kenarları… Süslü çay bardaklarımız, büyüklerin kahve bardakları… Canım yemek istemediği zaman kenarındaki pamuk prenses ve yedi cüceler desenlerini seyrettiğim tabak takımlarımız… Büyülü gibi duran annemin desenli elbiseleri, pamuklu etekleri… Desenler, desenler, desenler…
-
Okul günleri her sabah aynı saatte babamın ‘Haydi çocuklar kalkın’ diyen gürleştirilmiş sesi… İlk okulda her gün saat 10’da öcü gibi çekindiğim süt saati… Dersler, dersler, dersler…
Akşam yemekleri… Hep aynı saatte ve askeri disiplinle rapor etmemiz gereken akşam yemekleri…
Aile ziyaretleri, belirli aralarla ama hep aynı ara ile tekrarlanmayan ziyaretler…
-
Orta okulda Kadıköye gidiş gelişler, hep aynı saatte kalkan otbüsleri bir sonraki durakta yakalamak için yaptığımız yol boyunca koşular…
Yaz tatilleri… Ağabeyim ile değiş tokuş gün aşırı Beykoz’da babamın yanında arı kovanları üstünde çalışmak…
Bayramlar! Bayramlar! Bayramlar! Anneannemin dolmaları, börekleri… Bayramların tekrarlanan sevgi ve sıcaklığı…
Günler, haftalar, aylar, … Mevsimler, mevsimler, mevsimler…
Istanbul sonbaharının güzelliği! Mayıs meltemi! Mavi gözlü küçük bir kızın ona her bakışımda tekrarlanan gülümseyişi…
Hayatımızda belirli aralarla düzenli düzensiz tekrarlanan şeyler… Tekrar, tekrar, tekrar…
Günler, haftalar, aylar, mevsimler, yıllar, hayatlar… Zaman desenleri…
Kimi zaman farkında olduğumuz kimi zaman olmadığımız, belki yalnız hissettiğimiz… Tıpkı mevsimler gibi, nedenini bilsek bile, işleyişine tümüyle, gözümüzle görüp hakim olamadığımız; modeller, çizimlerle kafamızda canlandırabildiğimiz, gizemli güçlerin şekillendirdiği desenler, desnler, desenler…
-
Uyan, kalk, tuvalete git, ağırlığını ölç, jimnastik yap, banyo yap, giyin, kahvaltını yap… Bunların hepsinin kendine özgü ayrıntıları var, banyo yaparken şampuanı hep aynı yere koy, diş fıçasının yeri hep aynı vb…
Hep tekrar eden davranış desenleri…
-
‘Ben size söyliyeyim…’ “Estağfurullah…’ ‘Ben olsam…’ ‘Ben size öğreteyim…’ ‘Oldu mu ya!’
Anlamını unutacak ölçü de sık sık tekrarladığımız söz kalıpları! Söz desenleri…
-
Oturma odası, Pazar yeri, elma, saygı, aşk, düğün… Tekrarlanan zihinsel yapı desenleri…
-
Ateş olsa değdiği yer kadar yakar. Ak akça kara gün içindir. Bugünün işini yarına bırakma!
Atasözleri… Tekrar tekrar kullanılan, tekrar edilen kavramlar… Kavram desenleri…
-
‘O bana bunu yaptı ben de ona şöyle yaparım, görür gününü…’ ‘Acaba benim hakkımda ne düşünüyorlar?’ ‘Bu iş bu kadar yapılır…’ ‘Bütün köpekler tehlikelidir.’
Tekrarlanan algılama yorumlama biçimleri… DÜŞÜNÜŞ DESENLERİ…
-
Paranoya. Şizofreni. Zihinsel rahatsızlıklar…
Rahatsızlıkları ortak özellikler taşıyan insanların DÜŞÜNÜŞ DESENLERİ…
-
Bir gün işe başka yoldan git! İşten çıktığında doğrudan eve dönme hiç gitmediğin bir yere git! Bir sabah kalktığında her şeye farklı gözle bak! Evindeki her şeyi ilk defa görüyormuş gibi algıla… Güzel bir kitap bul, yeni şeyler öğren! Dünyaya balışın değişsin. Hep aynı şeyleri takrarlasan bile bakış noktanı değiştir. Hiçbir şeye sonuna kadar bağlanma… Her şey değişiyor. Kafandaki desenlerin (schema, script, frame) de değişmesi doğal…
En büyük çabayı en sık tekrarladığın deseni ilk günkü gibi taze tutmak için harcamalısın.
Farklı diller, kültürler, dinler öğren.
Sağlığına uygunsa seyahat et.
Ali Riza SARAL
Not: Sayın editörüm birkaç yazım hatası var, lütfen öyle kalsın! Her ne hikmetse az biraz hata yaptıkça rahatlıyorum... Hem de metacognition oluyo… Zaten bu yazıyı gelecek hafta yeniden başka türlü yazacağım.
Evimizin tavanlarını süsleyen kontrpiyeler… Mutfak ve hollerimizdeki taşları süsleyen çiniler… Küçüklüğümdeki yemek masamızın yollu kenarları… Süslü çay bardaklarımız, büyüklerin kahve bardakları… Canım yemek istemediği zaman kenarındaki pamuk prenses ve yedi cüceler desenlerini seyrettiğim tabak takımlarımız… Büyülü gibi duran annemin desenli elbiseleri, pamuklu etekleri… Desenler, desenler, desenler…
-
Okul günleri her sabah aynı saatte babamın ‘Haydi çocuklar kalkın’ diyen gürleştirilmiş sesi… İlk okulda her gün saat 10’da öcü gibi çekindiğim süt saati… Dersler, dersler, dersler…
Akşam yemekleri… Hep aynı saatte ve askeri disiplinle rapor etmemiz gereken akşam yemekleri…
Aile ziyaretleri, belirli aralarla ama hep aynı ara ile tekrarlanmayan ziyaretler…
-
Orta okulda Kadıköye gidiş gelişler, hep aynı saatte kalkan otbüsleri bir sonraki durakta yakalamak için yaptığımız yol boyunca koşular…
Yaz tatilleri… Ağabeyim ile değiş tokuş gün aşırı Beykoz’da babamın yanında arı kovanları üstünde çalışmak…
Bayramlar! Bayramlar! Bayramlar! Anneannemin dolmaları, börekleri… Bayramların tekrarlanan sevgi ve sıcaklığı…
Günler, haftalar, aylar, … Mevsimler, mevsimler, mevsimler…
Istanbul sonbaharının güzelliği! Mayıs meltemi! Mavi gözlü küçük bir kızın ona her bakışımda tekrarlanan gülümseyişi…
Hayatımızda belirli aralarla düzenli düzensiz tekrarlanan şeyler… Tekrar, tekrar, tekrar…
Günler, haftalar, aylar, mevsimler, yıllar, hayatlar… Zaman desenleri…
Kimi zaman farkında olduğumuz kimi zaman olmadığımız, belki yalnız hissettiğimiz… Tıpkı mevsimler gibi, nedenini bilsek bile, işleyişine tümüyle, gözümüzle görüp hakim olamadığımız; modeller, çizimlerle kafamızda canlandırabildiğimiz, gizemli güçlerin şekillendirdiği desenler, desnler, desenler…
-
Uyan, kalk, tuvalete git, ağırlığını ölç, jimnastik yap, banyo yap, giyin, kahvaltını yap… Bunların hepsinin kendine özgü ayrıntıları var, banyo yaparken şampuanı hep aynı yere koy, diş fıçasının yeri hep aynı vb…
Hep tekrar eden davranış desenleri…
-
‘Ben size söyliyeyim…’ “Estağfurullah…’ ‘Ben olsam…’ ‘Ben size öğreteyim…’ ‘Oldu mu ya!’
Anlamını unutacak ölçü de sık sık tekrarladığımız söz kalıpları! Söz desenleri…
-
Oturma odası, Pazar yeri, elma, saygı, aşk, düğün… Tekrarlanan zihinsel yapı desenleri…
-
Ateş olsa değdiği yer kadar yakar. Ak akça kara gün içindir. Bugünün işini yarına bırakma!
Atasözleri… Tekrar tekrar kullanılan, tekrar edilen kavramlar… Kavram desenleri…
-
‘O bana bunu yaptı ben de ona şöyle yaparım, görür gününü…’ ‘Acaba benim hakkımda ne düşünüyorlar?’ ‘Bu iş bu kadar yapılır…’ ‘Bütün köpekler tehlikelidir.’
Tekrarlanan algılama yorumlama biçimleri… DÜŞÜNÜŞ DESENLERİ…
-
Paranoya. Şizofreni. Zihinsel rahatsızlıklar…
Rahatsızlıkları ortak özellikler taşıyan insanların DÜŞÜNÜŞ DESENLERİ…
-
Bir gün işe başka yoldan git! İşten çıktığında doğrudan eve dönme hiç gitmediğin bir yere git! Bir sabah kalktığında her şeye farklı gözle bak! Evindeki her şeyi ilk defa görüyormuş gibi algıla… Güzel bir kitap bul, yeni şeyler öğren! Dünyaya balışın değişsin. Hep aynı şeyleri takrarlasan bile bakış noktanı değiştir. Hiçbir şeye sonuna kadar bağlanma… Her şey değişiyor. Kafandaki desenlerin (schema, script, frame) de değişmesi doğal…
En büyük çabayı en sık tekrarladığın deseni ilk günkü gibi taze tutmak için harcamalısın.
Farklı diller, kültürler, dinler öğren.
Sağlığına uygunsa seyahat et.
Ali Riza SARAL
Not: Sayın editörüm birkaç yazım hatası var, lütfen öyle kalsın! Her ne hikmetse az biraz hata yaptıkça rahatlıyorum... Hem de metacognition oluyo… Zaten bu yazıyı gelecek hafta yeniden başka türlü yazacağım.
SAFETY CULTURE - EMİNLİK KÜLTÜRÜ
Eminlik-Safety: Herhangi bir kazaya yol açmak ya da uğramak olasılığından uzak olmak.
Güvenlik-Security: Dışarıdan gelecek tehlikeden bağımsız olmak durumu.
Eminlik bir sistem çalışırken bu sistemin onu kullananlara ve kendine zarar vermemesidir. Bir sistemin emin oluşu için gerekli adımlar onun yapım şartnamesinin yazılması ile başlar. Sistemin eminliğini sağlamak onun hizmet ömrünün sonuna kadar ona özgü bir güvenlik politikasının tüm ilgililerce uygulanmasını ve bu durumun yetkili bir güvenlik grubu tarafından denetlenişini gerektirir.
Eminlik politikasının belirlenebilmesi için, EUROCONTROL’ün 2011 Gelecek Hava Güvenlik Grubu’nun yaptığı gibi bir ‘güvenlik yol haritası’ çıkartmak gereklidir. Bu yol haritası sistemden beklenen hizmetteki hızlı değişimleri göğüslemek için gerekli yeni işletimsel kavramların nasıl geliştirileceğini belirlemelidir. “Bu yeni kavramlar yapısal güvenliğe sahip midirler? Yeni kavramlar gerçekten onlardan beklenen güvenlik artışını sağlayacaklar mıdır? Kavram değişiklikleri güvenlik ile ilgili işlemleri nasıl etkileyecekler?
Yeni geliştirilen SESAR İşletimsel Kavramı 2020’deki güvenlik hadeflerini sağlayacak mıdır?”
‘Eminlik yol haritası’ söz konusu büyük sistemlerin bugünkü icra seviyesini, gelecekte ondan beklenen seviyeleri, bu hedeflere ulaşmak için gerekli ana planı, bu ana planın içerdiği önemli kavram tartışmalarını, yeni sistemi geliştirecek üreticilerin teknik ve diğer sorularını ve yeni yol haritasından varsayımsal sağduyu çıkarımlarını içermelidir.
Eminlik hedefleri kaza sayısının indirilmesi ve işletimsel hacmin aynı eminlik seviyesi korunarak arttırılmasıdır. Bu hedeflere ulaşmak için Tepkisel(Reactive) ya da Öncül(Proactive) eylemler yapabiliriz. Tepkisel yöntem geçmişte olmuş kazaların tekrar edilmemesine yönelik, Öncül yöntemler ise hiç olmamış yeni kaza türlerine karşı önlem almaktır. Öncül yöntemler için SESAR, ACARE gibi stratejik araştırma çalışmaları örgütlemek gerekir. Eminlik eylemleri Düzenleme, Gözetim, Güvenlik Yönetim Sistemleri, Lisanslama ve Eğitim, Eminlik Ekipleri gibi unsurlar içerir. Techneloji geliştirmek ise TCAS, ACAS, turbulence/windshear detection dahil olmak üzere EGPWS & Weather Radar, güvenli veri bağlantısı ile 4 boyutlu yol pazarlığı, STCA, “Sanal Kule” ve ATM için trafik izlemek gibi teknik unsurları içerir. Eminlik arttırılması ileri tekneloji, risk azaltmak ve yok etmek, pazarın değişimi ve eminliğin kültürel yönleri, eminlik yönetimi ve tümleşik risk yönetimi konularını içerir.
Bir ‘Eminlik yol haritası’ ‘nı izleyerek ‘eminlik hedefleri’ ‘ne ulaşabilmek için EUROCONTROL’ün FAST-Future Air Safety Group ya da İngiliz UK Safety Regulation Group gibi Eminlik amaçlı ekipler oluşturmak gerekir. Eminlik Grubunun düzenlemesi ile öncelikle durum tespiti amacına yönelik tarayış çalışmaları yapılır. Bunlar daha çok Eminlik konusunda kuruluş içinde var olan anlayışları ve genel kültürü tespit etmeği hedefler…
Örneğin, EUROCONTROL ve Boeing çalışanlarının işbirliği ile yapılan bir anket çalışmasında planlama, eminlik örgütlenmesi, düzenleme ve standartlar, eminlik değerlendirmesi, eminlik taramaları, eğitim ve yeterlilik, altyapı ve harici hizmetler, eminlik belgeleri, işletim ve iş kontrolü, eminlik olay raporları, ödüllendiriş ve teşvikler konuları ele alınmıştır. Yine bu taramada:
Eminlik için sorumluluk;
- Düzenleyici etkinliği, gerçek iş uygulamaları, kuruluş içinde güven, sistem/prosedür değişikliklerinde iletişim, suçlayış & hata toleransı, olaylardan öğreniş
ATCO’ları eminlik için nasıl seferber ediyoruz?
- Eminlik için sorumluluk
- Eminlik için ayrılan kaynaklar
- Olayları rapor etme/sorunları iletmeyi nasıl öğreniyoruz?
- Eminlik için takım oluşturuş
- Yönetimin eminlik için seferber edilişi
Eminliği arttırmak amaçlı çalışmalar SESAR- Single European Sky ATM research ya da ACARE - Advisory Council for Aeronautics Research in Europe gibi program ve örgütlenmeleri zorunlu kılar.
İngiliz CAA-Civil Aviation Authority’nin Eminlik Planı şu amaçları gerçekleştirmeyi hedefler:
- Eminlik amaçlarını gerçekleştirmeye yardımcı olmak.
- Değişen düzenleyici ortamı yönetmek.
- Beş yılı kaplar.
- Belirlenebilir riskleri ve eminlik çalışmalarını kayıt eder.
Bu eminlik planı
- Eminlik Düzenleyici Grubun başlama noktası olan kaza analizleri
- Kontrol kaybı
- CFIT (Controlled Flight Into Terrain)
- Yangın
- Pilot icra seviyesi
- Havada çarpışma
- Kazaya dayanmayan fakat potansiyel olası kazaları‘nı dikkate alır.
Eminliği yönetilebilmek, arttırılabilmek için onu hiç değilse kısmen ölçebilmek gerekir. Aksi takdirde yeni geliştirilen eminlik arttırıcı önlemlerin işe yarayıp yaramayışını ya da kapasite arttırıcı değişikliklerin kaza riskini nasıl etkilediğini doğru değerlendiremeyiz. IATA veriye dayanan değerlendirişi savunan tutumu ile belirlediği altı maddelik eminlik programında
- Eminlik sınayışı
- Altyapı eminliği
- Eminlik Veri Yönetimi ve İncelenişi
- Uçuş işletimi
- Eminlik Yönetim Sistemleri
- Yük Eminliği‘ne yer vermiştir.
IATA güvenlik veri yönetimi ve analizi konusunda:
- Kazalar: Yıllık IATA Eminlik Raporu
-Öğrenilen derslerin gelecek eminlik teşebbüslerine yedirilmesi
- Hadiseler: STEADES
- Mevsimlik raporların önde gelen hadiselerin altını çizişi
-Kaygı uyandıran belirli alanların duruma göre analizi
- Normal işletim: FDA hizmeti
- Gün be gün işletimsel standartlara açılan pencere
- Belirli olayların analizi ve eğitim amacı ile yeniden canlandırılışı çalışmalarını yapmaktadır.
Veri akışını kolaylaştırmak için
- Regulatory provisions
- EC Directives 94/56 and 2003/42
- ICAO Annex 13
- JAR OPS
- EU Regulation 1592/2002
- ‘Hak kültürü’-‘Just Culture’ yaklaşımının Hadise raporlarına uygulanması
- Daha çok veri
- Öntetikleyicilerin daha iyi belirlenişi
- Azaltıcı önlemlerin geliştirilmesine odaklı yaklaşım
Sistem eminliğini sağlamak için toplanmış olan hadise verilerinin doğru değerlendirilmesi gerekir – Eminlik Değerlendirmesi-Safety Assessment. EUROCONTROL’den Dr. Straeter “şartlara uyum sağlayamayan – non-resilient eminlik değerlendiriş yaklaşımları uygulanmasının sistem icra seviyesinin hastalıklı tanımlanışına yol açacağına” dikkat çekmiştir.
- Eminliğin kapsadığı alan ve yöntemler sistemin geleceğe yönelik tasarımını önceden belirler.
- Eminlik değerlendirme yöntemlerinin eksiklikleri gelecekteki sistemin eminlik icra seviyesinin de eksikliklerini belirler.
- Sayısal eminlik değerlendiriş ve insana dayanılabilirlik değerlendirişini özellikle şartlara uyum sağlayış prensiplerine göre yapmak gerekir.
Eminlik Kültürü deyimi ilk olarak Çernobil kazasından sonra Uluslararası Eminlik Kültürü Tavsiye Grubu tarafından kullanılmıştır. Öte yandan, benzer kaza nedenleri daha önceden de gözlenmiş ve belirlenmiştir. Nitekim Üç mil adası kazası kuruluş içindeki etkin örgütlenemeyişten kaynaklanan art nedenlerin sonucudur. Son zamanlarda da uzay mekiği Kolombiya kazası için ‘iflas etmiş Eminlik Kültürü’ ifadesi kullanılmıştır.
Feleketlere neden olan kuruluşsal etkenler:
- Boydan boya geliştirilmiş eminlik sistemlerine karşın, karışık sistemler – complex systems insanlar üstlerine düşeni yapmadığı için çökmektedirler.
- Bunlar tek tek ve basit olaylar değil sistemi çalışır durumda tutan çürümüş bir sosyal sistemin yanlış uygulamalarıydılar.
- Zayıf iletişim önemli bir etkendi.
- “İnsan hatasını” suçlu göstermek ve bu rasgele seyrek zayıflıkların tamir edilmesi için bir büyülü tedavi beklemek sorunları çözemez.
Malcolm FERNBY EUROCONTROL Safety R&D Seminar’da yaptığı ‘Safety Culture Activities in NATS’ adlı sunuşunda İngiliz Hava Trafik Kontrolü Kuruluşunda Safety Culture Maturity Model – Eminlik Kültürü Olgunluk Modeli’nin nasıl uygulamaya konulduğunu anlatıyor. Çok faydalı bir çalışma. Internet’te bulmak mümkün…
Söz konusu seminerin sunumları arasında ‘Swed Lund Impact of change processes on safety culture and organizational climate’, ‘Operational Readiness in Transition’, ‘ATM Safety Maturity Model Boeing Safety Culture Survey’, ‘Swed safety management system’, ‘UK Safety Regulation Group’, ‘NLR Identification of emergent hazards and behaviour’, ‘The Functional Resonance Accident Model’ konularında da ilgi çekici sunumlar var.
FAA, NATS, NLR, gibi Amerikan ve İngiliz kuruluşları yanında hem sayı hem de içerik olarak İsveç sunumlarının başarısı daha önde… Bu durum daha önce eminlik konusunda yaptığım çalışmalar sırasında acil duruma müdahele, baskı altında karar vermek gibi konularda İsveç itfaiyecilerinin yazdıkları makalelerin hem sayı hem de kalite olarak yüksekliğini hatırlattı bana… Maalesef bu makalelerin büyük kısmı fazla pahalı olmasa da ücretli…
Emin bir hava ulaşım sistemi kurabilmek için bir yerde birilerinin eminlik konusunda araştırma yapması en azından var olan makaleleri okuyup havacılık camiasına nakletmesi gerekiyor. Bu işin gerektirdiği ciddiyet ve güçle yapılabilmesi için üniversiteler ya da TUBİTAK bir kapı açmalı ilgililere…
Saygılarımla.
Ali Rıza SARAL
Güvenlik-Security: Dışarıdan gelecek tehlikeden bağımsız olmak durumu.
Eminlik bir sistem çalışırken bu sistemin onu kullananlara ve kendine zarar vermemesidir. Bir sistemin emin oluşu için gerekli adımlar onun yapım şartnamesinin yazılması ile başlar. Sistemin eminliğini sağlamak onun hizmet ömrünün sonuna kadar ona özgü bir güvenlik politikasının tüm ilgililerce uygulanmasını ve bu durumun yetkili bir güvenlik grubu tarafından denetlenişini gerektirir.
Eminlik politikasının belirlenebilmesi için, EUROCONTROL’ün 2011 Gelecek Hava Güvenlik Grubu’nun yaptığı gibi bir ‘güvenlik yol haritası’ çıkartmak gereklidir. Bu yol haritası sistemden beklenen hizmetteki hızlı değişimleri göğüslemek için gerekli yeni işletimsel kavramların nasıl geliştirileceğini belirlemelidir. “Bu yeni kavramlar yapısal güvenliğe sahip midirler? Yeni kavramlar gerçekten onlardan beklenen güvenlik artışını sağlayacaklar mıdır? Kavram değişiklikleri güvenlik ile ilgili işlemleri nasıl etkileyecekler?
Yeni geliştirilen SESAR İşletimsel Kavramı 2020’deki güvenlik hadeflerini sağlayacak mıdır?”
‘Eminlik yol haritası’ söz konusu büyük sistemlerin bugünkü icra seviyesini, gelecekte ondan beklenen seviyeleri, bu hedeflere ulaşmak için gerekli ana planı, bu ana planın içerdiği önemli kavram tartışmalarını, yeni sistemi geliştirecek üreticilerin teknik ve diğer sorularını ve yeni yol haritasından varsayımsal sağduyu çıkarımlarını içermelidir.
Eminlik hedefleri kaza sayısının indirilmesi ve işletimsel hacmin aynı eminlik seviyesi korunarak arttırılmasıdır. Bu hedeflere ulaşmak için Tepkisel(Reactive) ya da Öncül(Proactive) eylemler yapabiliriz. Tepkisel yöntem geçmişte olmuş kazaların tekrar edilmemesine yönelik, Öncül yöntemler ise hiç olmamış yeni kaza türlerine karşı önlem almaktır. Öncül yöntemler için SESAR, ACARE gibi stratejik araştırma çalışmaları örgütlemek gerekir. Eminlik eylemleri Düzenleme, Gözetim, Güvenlik Yönetim Sistemleri, Lisanslama ve Eğitim, Eminlik Ekipleri gibi unsurlar içerir. Techneloji geliştirmek ise TCAS, ACAS, turbulence/windshear detection dahil olmak üzere EGPWS & Weather Radar, güvenli veri bağlantısı ile 4 boyutlu yol pazarlığı, STCA, “Sanal Kule” ve ATM için trafik izlemek gibi teknik unsurları içerir. Eminlik arttırılması ileri tekneloji, risk azaltmak ve yok etmek, pazarın değişimi ve eminliğin kültürel yönleri, eminlik yönetimi ve tümleşik risk yönetimi konularını içerir.
Bir ‘Eminlik yol haritası’ ‘nı izleyerek ‘eminlik hedefleri’ ‘ne ulaşabilmek için EUROCONTROL’ün FAST-Future Air Safety Group ya da İngiliz UK Safety Regulation Group gibi Eminlik amaçlı ekipler oluşturmak gerekir. Eminlik Grubunun düzenlemesi ile öncelikle durum tespiti amacına yönelik tarayış çalışmaları yapılır. Bunlar daha çok Eminlik konusunda kuruluş içinde var olan anlayışları ve genel kültürü tespit etmeği hedefler…
Örneğin, EUROCONTROL ve Boeing çalışanlarının işbirliği ile yapılan bir anket çalışmasında planlama, eminlik örgütlenmesi, düzenleme ve standartlar, eminlik değerlendirmesi, eminlik taramaları, eğitim ve yeterlilik, altyapı ve harici hizmetler, eminlik belgeleri, işletim ve iş kontrolü, eminlik olay raporları, ödüllendiriş ve teşvikler konuları ele alınmıştır. Yine bu taramada:
Eminlik için sorumluluk;
- Düzenleyici etkinliği, gerçek iş uygulamaları, kuruluş içinde güven, sistem/prosedür değişikliklerinde iletişim, suçlayış & hata toleransı, olaylardan öğreniş
ATCO’ları eminlik için nasıl seferber ediyoruz?
- Eminlik için sorumluluk
- Eminlik için ayrılan kaynaklar
- Olayları rapor etme/sorunları iletmeyi nasıl öğreniyoruz?
- Eminlik için takım oluşturuş
- Yönetimin eminlik için seferber edilişi
Eminliği arttırmak amaçlı çalışmalar SESAR- Single European Sky ATM research ya da ACARE - Advisory Council for Aeronautics Research in Europe gibi program ve örgütlenmeleri zorunlu kılar.
İngiliz CAA-Civil Aviation Authority’nin Eminlik Planı şu amaçları gerçekleştirmeyi hedefler:
- Eminlik amaçlarını gerçekleştirmeye yardımcı olmak.
- Değişen düzenleyici ortamı yönetmek.
- Beş yılı kaplar.
- Belirlenebilir riskleri ve eminlik çalışmalarını kayıt eder.
Bu eminlik planı
- Eminlik Düzenleyici Grubun başlama noktası olan kaza analizleri
- Kontrol kaybı
- CFIT (Controlled Flight Into Terrain)
- Yangın
- Pilot icra seviyesi
- Havada çarpışma
- Kazaya dayanmayan fakat potansiyel olası kazaları‘nı dikkate alır.
Eminliği yönetilebilmek, arttırılabilmek için onu hiç değilse kısmen ölçebilmek gerekir. Aksi takdirde yeni geliştirilen eminlik arttırıcı önlemlerin işe yarayıp yaramayışını ya da kapasite arttırıcı değişikliklerin kaza riskini nasıl etkilediğini doğru değerlendiremeyiz. IATA veriye dayanan değerlendirişi savunan tutumu ile belirlediği altı maddelik eminlik programında
- Eminlik sınayışı
- Altyapı eminliği
- Eminlik Veri Yönetimi ve İncelenişi
- Uçuş işletimi
- Eminlik Yönetim Sistemleri
- Yük Eminliği‘ne yer vermiştir.
IATA güvenlik veri yönetimi ve analizi konusunda:
- Kazalar: Yıllık IATA Eminlik Raporu
-Öğrenilen derslerin gelecek eminlik teşebbüslerine yedirilmesi
- Hadiseler: STEADES
- Mevsimlik raporların önde gelen hadiselerin altını çizişi
-Kaygı uyandıran belirli alanların duruma göre analizi
- Normal işletim: FDA hizmeti
- Gün be gün işletimsel standartlara açılan pencere
- Belirli olayların analizi ve eğitim amacı ile yeniden canlandırılışı çalışmalarını yapmaktadır.
Veri akışını kolaylaştırmak için
- Regulatory provisions
- EC Directives 94/56 and 2003/42
- ICAO Annex 13
- JAR OPS
- EU Regulation 1592/2002
- ‘Hak kültürü’-‘Just Culture’ yaklaşımının Hadise raporlarına uygulanması
- Daha çok veri
- Öntetikleyicilerin daha iyi belirlenişi
- Azaltıcı önlemlerin geliştirilmesine odaklı yaklaşım
Sistem eminliğini sağlamak için toplanmış olan hadise verilerinin doğru değerlendirilmesi gerekir – Eminlik Değerlendirmesi-Safety Assessment. EUROCONTROL’den Dr. Straeter “şartlara uyum sağlayamayan – non-resilient eminlik değerlendiriş yaklaşımları uygulanmasının sistem icra seviyesinin hastalıklı tanımlanışına yol açacağına” dikkat çekmiştir.
- Eminliğin kapsadığı alan ve yöntemler sistemin geleceğe yönelik tasarımını önceden belirler.
- Eminlik değerlendirme yöntemlerinin eksiklikleri gelecekteki sistemin eminlik icra seviyesinin de eksikliklerini belirler.
- Sayısal eminlik değerlendiriş ve insana dayanılabilirlik değerlendirişini özellikle şartlara uyum sağlayış prensiplerine göre yapmak gerekir.
Eminlik Kültürü deyimi ilk olarak Çernobil kazasından sonra Uluslararası Eminlik Kültürü Tavsiye Grubu tarafından kullanılmıştır. Öte yandan, benzer kaza nedenleri daha önceden de gözlenmiş ve belirlenmiştir. Nitekim Üç mil adası kazası kuruluş içindeki etkin örgütlenemeyişten kaynaklanan art nedenlerin sonucudur. Son zamanlarda da uzay mekiği Kolombiya kazası için ‘iflas etmiş Eminlik Kültürü’ ifadesi kullanılmıştır.
Feleketlere neden olan kuruluşsal etkenler:
- Boydan boya geliştirilmiş eminlik sistemlerine karşın, karışık sistemler – complex systems insanlar üstlerine düşeni yapmadığı için çökmektedirler.
- Bunlar tek tek ve basit olaylar değil sistemi çalışır durumda tutan çürümüş bir sosyal sistemin yanlış uygulamalarıydılar.
- Zayıf iletişim önemli bir etkendi.
- “İnsan hatasını” suçlu göstermek ve bu rasgele seyrek zayıflıkların tamir edilmesi için bir büyülü tedavi beklemek sorunları çözemez.
Malcolm FERNBY EUROCONTROL Safety R&D Seminar’da yaptığı ‘Safety Culture Activities in NATS’ adlı sunuşunda İngiliz Hava Trafik Kontrolü Kuruluşunda Safety Culture Maturity Model – Eminlik Kültürü Olgunluk Modeli’nin nasıl uygulamaya konulduğunu anlatıyor. Çok faydalı bir çalışma. Internet’te bulmak mümkün…
Söz konusu seminerin sunumları arasında ‘Swed Lund Impact of change processes on safety culture and organizational climate’, ‘Operational Readiness in Transition’, ‘ATM Safety Maturity Model Boeing Safety Culture Survey’, ‘Swed safety management system’, ‘UK Safety Regulation Group’, ‘NLR Identification of emergent hazards and behaviour’, ‘The Functional Resonance Accident Model’ konularında da ilgi çekici sunumlar var.
FAA, NATS, NLR, gibi Amerikan ve İngiliz kuruluşları yanında hem sayı hem de içerik olarak İsveç sunumlarının başarısı daha önde… Bu durum daha önce eminlik konusunda yaptığım çalışmalar sırasında acil duruma müdahele, baskı altında karar vermek gibi konularda İsveç itfaiyecilerinin yazdıkları makalelerin hem sayı hem de kalite olarak yüksekliğini hatırlattı bana… Maalesef bu makalelerin büyük kısmı fazla pahalı olmasa da ücretli…
Emin bir hava ulaşım sistemi kurabilmek için bir yerde birilerinin eminlik konusunda araştırma yapması en azından var olan makaleleri okuyup havacılık camiasına nakletmesi gerekiyor. Bu işin gerektirdiği ciddiyet ve güçle yapılabilmesi için üniversiteler ya da TUBİTAK bir kapı açmalı ilgililere…
Saygılarımla.
Ali Rıza SARAL
Tuesday, April 10, 2007
A Few Notes on the EUROCONTROL Safety R&D Seminar
A Few Notes on the EUROCONTROL Safety R&D Seminar
by Ali Riza SARAL
Barcelona, Spain
25-27 October 2006
EUROCONTROL held a Safety R & D Seminar at Barselona late October 2006. This seminar took place in a decade that is marked not only by change in ATC technologies but also a continued trend of increase in air traffic. It must be noted that the increase in the air traffic is dramatic. For example the air traffic has risen from approx. 2000 flights per day to 4000 flights per day at KARLDAP central Germany and Europe. This is not a fast and natural load increase in a brand new system. The KARLDAP system is at the edge of a big transition to a brand new one and the technical staff is almost getting retired as a whole…
Big investments are being made for new systems… Yet Europe has seen her worst air traffic accident at Switzerland in this decade… Managers need to have objective methods and tools to justify new costs… The aviation industry is faced with increasing pressure to minimize its costs… Rationalisation sometimes causes experienced ATCOs to work two shifts 8 hours per day as DSF did in late 1990s…
These tendencies are reflected in the Swedish presentation on the “Impact of change processes on safety culture and organizational climate” and “Swed Lund Operational Readiness in Transition” and a not so good other presentation about the Switzerland accident “Human reaction to safety nets”…
I have witnessed the German KARLDAP and Turkish systems and I have not been able to find a comprehensive definition of SAFETY in these places… People are working with rule of thumbs and mutually FELT and SHARED feelings of safety but not objective understandings of it… The traffic load is increasing substantially but no one can judge what is exactly safe and what is not – accept to a certain degree simulation guys… IATA comes into the arena with the “IATAData driven approach to ATM Safety” presentation in the EUROCONTROL seminar.
In order to measure whether a system is safe or not, one must first identify which risks associated with which hazards to measure… Here comes a group of presentations, first two by NLR “NLR Identification of emergent hazards and behaviour” and “NLR Identification of emergent hazards and behaviour”, and a special case “The Functional Resonance Accident Model” and last one from FAA “Human Error Safety Risk Analysis FAA Human Factors Research Group”…
Part of the problem arises from not having the data at all “Confidential Reporting”… Reporting methods, organization and environment are important according to EUROCONTROL presentation which indicates a method and independent Safety Group organisation. “Eliciting Info for Safety Assessment” is a similar presentation…
Once the data is gathered we have to assess it according to a method in order to evaluate the safety of our system… NLR steps in once more with the “NLR Need_for_novel_approach_to_aviation_safety_validation” article along with “resilience in safety assessment”.
Safety culture is the key phrase that is most emphasized in the seminar presentations… “ATM Safety Maturity Model”, “Boeing Safety Culture Survey”, Swedish “safety management system”, “UK Safety Regulation Group” presentation are noteworthy. I am impressed by the FAA, UK and NLR presentations but the Swedish quality and amount of work at most…
by Ali Riza SARAL
Barcelona, Spain
25-27 October 2006
EUROCONTROL held a Safety R & D Seminar at Barselona late October 2006. This seminar took place in a decade that is marked not only by change in ATC technologies but also a continued trend of increase in air traffic. It must be noted that the increase in the air traffic is dramatic. For example the air traffic has risen from approx. 2000 flights per day to 4000 flights per day at KARLDAP central Germany and Europe. This is not a fast and natural load increase in a brand new system. The KARLDAP system is at the edge of a big transition to a brand new one and the technical staff is almost getting retired as a whole…
Big investments are being made for new systems… Yet Europe has seen her worst air traffic accident at Switzerland in this decade… Managers need to have objective methods and tools to justify new costs… The aviation industry is faced with increasing pressure to minimize its costs… Rationalisation sometimes causes experienced ATCOs to work two shifts 8 hours per day as DSF did in late 1990s…
These tendencies are reflected in the Swedish presentation on the “Impact of change processes on safety culture and organizational climate” and “Swed Lund Operational Readiness in Transition” and a not so good other presentation about the Switzerland accident “Human reaction to safety nets”…
I have witnessed the German KARLDAP and Turkish systems and I have not been able to find a comprehensive definition of SAFETY in these places… People are working with rule of thumbs and mutually FELT and SHARED feelings of safety but not objective understandings of it… The traffic load is increasing substantially but no one can judge what is exactly safe and what is not – accept to a certain degree simulation guys… IATA comes into the arena with the “IATAData driven approach to ATM Safety” presentation in the EUROCONTROL seminar.
In order to measure whether a system is safe or not, one must first identify which risks associated with which hazards to measure… Here comes a group of presentations, first two by NLR “NLR Identification of emergent hazards and behaviour” and “NLR Identification of emergent hazards and behaviour”, and a special case “The Functional Resonance Accident Model” and last one from FAA “Human Error Safety Risk Analysis FAA Human Factors Research Group”…
Part of the problem arises from not having the data at all “Confidential Reporting”… Reporting methods, organization and environment are important according to EUROCONTROL presentation which indicates a method and independent Safety Group organisation. “Eliciting Info for Safety Assessment” is a similar presentation…
Once the data is gathered we have to assess it according to a method in order to evaluate the safety of our system… NLR steps in once more with the “NLR Need_for_novel_approach_to_aviation_safety_validation” article along with “resilience in safety assessment”.
Safety culture is the key phrase that is most emphasized in the seminar presentations… “ATM Safety Maturity Model”, “Boeing Safety Culture Survey”, Swedish “safety management system”, “UK Safety Regulation Group” presentation are noteworthy. I am impressed by the FAA, UK and NLR presentations but the Swedish quality and amount of work at most…
Monday, March 19, 2007
TAŞ TAŞ ÜSTÜNE
Resim 1
TAŞ TAŞ ÜSTÜNE
“… ve daha sonra acımasız bir kasaplık başladı. Kıyımda iddialı olanlar Makedonyalılar değil, gururlu yedi kapılı şehirden bir çok neslinin hataları ve hakaretlerinin intikamını alan Thebes’in eski düşmanları Phocia’lılar, Plataea’lılar ve diğer Boeotia halklarıydılar. İskender kıyımı durduruncaya kadar altı bin hayat kayboldu. Sonraki gün, isyankar şehrin kaderini belirlemek için Corinth konfedere’lerini topladı. Hakimler Thebes’e Thebes’in bir zamanlar Atina’ya ölçüp biçtiği cezayı biçti. Ceza ŞEHRİN YERLE BİR EDİLMESİ ve …” (Yunanistan’ın Tarihi J. B. BURY et all, s. 449)
Ünlü yazarımız Halikarnas Balikçısının yazılarında sık sık kaynak gösterdiği J.B. BURY, ‘A History of Greece to the Death of Alexandre Great’ adlı kitabinda sik sik eski Yunan, Makedonyalı ve Persli kavimlerin yakıp yıktığı, erkekleri katledilip kadınları muzaffer askerlere dağıtılan ve yerle bir edilen, TAŞ TAŞ ÜSTÜNE BIRAKILMAYAN mahlup şehirleri anlatır... Bu kitap yalnız Anadolu kültürünün güzelliklerini değil, onun her yönünü anlatır. Örneğin gökten üstümüze kuş pislemesinin uğur sayılması ile ilgili İskender’in bir hikayesi bile vardır bu kitapta… J.B. Bury’nin Heredot tarihi gibi çok sayıda elle tutulur tarih ve belgeye dayanan bu değerli kitabı günümüzde bile yaşayan antik Anadolu kültürünü daha iyi anlamamıza güçlü bir yardımcıdır.
Yakın zamanlarda kaybettiğimiz değerli arkeologumuz Ekrem AKURGAL ‘Türkiye’nin Eski Uygarlıkları ve Harabeleri’ adlı kitabının 222. sayfasında Didim’deki tapınağın 6. yy’da, arkaik dönemde yüzyıllık bir süre için çok ünlendiğini yazar. Bu dönemde Branşid ismi verilen bir rahip ailesi tarafından yönetilmişti bu tapınak. Branşid’ler o dönemde sağduyuyu temsil eden kahinlerdi. Nice kral onlara hediyeler gönderip onlardan fikir alıyordu o dönemde.
Didim Kahin Tapınağının ilk inşaatı Milattan önce 8. yüzyılda yapılmıştı(s. 223). Daha sonra MÖ 6. ve 5. yüzyıllarda yeniden inşa edilmiş, 112 sütunluk devasa bir mimari harika olmuştu. Fakat Ion ayaklanmasından sonra Persler Lade savaşını kazanınca Didim ve Mileti yakıp yıktılar. Branşid’leri yasakladılar ve ihanetlerine kıssa olarak İran’da Baktria’ya sürdüler. MÖ 4. yy’ın sonuna doğru İskender bölgeyi kurtarınca yeniden Kahin tapınağını inşa ettirdi. Devasa bir bina tasarladılar. “Bu kadar BÜYÜK BİR BİNA’nın kısa bir zamanda bitirilmesi mümkün değildi. İnşaat MÖ. 3. ve 2. yüzyıllarda devam etti ve bir bölümü ancak Roma döneminde bitirilebildi. Anlaşıldığı kadarı ile güney-batı ve kuzey bölümleri hiçbir zaman bitirilemedi…” (Akurgal, Ancient Civilization and Ruins of Turkey, s. 227).
İsa’dan önce 3. yüzyılda devasa bir bina inşaatına başlıyorsunuz. Bina daha önce, bilgiişlem jargonuyla, çok sayıda sürümleri çıkartılmış, 500 yıllık bir geçmişe, yıkıp yeniden yapma tarihine sahip… Bina defalarca yeniden yapılmış, mimari tasarımı zamanın içinde bir imbikten süzülmüş, damıtılmış. Sonra büyük bir yıkım, Pers yıkımı… Ve İskender’in dahiyane kararı… İskender, yine bilgiişlem jargonu ile, bir BÜYÜK SİSTEM yapmaya karar vermiş… Yapımı belki hiçbir zaman bitmeyecek, nesiller boyu devam edecek büyük bir boy ölçüşme… Günümüzdeki uzay istasyonu ve benzeri uzay çalışmaları gibi…
Resim 2
Didim Branşid Kahin Tapınağı, MÖ. 8 – MS 2. yy
Yaklaşık 1000 yıl süren bir inşa süreci ve tümü bitirilemeden büyük bir depremde yıkılan Didim Branşid’lerinin Kahin Tapınağı… ‘Taş taş üstüne bırakmamak’ ile mücadele eden, gerçekleştirmeye çalıştığı BÜYÜK SİSTEM’in yanında ömrü bile yetersiz kalan insanların, devlet adamlarının, askerlerin, sanatçıların ve taş ustalarının kararlılığı: bir nesilden diğerine emanet edilen bir kararlılık; taş taş üstüne koyma kararlılığı, BAŞKASININ KOYDUĞU TAŞIN ÜSTÜNE BİR TAŞTA BEN KOYAYIM kararlılığı ve alçak gönüllülüğü, hizmet anlayışı.
ABD Savunma Bakanlığı (DoD-Department of Defence)’in STSC – Software Technology Support Center’ının yani Yazılım Destek Merkezi’nin çıkarttığı, internettede kolaylıkla bulunabilen tartışma - CROSSTALK adlı dergide yayınlanmış bir makalenin başlığı “Niye Büyük Yazılım Projeleri Başarısız Oluyor – 12 Anahtar Soru”… SEI – Software Engineering Institute’tan Watts S. HUMPREY tarafından yazılmış bu makale yazılım projesi yönetiminde yapılan ilerlemelere karşın niye yazılım projelerinin rahatsız edici bir şekilde başarısız olduğunu sorguluyor. Bu makale “BÜYÜK-BOYUTLU YAZILIM PROJELERİ’nde kurumunuzun başarısızlıklarına neden olan unsurları inceliyor ve …”
BÜYÜK-BOYUTLU yazılım projeleri… LARGE SYSTEMS… BÜYÜK SİSTEMLER… Hızlı tren projesi… Büyük tüneller… Yeni yapılan hava trafik kontrolü sistemimizin SMART ihalesi…Marmara Ray… Metro projeleri… Yeni elektrik santralları… Nükleer santral… Elektrik dağıtım şebekeleri… Petrol nakil hatları… Uçak yapımı… Helikopter yapımı… Yolcu gemisi, yük gemisi yapımı… Savaş gemisi yapımı… Bunlar Türkiyemizin önündeki başarmamız gereken boy ölçüşmeler… Ve çoğunun içinde kontrol ve kumanda amaçlı büyük yazılım sistemleri var… Bunların üretimi ve bakımı için yurt dışına büyük döviz ödemeleri yapıyoruz.
Bunun bir çok nedeni olabilir. Ama bunların önemli bir tanesi BÜYÜK SİSTEMLER yapmanın basit ve kısa bir süreç sonucu değil, mesleğinin ustası kişilerin, usta çırak ilişkisi içinde, birkaç nesil ve ömür boyu çalışarak oluşturdukları sistemlerin 15- 20 yıl ısrarla kullanılarak geliştirilmesine dayanan bir kültür işi olmasıdır. Sorun TAŞ TAŞ ÜSTÜNE KOYMA kültürünü ve devlet politikasını ve siyasi iradesini oluşturmaktır.
Türkiye’mizin olağanüstü büyük ve zorlu coğrafyası, 100 milyona yaklaşacak nüfusu Türkiye Cumhuriyeti devletini ve bizleri politikadan, sanata, devlet idaresinden teknolojiye, sanayiye kadar BÜYÜK SİSTEMLER kullanmak, geliştirmek ve icad etmek zorunda bırakıyor. Geçmişte bu coğrafyayı kendi renkleri ile boyamayı başarmaya cüret edebilen milletimiz çağımızda Anadolu coğrafyasının önümüze koyup dayattığı her türlü büyük sistemle baş edebilme, her türlü büyük sistemin içinde kendi kişiliği ile var olabilme mücadelesi, boy ölçüşmesi ile karşı karşıya…
Harward Business Review’un Tem – Ağu 1993’te Building A Learning Organization – Öğrenen Bir Kuruluş İnşa Etmek makalesinde :
“Öğrenen bir kuruluş yeni bilgi ve sağduyuyu yaratmada, edinmede ve nakletmede ve kendi davranışını bunu yansıtacak şekilde değiştirmede usta olan kurumdur” der.
Harward Üniversitesinin bu dergisi toplumumuzun her kademesinde faydalı olabilecek, esinlenilebilecek bir kaynak… Ne yazık ki bu dergiyle tanışmamı sağlayan BİMSA’nın sağduyulu kütüphanesi artık bugünkü I-BİMSA içinde bulunmuyor… Öğrenen bir Kurum oluşturmak çok iddialı bir sav… Belki yalnız Microsoft vb. yabancı kuruluşlar için geçerli olabilecek bir şey…
Bilginin kurum içinde birikmesini sağlamak, en azından hedeflenebilecek bir şey… Ülkemizde bir çok kurum ISO9000 belgesi almış durumda, hak ederk ya da etmeyere… Dikkat edilirse ISO9000’in özü, oluşturmak istediği sistemin nüvesi, kurum bilgi ve tecrübesinin sistem içinde, kurum içinde biriktirilebilmesi ve kolayca nakledilebilmesidir…
Bir mühendisin karakteri bilgiye karşı aldığı tavırdan anlaşılır. Bilgiyi hak etmiyene vermemek, bilgiyi yetkin olmayan kişiye vermemek, karşılığını almadan ya da kıymetini bilmeyene bilgiyi vermemek, hakettiği saygıyı göstermeyene bilgiyi vermemek, bilgiyi idareli kullanmak, eldeki bilgileri yenileri gelmeden dağıtmamak, bilgiyi sağladığı güce uygun ve orantılı güçle kullanmak, bilgiyi bilmeyeni ezmek için kullanmak, bilgiyi iş yapmaktan çok biriktirmek amacıyla edinmek, bilgiyi o anki işi hallettiği kadar edinmek, bilgiyi çok basite indirgemek günlük işleri bitirmek için en etkin araç kılmak gibi… Ya da başkasından öğrendiği üzerine kendisinden önce gelenin üslubunu koruyarak küçük bir ekleme yapıp yapanın kimliğini belirlemesi için sistemin öngördüğü ve kendisine ait usta işaretini bir köşeye yerleştiren ve yaptığını çokta önemsemeyen bir usta mühendis gibi… Aslında ne kadar mühendis varsa dünyada ona yakın sayıda bilgiye karşı tavır söz konusudur… Üstelik bu sayı zaman içinde de değişir.
Yazıma antik dönemdeki BÜYÜK SİSTEMLER ile başlamıştım. 20 – 30 metre yüksekliğinde
112 taş sütun küçük bir şey değil bugün için bile… Ama bir şeyin büyüklüğünü belirleyen yalnız büyüklüğünün mutlak değeri değil onun nasıl algılandığıdır… Soyutlama seviyeleri çok 250 bin satırlık bir yazılım bir LARGE SYSTEMS olabilir. Nitekim, ADA ile yazılmış 250 bin satır C++ ile yazılmış 250 bin satırlık bir sistemden daha büyük olabilir… Ya da 5 kişilik bir ekibin yazdığı 800 bin satırlık bir paket 10 kişinin yazdığı 800 bin satırlık bir paketten daha büyük algılanabilir. Önemli olan yazılım paketinin büyüklüğü değil işin yapılması sırasında karşılaşılan güçlüklerden başarı ile çıkılmasıdır. Benzer bir yapı içinde 5 kişi, 10 kişinin karşılaştığı güçlükleri daha yoğun olarak yaşayabilir bazen…
Yazılım projelerinde boy ölçüşülen önemli bir güçlük ISO9000’de yüklenici tarafından yapılması gerektiği vurgulanan, müşteri tarafından belirtilen şartname maddelerinin doğal parçası olan, ‘implied requirements’’ın, yani yapılacak işin tümünün her yönüyle proje başlangıcında görülememesidir. Tıp alanından bir örnek verirsek, ameliyat masasına yatırdığınız canlının ne olduğunu tam olarak bilemiyorsunuz, ve bir amipin hücre duvarını tamir edeyim derken amip bir orangutana dönüşüyor masanın üzerinde, siz ameliyat yaparken…
Uzay istasyonu ya da Didim Branşid Kahini Tapınağı gibi bitmesi hiç mümkün olmayacak BÜYÜK SİSTEM’ler üzerinde çalışmak belki de daha küçük ve sınırlı sistemlerde karşılaştığımız güçlükleri yenmek için gerekli eşsiz tecrübeyi bize kazandırabilir… Nitekim, büyük yazılım sistemlerinde çalışan her usta mühendisin elinin altında bulunan, “Yazılım Ölçümlerinin Geçerliliğinin Değerlendirilmesi için Yöntem” IEEE 1992 adlı makaleyi yazan, Shneidewind, aslında, “Uzay Mekiğinin gelecek yazılım hatasının ne zaman olacağını haber veren ve IBM-Houston tarafından kullanılan” Schneidewind “Yazılım Güvenilirlik Modeli”’nin yaratıcısı belki de zamanımızın modern bir Branşid kahinidir…
Ali Rıza SARAL
Monday, March 05, 2007
YAZILIM YAŞAM DÖNGÜSÜ BELGELEME SİSTEMİ
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
YAZILIM YAŞAM DÖNGÜSÜ BELGELEME SİSTEMİ
(ISO9000, CMM, DO178B, Mil498, ISO12207, IEEE1407 uyumlu)
Derleyen : Ali R+ SARAL
İÇİNDEKİLER
-----------------
- KULLANICI KOŞULLARI BELGESİ - USER REQUIREMENTS DOCUMENT(URD)
- YAZILIM KOŞULLARI BELGESİ - SOFTWARE REQUIREMENTS DOCUMENT(SRD)
- MİMARİ TASARIM BELGESİ - ARCHITECTURAL DESIGN DOCUMENT(ADD)
- AYRINTILI TASARIM BELGESİ - DETAILED DESIGN DOCUMENT(DDD)
- PROJE GEÇMİŞİ BELGESİ - PROJECT HISTORY DOCUMENT(PHD)
- YAZILIM KURULUM DAĞILIMI YÖNETİMİ PLANI - SOFTWARE CONFIGURATION MANAGEMENT PLAN(SCMP)
- YAZILIM PROJESİ YÖNETİM PLANI - SOFTWARE PROJECT MANAGEMENT PLAN(SPMP)
- YAZILIM KALİTE GÜVENCESİ PLANI - SOFTWARE QUALITY ASSURANCE PLAN(SQAP)
- YAZILIM DOĞRULAYIŞ VE SINAYIŞ PLANI - SOFTWARE VALIDATION AND VERIFICATION PLAN(SVVP)
- KABUL SINAVI TANIMI - ACCEPTANCE TEST SPECIFICATION(AT)
- YAZILIM KULLANICI EL-KİTABI - SOFTWARE USER MANUAL(SUM)
- YAZILIM DEVİR BELGELERİ - SOFTWARE TRANSFER DOCUMENT(STD)
--------------------------------------------------------------------------------------------------
KULLANICI KOŞULLARI BELGESİ - USER REQUIREMENTS DOCUMENT(URD)
1. Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar, deyimler
1.4 Referanslar
1.5 Özet
2. Genel Açıklama
2.1 Ürüne genel bakış
2.2 Kullanıcı özellikleri
2.3 Genel Sınırlamalar
2.4 Kabuller ve bağımlılıklar
2.5 İşletimsel Ortam
3. Belirli Koşullar
3.1 Yetenek Şartları
3.2 Sınırlayıcı Şartlar
***********************************************************************************
YAZILIM KOŞULLARI BELGESİ - SOFTWARE REQUIREMENTS DOCUMENT(SRD)
1. Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar, deyimler
1.4 Referanslar
1.5 Özet
2 Genel Tarif
2.1 Güncel projelerler ilişkisi
2.2 Önceki ve sonraki projelerle ilişkisi
2.3 İşlev ve amaç
2.4 Ortamsal değerlendirmeler
2.5 Diğer sistemlerle ilişkisi
2.6 Genel kısıtlamalar
2.7 Model tarifi
3 Belirli Koşullar
3.1 İşlevsel koşullar
3.2 İcra seviyesi koşulları
3.3 Arayüz koşulları
3.4 İşletimsel koşullar
3.5 Kaynak koşulları
3.6 Doğrulama koşulları
3.7 Kabul testi koşulları
3.8 Belgeleme koşulları
3.9 Güvenlik koşulları
3.10 Taşınabilirlik koşulları
3.11 Kalite koşulları
3.12 Güvenilirlik koşulları
3.13 Bakım yapılabilirlik koşulları
3.14 Güvenlik koşulları
***********************************************************************************
MİMARİ TASARIM BELGESİ - ARCHITECTURAL DESIGN DOCUMENT(ADD)
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar ve deyimler
1.4 Referanslar
1.5 Kısaözet
2 Ayrıştırış Tarifi
2.1 Modül ayrıştırışı
2.1.1 Modül 1 tarifi
2.1.2 Modül 2 tarifi
2.2 Eşzamanlı Süreç tarifi
2.2.1 Süreç1 tarifi
2.2.2 Süreç2 tarifi
2.3 Veri ayrıştırışı
2.3.1 Veri varlık 1 tarifi
2.3.2 Veri varlık 2 tarifi
3 Bağıntı Tarifi
3.1 Modül ler arası bağıntılar
3.2 Süreçler arası bağıntılar
3.3 Veri bağıntıları
4 Arayüz Tarifi
4.1 Modül arayüzü
4.1.1 Modül 1 tarifi
4.1.2 Modül 2 tarifi
4.2 İşlem Süreci arayüzü
2.2.1 Süreç 1 tarifi
2.2.2 Süre 2 tarifi
***********************************************************************************
AYRINTILI TASARIM BELGESİ - DETAILED DESIGN DOCUMENT(DDD)
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar ve deyimler
1.4 Referanslar
1.5 Kısaözet
2 Ayrıştırış Tarifi
2.1 Modül ayrıştırışı
2.1.1 Modül 1 tarifi
2.1.1.1 Modül 1 ayrıntı
2.1.2 Modül 2 tarifi
2.1.1.2 Modül 2 ayrıntı
2.2 Concurrent process tarifi
2.2.1 İşlem Süreci 1 tarifi
2.2.1.1 Süreç 1 ayrıntı l
2.2.2 İşlem Süreci 2 tarifi
2.2.1.2 Süreç 2 ayrıntı
2.3 Data decomposition
2.3.1 Veri varlığı-entity 1 tarifi
2.3.1.1 Veri varlığı 1 ayrıntı
2.3.2 Veri varlığı 2 tarifi
2.3.1.2 Veri varlığı 2 ayrıntı
3 Bağıntı Tarifi
3.1 Modüller arası bağıntılar
3.1.1 Modüller arası bağıntılar ayrıntı
3.2 İşlem süreçleri arası bağıntılar
3.2.1 2 İşlem süreçleri ayrıntı
3.3 Veri bağıntıları
3.3.1 Veri bağıntıları ayrıntı
4 Arayüz Tarifi
4.1 Modül arayüzü
4.1.1 Modül 1 tarifi
4.1.1.1 Modül 1 ayrıntı
4.1.2 Modül 2 tarifi
4.1.2.1 Modül 2 ayrıntı
4.2 İşlem süreci arayüzü
2.2.1 Süreç 1 tarifi
2.2.1.1 Süreç 1 ayrıntı
2.2.2 Süreç 2 tarifi
2.2.2.1 Süreç 2 ayrıntı
***********************************************************************************
PROJE GEÇMİŞİ BELGESİ - PROJECT HISTORY DOCUMENT(PHD)
1. Proje Tanımı
2. Proje Yönetimi
2.1 Sözleşme yaklaşımı
2.2 Proje tanımı
2.3 Kullanılan Yöntemler
2.4 Planlama
3. Yazılım Üretimi
3.1 Kestirilen ve üretilmiş gerçek toplam program kod satır sayısı
3.2 Belgeleme
3.3 Kestirilen ve gerçek çaba
3.4 Bilgisayar kaynakları
3.5 Üretkenlik faktörlerinin analizi
4. Kalite Güvencesi Gözdengeçirimi
5. Finansal Gözdengeçirim
6. Sonuçlar
7. Sistemin İşletim ve Bakım Aşamasında İcra Seviyesi
***********************************************************************************
YAZILIM KURULUM DAĞILIMI YÖNETİMİ PLANI - SOFTWARE CONFIGURATION MANAGEMENT PLAN(SCMP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Sözlük
1.4 Referanslar
2 Yönetim
3 Kurulum Dağılım Tanımları
4 Kurulum Dağılım Kontrolü
4.1 Program Kod controlü
4.2 Medya kontrolü
4.3 Değişiklik kontrolü
5 Kurulum Dağılım Durum Takibi
6 Yazılım Kurlum Dağılımı Yönetimi için Araçlar, Teknikler ve Yöntemler
7 Sağlayıcı Kontrolü
8 Kayıt Biriktirme ve Korunması
***********************************************************************************
YAZILIM PROJESİ YÖNETİM PLANI - SOFTWARE PROJECT MANAGEMENT PLAN(SPMP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******
1 Giriş
1.1 Proje kısaözeti
1.2 Proje çıktıları
1.3 SPMP’nin gelişimi
1.4 Değinilen materyaller
1.5 Tanımlar ve kısaltmalar
2 Proje Düzenlenişi
2.1 Süreç modeli
2.2 Kurluşsal yapı
2.3 Kuruluşsal sınırlar ve arayüzler
2.4 Proje sorumlulukları
3 Yönetimsel Süreç
3.1 Yönetim hedefleri ve öncelikleri
3.2 Kabuller, bağıntılar ve kısıtlar
3.3 Risk yönetimi
3.4 İzleyiş ve kontrol mekanizmaları
3.5 Eleman buluş planı
4 Teknik Süreç
4.1 Yöntemler, araçlar ve teknikler
4.2 Yazılım Belgeleyiş sistemi
4.3 Project destek işlevleri
5 İş paketleri, Zaman Cetveli ve Bütçe
5.1 İş paketleri
5.2 Bağıntılar
5.3 Kaynak koşulları
5.4 Bütçe ve kaynak ayırışı
5.5 Zaman cetveli
***********************************************************************************
YAZILIM KALİTE GÜVENCESİ PLANI - SOFTWARE QUALITY ASSURANCE PLAN(SQAP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******
1 Amaç
2 Değinilen Belgeler
3 Yönetim
4 Belgeleyiş Sistemi
5 Standartlar, uygulamalar, yaklaşımlar ve ölçümler-metrics
5.1 Belgeleyiş Sistemi standartları
5.2 Tasarım standartları
5.3 Program yazış standartları
5.4 Yorum notları standartları
5.5 Sınayış standartları ve uygulayışları
5.6 Seçilmiş yazılım kalite güvencesi ölçümleri
5.7 Uyumun nasıl izleneceğinin ifadesi
6 Gözden geçirişler ve sözlü dinleyişler
6.1 Amaç
6.2 Koşulların aen alt sınırı
7 Sınav
8 Sorun raporlayış ve düzeltici eylem
9 Araçlar, teknikler ve yöntemler
10 Program metni kontrolü
11 Veri ortam kontrolü
12 Sağlayıcı kontrolü
13 Kayıt toplayış, bakım ve saklanışı
14 Eğitim
15 Risk yönetimi
16 Projenin geri kalan kısmının kısa özeti
***********************************************************************************
YAZILIM DOĞRULAYIŞ VE SINAYIŞ PLANI - SOFTWARE VALIDATION AND VERIFICATION PLAN(SVVP)
Yazılım Koşulları Aşaması
*******
Mimai Tasarım Aşaması
********
Ayrıntılı Tasarım Aşaması
********
Devir Aşaması
*******
1Amaç
2 Dayanılan Belgeler
3 Tanımlar
4 Sınama kısa özeti
4.1 Örgütleniş
4.2 Ana program
4.3 Kaynaklar özeti
4.4 Sorumluluklar
4.5 Araçlar, teknikler ve yöntemler
5 Sınama İdari İşlemleri
5.1 Gariplik raporlayış ve çözüş
5.2 Görev tekrar politikası
5.3 Sapma politikası
5.4 Kontrol işlemleri
5.5 Standartlar, uygulamalar ve yaklaşımlar
6 Sınama faaliyetleri
7 Yazılım Sınama Raporlayışı
7.1 İz sürülebilirlik matris kalıbı
7.2 Biçimsel ispatlar
7.3 Gözden geçirişler
***********************************************************************************
KABUL SINAVI TANIMI - ACCEPTANCE TEST SPECIFICATION(AT)
SVVP/AT
*******
Sistem Sınav Belirleyicisi
********************
Tümleşik Sınav Belirleyicisi
***********************
Birimsel Sınav Belirleyicisi
***********************
1 Sınav Planı
1.1 Giriş
1.2 Sınav unsurları
1.3 Sınanıcak özellikler
1.4 Sınanmayacak özellikler
1.5 Yaklaşım
1.6 Unsur geçiş/kalış koşulu
1.7 Askıya alış koşulu ve devam ediş koşulları
1.8 Sınav çıktıları
1.9 Sınayış görevleri
1.10 Ortamsal ihtiyaçlar
1.11 Sorumluluklar
1.12 Eleman durumu ve eğitim ihtiyaçları
1.13 Zamanlayış
1.14 Riskler ve umulmadık durumlar
1.15 Onaylar
2 Sınav Tasarımları (her test tasarımı başına...)
2.n.1 Sınav tasarım belirleyicisi
2.n.2 Test edilecek özellikler
2.n.3 Yaklaşım şartları
2.n.4 Sınanacak durumları belirlenişi
2.n.5 Özellik geçiş/kalış koşulu
3 Sınanıcak Durum Tarifleri(her test durumu başına...)
3.n.1 Sınanıcak durum belirleyicisi
3.n.2 Sınav unsurları
3.n.3 Giriş belirleyicileri
3.n.4 Çıkış belirleyicileri
3.n.5 Ortamsal ihtiyaçlar
3.n.6 Özel süreç koşulları
3.n.7 Durumlar arası bağımlılıklar
4 Sınav süreci(her sınav durumu başına...)
4.n.1 Sınav rapor belirleyicisi
4.n.2 Amaç
4.n.3 Özel şartlar
4.n.4 İşlem süreci adımları
5 Sınav RaporlarıTest Reports(her sınav süreci uygulaması başına bir tane...)
5.n.1 Sınav rapor belirleyicisi
5.n.2 Tarif
5.n.3 Faaliyet ve olay girişleri
***********************************************************************************
YAZILIM KULLANICI EL-KİTABI - SOFTWARE USER MANUAL(SUM)
1 Giriş
1.1 Niyetlenilen okuyucu kitlesi
1.2 Uygulanabilirlik ifadesi
1.3 Amaç
1.4 Bu belgeyi nasıl kullanmalı
1.5 İlgili belgeler
1.6 Yaklaşımlar
1.7 Sorun bildirme komutları
2 Kısa özet bölümü
(Bu bölüm kullanıcıya yazılımın hangi bölümlerinin ihtiyaç duyulan
yetenekleri sağladığına dair genel bir anlayış verir.)
3 Komutlar bölümü
(Her komut için aşağıdakileri sağlar…
(a) İşlevsel tarif
(b) Dikkat çekilen noktalar ve uyarılar
(c) İşlemler, aşağıdakiler dahil:
- Kurulum ve başlangıç
- Giriş işlemleri
- Beklenilen sonuçlar
(d) Olabilecek hatalar ve muhtemel nedenler)
4 Başvuru bölümü
(Her işlemi tanımla, aşağıdakiler dahil olmak üzere :
(a) İşlevsel tarif
(b) Dikkat çekilen noktalar ve uyarılar
(c) Biçimsel tarif, aşağıdakilerden yeri gelenler dahil olmak üzere:
- gerekli değişkenler
- isteğe bağlı değişkenler
- yoktan geçerli seçenekler
- sıra ve dilbilgisi
(d) Örnekler
(e) Olabilecek hatalar ve muhtemel nedenler
(f) Diğer işlemlere kestirme değinmeler)
Ek A Hata mesajları ve kurtarıcı işlemler
Ek B Sözlük
Ek C İçindekiler
***********************************************************************************
YAZILIM DEVİR BELGELERİ - SOFTWARE TRANSFER DOCUMENT(STD)
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, Kısaltmalar, Deyimler
1.4 Referanslar
2 Kurulum İşlemleri
3 Uygulama İnşa İşlemleri
4 Kurulum Yapısı Unsurları Listesi
5 Kabul Sınama Rapor Özeti
6 Yazılım Sorun Raporları
7 Yazılım Değişiklik İstekleri
8 Yazılım Değişiklik Raporları
***********************************************************************************
***********************************************************************************
***********************************************************************************
Hayırlı olsun...
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
YAZILIM YAŞAM DÖNGÜSÜ BELGELEME SİSTEMİ
(ISO9000, CMM, DO178B, Mil498, ISO12207, IEEE1407 uyumlu)
Derleyen : Ali R+ SARAL
İÇİNDEKİLER
-----------------
- KULLANICI KOŞULLARI BELGESİ - USER REQUIREMENTS DOCUMENT(URD)
- YAZILIM KOŞULLARI BELGESİ - SOFTWARE REQUIREMENTS DOCUMENT(SRD)
- MİMARİ TASARIM BELGESİ - ARCHITECTURAL DESIGN DOCUMENT(ADD)
- AYRINTILI TASARIM BELGESİ - DETAILED DESIGN DOCUMENT(DDD)
- PROJE GEÇMİŞİ BELGESİ - PROJECT HISTORY DOCUMENT(PHD)
- YAZILIM KURULUM DAĞILIMI YÖNETİMİ PLANI - SOFTWARE CONFIGURATION MANAGEMENT PLAN(SCMP)
- YAZILIM PROJESİ YÖNETİM PLANI - SOFTWARE PROJECT MANAGEMENT PLAN(SPMP)
- YAZILIM KALİTE GÜVENCESİ PLANI - SOFTWARE QUALITY ASSURANCE PLAN(SQAP)
- YAZILIM DOĞRULAYIŞ VE SINAYIŞ PLANI - SOFTWARE VALIDATION AND VERIFICATION PLAN(SVVP)
- KABUL SINAVI TANIMI - ACCEPTANCE TEST SPECIFICATION(AT)
- YAZILIM KULLANICI EL-KİTABI - SOFTWARE USER MANUAL(SUM)
- YAZILIM DEVİR BELGELERİ - SOFTWARE TRANSFER DOCUMENT(STD)
--------------------------------------------------------------------------------------------------
KULLANICI KOŞULLARI BELGESİ - USER REQUIREMENTS DOCUMENT(URD)
1. Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar, deyimler
1.4 Referanslar
1.5 Özet
2. Genel Açıklama
2.1 Ürüne genel bakış
2.2 Kullanıcı özellikleri
2.3 Genel Sınırlamalar
2.4 Kabuller ve bağımlılıklar
2.5 İşletimsel Ortam
3. Belirli Koşullar
3.1 Yetenek Şartları
3.2 Sınırlayıcı Şartlar
***********************************************************************************
YAZILIM KOŞULLARI BELGESİ - SOFTWARE REQUIREMENTS DOCUMENT(SRD)
1. Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar, deyimler
1.4 Referanslar
1.5 Özet
2 Genel Tarif
2.1 Güncel projelerler ilişkisi
2.2 Önceki ve sonraki projelerle ilişkisi
2.3 İşlev ve amaç
2.4 Ortamsal değerlendirmeler
2.5 Diğer sistemlerle ilişkisi
2.6 Genel kısıtlamalar
2.7 Model tarifi
3 Belirli Koşullar
3.1 İşlevsel koşullar
3.2 İcra seviyesi koşulları
3.3 Arayüz koşulları
3.4 İşletimsel koşullar
3.5 Kaynak koşulları
3.6 Doğrulama koşulları
3.7 Kabul testi koşulları
3.8 Belgeleme koşulları
3.9 Güvenlik koşulları
3.10 Taşınabilirlik koşulları
3.11 Kalite koşulları
3.12 Güvenilirlik koşulları
3.13 Bakım yapılabilirlik koşulları
3.14 Güvenlik koşulları
***********************************************************************************
MİMARİ TASARIM BELGESİ - ARCHITECTURAL DESIGN DOCUMENT(ADD)
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar ve deyimler
1.4 Referanslar
1.5 Kısaözet
2 Ayrıştırış Tarifi
2.1 Modül ayrıştırışı
2.1.1 Modül 1 tarifi
2.1.2 Modül 2 tarifi
2.2 Eşzamanlı Süreç tarifi
2.2.1 Süreç1 tarifi
2.2.2 Süreç2 tarifi
2.3 Veri ayrıştırışı
2.3.1 Veri varlık 1 tarifi
2.3.2 Veri varlık 2 tarifi
3 Bağıntı Tarifi
3.1 Modül ler arası bağıntılar
3.2 Süreçler arası bağıntılar
3.3 Veri bağıntıları
4 Arayüz Tarifi
4.1 Modül arayüzü
4.1.1 Modül 1 tarifi
4.1.2 Modül 2 tarifi
4.2 İşlem Süreci arayüzü
2.2.1 Süreç 1 tarifi
2.2.2 Süre 2 tarifi
***********************************************************************************
AYRINTILI TASARIM BELGESİ - DETAILED DESIGN DOCUMENT(DDD)
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, kısaltmalar ve deyimler
1.4 Referanslar
1.5 Kısaözet
2 Ayrıştırış Tarifi
2.1 Modül ayrıştırışı
2.1.1 Modül 1 tarifi
2.1.1.1 Modül 1 ayrıntı
2.1.2 Modül 2 tarifi
2.1.1.2 Modül 2 ayrıntı
2.2 Concurrent process tarifi
2.2.1 İşlem Süreci 1 tarifi
2.2.1.1 Süreç 1 ayrıntı l
2.2.2 İşlem Süreci 2 tarifi
2.2.1.2 Süreç 2 ayrıntı
2.3 Data decomposition
2.3.1 Veri varlığı-entity 1 tarifi
2.3.1.1 Veri varlığı 1 ayrıntı
2.3.2 Veri varlığı 2 tarifi
2.3.1.2 Veri varlığı 2 ayrıntı
3 Bağıntı Tarifi
3.1 Modüller arası bağıntılar
3.1.1 Modüller arası bağıntılar ayrıntı
3.2 İşlem süreçleri arası bağıntılar
3.2.1 2 İşlem süreçleri ayrıntı
3.3 Veri bağıntıları
3.3.1 Veri bağıntıları ayrıntı
4 Arayüz Tarifi
4.1 Modül arayüzü
4.1.1 Modül 1 tarifi
4.1.1.1 Modül 1 ayrıntı
4.1.2 Modül 2 tarifi
4.1.2.1 Modül 2 ayrıntı
4.2 İşlem süreci arayüzü
2.2.1 Süreç 1 tarifi
2.2.1.1 Süreç 1 ayrıntı
2.2.2 Süreç 2 tarifi
2.2.2.1 Süreç 2 ayrıntı
***********************************************************************************
PROJE GEÇMİŞİ BELGESİ - PROJECT HISTORY DOCUMENT(PHD)
1. Proje Tanımı
2. Proje Yönetimi
2.1 Sözleşme yaklaşımı
2.2 Proje tanımı
2.3 Kullanılan Yöntemler
2.4 Planlama
3. Yazılım Üretimi
3.1 Kestirilen ve üretilmiş gerçek toplam program kod satır sayısı
3.2 Belgeleme
3.3 Kestirilen ve gerçek çaba
3.4 Bilgisayar kaynakları
3.5 Üretkenlik faktörlerinin analizi
4. Kalite Güvencesi Gözdengeçirimi
5. Finansal Gözdengeçirim
6. Sonuçlar
7. Sistemin İşletim ve Bakım Aşamasında İcra Seviyesi
***********************************************************************************
YAZILIM KURULUM DAĞILIMI YÖNETİMİ PLANI - SOFTWARE CONFIGURATION MANAGEMENT PLAN(SCMP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Sözlük
1.4 Referanslar
2 Yönetim
3 Kurulum Dağılım Tanımları
4 Kurulum Dağılım Kontrolü
4.1 Program Kod controlü
4.2 Medya kontrolü
4.3 Değişiklik kontrolü
5 Kurulum Dağılım Durum Takibi
6 Yazılım Kurlum Dağılımı Yönetimi için Araçlar, Teknikler ve Yöntemler
7 Sağlayıcı Kontrolü
8 Kayıt Biriktirme ve Korunması
***********************************************************************************
YAZILIM PROJESİ YÖNETİM PLANI - SOFTWARE PROJECT MANAGEMENT PLAN(SPMP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******
1 Giriş
1.1 Proje kısaözeti
1.2 Proje çıktıları
1.3 SPMP’nin gelişimi
1.4 Değinilen materyaller
1.5 Tanımlar ve kısaltmalar
2 Proje Düzenlenişi
2.1 Süreç modeli
2.2 Kurluşsal yapı
2.3 Kuruluşsal sınırlar ve arayüzler
2.4 Proje sorumlulukları
3 Yönetimsel Süreç
3.1 Yönetim hedefleri ve öncelikleri
3.2 Kabuller, bağıntılar ve kısıtlar
3.3 Risk yönetimi
3.4 İzleyiş ve kontrol mekanizmaları
3.5 Eleman buluş planı
4 Teknik Süreç
4.1 Yöntemler, araçlar ve teknikler
4.2 Yazılım Belgeleyiş sistemi
4.3 Project destek işlevleri
5 İş paketleri, Zaman Cetveli ve Bütçe
5.1 İş paketleri
5.2 Bağıntılar
5.3 Kaynak koşulları
5.4 Bütçe ve kaynak ayırışı
5.5 Zaman cetveli
***********************************************************************************
YAZILIM KALİTE GÜVENCESİ PLANI - SOFTWARE QUALITY ASSURANCE PLAN(SQAP)
Yazılım Koşulları Aşaması - SR Phase
*******
Yapısal Tasarım Aşaması - AD Phase
********
Ayrınıtılı Tasarım Aşaması - DD Phase
********
Devir Aşaması - TR Phase
*******
1 Amaç
2 Değinilen Belgeler
3 Yönetim
4 Belgeleyiş Sistemi
5 Standartlar, uygulamalar, yaklaşımlar ve ölçümler-metrics
5.1 Belgeleyiş Sistemi standartları
5.2 Tasarım standartları
5.3 Program yazış standartları
5.4 Yorum notları standartları
5.5 Sınayış standartları ve uygulayışları
5.6 Seçilmiş yazılım kalite güvencesi ölçümleri
5.7 Uyumun nasıl izleneceğinin ifadesi
6 Gözden geçirişler ve sözlü dinleyişler
6.1 Amaç
6.2 Koşulların aen alt sınırı
7 Sınav
8 Sorun raporlayış ve düzeltici eylem
9 Araçlar, teknikler ve yöntemler
10 Program metni kontrolü
11 Veri ortam kontrolü
12 Sağlayıcı kontrolü
13 Kayıt toplayış, bakım ve saklanışı
14 Eğitim
15 Risk yönetimi
16 Projenin geri kalan kısmının kısa özeti
***********************************************************************************
YAZILIM DOĞRULAYIŞ VE SINAYIŞ PLANI - SOFTWARE VALIDATION AND VERIFICATION PLAN(SVVP)
Yazılım Koşulları Aşaması
*******
Mimai Tasarım Aşaması
********
Ayrıntılı Tasarım Aşaması
********
Devir Aşaması
*******
1Amaç
2 Dayanılan Belgeler
3 Tanımlar
4 Sınama kısa özeti
4.1 Örgütleniş
4.2 Ana program
4.3 Kaynaklar özeti
4.4 Sorumluluklar
4.5 Araçlar, teknikler ve yöntemler
5 Sınama İdari İşlemleri
5.1 Gariplik raporlayış ve çözüş
5.2 Görev tekrar politikası
5.3 Sapma politikası
5.4 Kontrol işlemleri
5.5 Standartlar, uygulamalar ve yaklaşımlar
6 Sınama faaliyetleri
7 Yazılım Sınama Raporlayışı
7.1 İz sürülebilirlik matris kalıbı
7.2 Biçimsel ispatlar
7.3 Gözden geçirişler
***********************************************************************************
KABUL SINAVI TANIMI - ACCEPTANCE TEST SPECIFICATION(AT)
SVVP/AT
*******
Sistem Sınav Belirleyicisi
********************
Tümleşik Sınav Belirleyicisi
***********************
Birimsel Sınav Belirleyicisi
***********************
1 Sınav Planı
1.1 Giriş
1.2 Sınav unsurları
1.3 Sınanıcak özellikler
1.4 Sınanmayacak özellikler
1.5 Yaklaşım
1.6 Unsur geçiş/kalış koşulu
1.7 Askıya alış koşulu ve devam ediş koşulları
1.8 Sınav çıktıları
1.9 Sınayış görevleri
1.10 Ortamsal ihtiyaçlar
1.11 Sorumluluklar
1.12 Eleman durumu ve eğitim ihtiyaçları
1.13 Zamanlayış
1.14 Riskler ve umulmadık durumlar
1.15 Onaylar
2 Sınav Tasarımları (her test tasarımı başına...)
2.n.1 Sınav tasarım belirleyicisi
2.n.2 Test edilecek özellikler
2.n.3 Yaklaşım şartları
2.n.4 Sınanacak durumları belirlenişi
2.n.5 Özellik geçiş/kalış koşulu
3 Sınanıcak Durum Tarifleri(her test durumu başına...)
3.n.1 Sınanıcak durum belirleyicisi
3.n.2 Sınav unsurları
3.n.3 Giriş belirleyicileri
3.n.4 Çıkış belirleyicileri
3.n.5 Ortamsal ihtiyaçlar
3.n.6 Özel süreç koşulları
3.n.7 Durumlar arası bağımlılıklar
4 Sınav süreci(her sınav durumu başına...)
4.n.1 Sınav rapor belirleyicisi
4.n.2 Amaç
4.n.3 Özel şartlar
4.n.4 İşlem süreci adımları
5 Sınav RaporlarıTest Reports(her sınav süreci uygulaması başına bir tane...)
5.n.1 Sınav rapor belirleyicisi
5.n.2 Tarif
5.n.3 Faaliyet ve olay girişleri
***********************************************************************************
YAZILIM KULLANICI EL-KİTABI - SOFTWARE USER MANUAL(SUM)
1 Giriş
1.1 Niyetlenilen okuyucu kitlesi
1.2 Uygulanabilirlik ifadesi
1.3 Amaç
1.4 Bu belgeyi nasıl kullanmalı
1.5 İlgili belgeler
1.6 Yaklaşımlar
1.7 Sorun bildirme komutları
2 Kısa özet bölümü
(Bu bölüm kullanıcıya yazılımın hangi bölümlerinin ihtiyaç duyulan
yetenekleri sağladığına dair genel bir anlayış verir.)
3 Komutlar bölümü
(Her komut için aşağıdakileri sağlar…
(a) İşlevsel tarif
(b) Dikkat çekilen noktalar ve uyarılar
(c) İşlemler, aşağıdakiler dahil:
- Kurulum ve başlangıç
- Giriş işlemleri
- Beklenilen sonuçlar
(d) Olabilecek hatalar ve muhtemel nedenler)
4 Başvuru bölümü
(Her işlemi tanımla, aşağıdakiler dahil olmak üzere :
(a) İşlevsel tarif
(b) Dikkat çekilen noktalar ve uyarılar
(c) Biçimsel tarif, aşağıdakilerden yeri gelenler dahil olmak üzere:
- gerekli değişkenler
- isteğe bağlı değişkenler
- yoktan geçerli seçenekler
- sıra ve dilbilgisi
(d) Örnekler
(e) Olabilecek hatalar ve muhtemel nedenler
(f) Diğer işlemlere kestirme değinmeler)
Ek A Hata mesajları ve kurtarıcı işlemler
Ek B Sözlük
Ek C İçindekiler
***********************************************************************************
YAZILIM DEVİR BELGELERİ - SOFTWARE TRANSFER DOCUMENT(STD)
1 Giriş
1.1 Amaç
1.2 Kapsam
1.3 Tanımlar, Kısaltmalar, Deyimler
1.4 Referanslar
2 Kurulum İşlemleri
3 Uygulama İnşa İşlemleri
4 Kurulum Yapısı Unsurları Listesi
5 Kabul Sınama Rapor Özeti
6 Yazılım Sorun Raporları
7 Yazılım Değişiklik İstekleri
8 Yazılım Değişiklik Raporları
***********************************************************************************
***********************************************************************************
***********************************************************************************
Hayırlı olsun...
Thursday, February 22, 2007
Kontrol Odası Kurulum Yapısı (Operations Room Configuration)
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.
(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.
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
Friday, January 05, 2007
KAPANMAYIŞLAR
EUROCONTROL Software Team Karlsruhe –
KARLDAP’ın sistem babası
Rolf MÜHLSTROH’un anısına…
KAPANMAYIŞLAR
Kapanışlar, kapanmayışlar, kapanamayışlar…
Herbirimizin bazen aklından çıkaramadığı, düşünmekten kendini alamadığı, kapatamadığı konular olur… Bazen işte halledemediğimiz bir problem akşam evde aklımızı kurcalar. Bazen halledemediğimiz bir sıkıntımız hiç alakası olmayan bir yerde, trafik tıkandığında hop diye aklımızda belirir… Bazen Arşimed gibi bir bilim adamı bir türlü çözemediği bir problemin çözümünü hamamda bulup sevinçten “Buldum buldum!” diye dışarı fırlar… Bazen stress altında çalışan bir mühendis evinden çıkar ama sokak kapısını kilitlediğine bir türlü emin olamadığından otobüsü kaçırıp işe geç kalır… Bazen evi terketmeden önce son anda elektrikleri, suyu ya da ütüyü açık unuttuğunuzu hatırlarsınız…
Bu saydıklarımı herbirimiz farklı şekillerde farklı durumlarda yaşarız. Hiç birimiz bunların ya da benzeri durumların hiçbirini yaşamamış olamaz. Çünkü kapanışlar, kapanmayışlar ve kapanamayışlar hepimize özgü, insana özgü olgular... Bazen bir yetenek, bazen hoş bir oyun, bazen sezgi, bazen içgüdü, bazen bir alışkanlık, bazen kişinin kendisi için henüz tanımlamadığı bir şey… Bir açık kapı belki…
Karşılaştığımız sorunları aşmak için kullandığımız bir yeteneğimiz, TUTKU… Ya da İngilizce OBSSESSION… Bir sorunu kolaylıkla aşamazsak, konu aklımıza takılır ve kendiliğinden aklımıza tekrar gelir, ilişkili ilişkisiz ortamlarda… Hatta başka bir nedenden ya da ortamdan sıkılıdığımızda o çözemediğimiz sorunu düşünürken buluruz kendimizi…
Obsesyon istenmeyen, tekrar eden ve akla kolayca gelen fikri sabit halindeki düşünceler, dürtüler ya da hayaller şeklinde beliriyor ise obsessif-kompulsif düzensizlik olarak değerlendirilir (Obsessive-Compulsive Disorder (OCD) by Amy Scholten, MPH). Kompulsiyon ise obsesyonlar ile ilgili oluşan baskıyı azaltmak için tekrarlanan hareketler veya zihinsel davranışlar şeklinde belirir.
Sık görülen obsesyonlar şunları içerir:
Kendine ya da sevdiklerine zarar geleceği korkusu
Gerçekçi olmayan kirlenme duygusu
Kabul edilemeyecek dini, şiddet içeren ya da cinsel düşünceler
Herşeyi doğru ve tam yapmak için aşırı ihtiyaç duymak
Sık görülen kompulsiyonlar şunları içerir:
Kapı kilitlerinin, sobaların, muslukların, elektrik düğmelerinin vb. kapatılıp kapatılmadığının aşırı kontrolü
Nesneleri defalarca listelemek, saymak, düzenlemek veya yerleştirmek.
İşe yaramayan nesneleri toplamak ve biriktirmek
Belirli bir hareket dizisini içi rahatlayıncaya kadar tekrar etmek
Gereksiz yere tekrar tekrar okumak ve yazmak
Zihinde belli kalıp cümleleri tekrar etmek
Elleri defalarca yıkamak
Meisner ‘The Paranoid Process’ adlı kitabının önsözünde, "çok ilkel ve rahatsız hastalarımızın psikotik süreçleri göreli olarak sağlıklı ve çok daha uyumlu insan varlıklarında da belirlenebilir” der. “Hiç birimizin kaçamayacağı, insan tecrübesi ve varlığının temel problemlerini tanımlamak ve çözmek çabası içinde, hepimizin insan olarak paylaştığı yeteneklerimizi kullanarak, hastalarım ve benim benzer sorunlarla uğraştığımızı gözlemledim.”
Aslında, obsesyon karşılaştığımız güçlükleri aşmamıza yardımcı olan olumlu bir yeteneğimiz… Sorun bu durumun istenmeyen konuları, tekrar tekrar getirmesi ve en ufak şeyin bile o fikri sabiti kolayca hatırlatması… Bir bakıma sorun çözme mekanizmamızın kontrolümüz dışına çıması sanki… Yukarıda obsesyon belirtisi için yaptığım alıntıya tekrar bakarsanız, kontrol kelimesinin titizlikle kullanılmadığını görürsünüz… Çünkü obsesyonun tanım olarak yaşamımızdaki fonksiyonu kontrol dışında olmayı da içerir… Arşimede ilham gelmesi için gerekli epistemology (çözüm sağlayıcı ortam) obsesyon tarafından sağlanır. Sezgi, ilham vb. yaratıcılık unsurlarının tetiklenebilmesi için obsesyonun biraz kontrol dışı olması gerekli sanki…
“In its inner nature, belief or the sense of reality, is a sort of feeling more allied to the emotions than anything else. … The true opposite of belief, psychologically considered, are doubt and inquiry, not disbelief.”
William James (1890, The principles of psychology. NewYork: H. Holt pp. 283-284) kitabında
“İnanç ya da gerçeklik duygusu, içsel tabiatında diğer herşeyden çok duygulara bağımlı bir algı çeşididir. … Psikolojik olarak inancın gerçek zıttı , inançsızlık değil şüphe ve sorgulamadır.” der.
Gerçek nedir? Nasıl inanırız bir şeyin gerçek olduğuna? Özellikle hayati risk içeren bir durumda… Woody, E., & Szechtman, H. (2000) Hypnotic hallucinations and yedasentience. ContemporaryHypnosis, (17, 26-31) adlı kitaplarında; “içimizden gelen bir ‘bilme hissi’ hedeflenen-amaca vardığımıza ait olgusal bir işaret sağlar ve bunun sonucunda kendimize veya diğer kişilere zarar gelmesinden çekinmemize neden olan harekete geçirici düşünce, fikir veya hareketlerin sona ermesine neden olur. Bu hissi oluşturamama ya da hissedememe tipik obssessif-kompulsif düzensizlik (OKD) belirtilerini oluşturur”, der.
Büyük sistemlerde test sistemi ana sistemin aynısı ya da çok benzeridir. Bu yüzden test yapabileceğiniz tek bir sistem vardır. 50 – 60 kişilik bir yazılım ekibinde herkes serbest test zamanı bulmak için rekabet halindedir. Bu durumda ufak bir hata yapmak sorumluluğunuzu üstlendiğiniz güvenlik önleminin gerçekleşmesini dolayısıyla çok sayıda insanın güvenliğini riske atar. Bu durumda teste girerken son kontrollerinizi yaparsınız.
Kapadığınız bir kumanda anahtarı kapanmış mıdır yoksa açık mı kalmıştır? Bakarsınız, tekrar bakarsınız, emin olmak için tekrar kaparsınız, bu boyle gider… Tıpkı güneydoğuda görev yapan bir helikopter pilotu dostum gibi, ya da bazen siz evinizden çıkarken kapıyı defaatle
kilitleyip kontrol etmeniz gibi… Yaptığımız kontrol bize somut bilgi sağlar, kapatmışızdır. Fakat bu bilgi gitmesi gereken yere ulaşamaz. Başlı başına bu bilgi “Evet, kapıyı kapattım ve kontrol ettim, şimdi işime gitmeliyim” demez bize… OKD’den rahatsız olan kişiler, hasta veya normal de olsalar problemli oldukları konuyu nesnel bir şekilde bilirler fakat subjektif şekilde o olguya inanamazlar. Anahtarı çevirdiklerini görürler ama kapıyı kilitlediklerine inanamazlar ya da kısa süre içinde unuturlar.
OKD hastalarının rahatsızlığının temelinde üç ayrı olgu yatar:
1. Onların ilgili davranış ve korkuları varlığımıza yönelmiş tehditleri değerlendiren güçlü bir özel bir güdü tarafından oluşturulurlar.
2. Bu güdü sistemi harici bir sonuçlandırıcı sistemi olmayan açık uçlu bir sistemdir.
3. Çevreden gelebilecek bu tür bir uyarıcı işaretin olmaması yüzünden hedefe varıldığının anlaşılması içten gelen sonlandırıcı (bildiğini hissetme şeklinde yaşanan) ile belli olmaktadır. OKD hastaları ya bu duygusal işareti oluşturamamakta ya da bu işaret oluşmuş bulunan dürtüyü bastırmaya yetmemektedir.
“’Bildiğini hissetme’ kişi o anda bir bilgiyi aklına getiremese bile onu bildiğini hissetmesi durumu için kullanılır, cognitive yazında…(Nelson, T. O., Gerler, D., & Narens, L. (1984). Accuracy of feeling-of-knowing judgments for predicting perceptual identification and relearning. Journal of Experimental Psychology: General, 113, 282-300.) Açlık veya cinsellik gibi dürtüler benzer özellik taşısa da güvenlik dürtüsü gerçeğe-dayanan sonuçlandırıcı uyarı taşımaması bakımından ayrıcalıklıdır ve açık-uçludur.
“Eğer türün vahşi düşmanlarının ve diğer tehlikelerin kontrol altında tutulması faaliyetlerinin duyularını harekete geçirecek gerçek uyarılar olmadan harekete geçtiği dikkate alınırsa problem daha da ağırlaşır – yani harekete geçirilen faaliyet potansiyel bir tehlikeye yönlendirilmektedir.”
“Benzer şekilde, içten gelen bilme duygusu yalnız hedefe-varıldığını belirten bir olgu işareti değil aynı zamanda güvenlik dürtüsünü kapatan bir fizyolojik mekanizmadır.” “OKD belirtileri özel bir ‘güvenlik’ sisteminin ifadesini oluşturur. ‘Güvenliği’ amaç olarak taşıyan bir dürtü klasik psikoloji tarafından tanınan açlık, acı, sex, analık ve araştırma dürtülerinden biri değildir (Hebb, D. O. (1966). A textbook of psychology. Philadelphia: Saunders)”. Trower ( Trower, P., Gilbert, P., & Sherling, G. (1990). Social anxiety, evolution, and self-presentation: An interdisciplinary perspective. In H. Leitenberg (Ed.), Handbook of social and evaluation) hem fiziksel hem de sosyal potensiyel tehditlerin tesbiti ve değerlendirilmesi ile ilgili temel dürtüsel nitelik taşıyan bir ‘güvenlik’ sistemi kavramını ileri sürmüştür.
Kendi veya diğerlerinin güvenliğini korumaya yönelik biyolojik tabanlı (‘hardwired’) türe-özgü davranışlar biyolojik olarak ilkel ve türün devamı için zorunlu bir eğilimin varlığını gösterir. “Bu tür moduler sistemler bünyesel olarak tanımlı ve yapıya gömülü(hardwired), belirli girdilere karşı yüksek hassasiyetli, göreli olarak otomatik ve otonom, ve “kendi içine kapalı” veya diğer sistemler tarafından üretilen bilgiden nispeten yalıtılmıştır”.
“Vahşilere kurban olma riskinde geçici değişiklikler bir çok hayvan için hayatın bir gerçeğidir ve yüzlerce çalışma hayvanların vahşilere kurban olma riskindeki değişimlere çabuk ve uyumlu bir şekilde yanıt verdiklerini gösterir. Bu riskteki değişimin sonucunda, hayvanlar beslenme ve vahşilere karşı korunma faaliyetlerini farklı risk durumularına karşı nasıl düzenlemeleri gerektiği problemi ile karşılaşırlar”.
“Koruma dürtüsü sistemi kolaylıkla aktive olur. Küçük bir tehlike olasılığı bile bu sistemi tetikleyebilir. Değerlendirme sürecini besleyen çevredeki koşullar değişse bile bir kere tetiklendi mi uzun bir yarılanma süresi vardır “(Masterson, F. A., & Crawford, M. (1982). The Defense Motivation System - A Theory of Avoidance-Behavior. Behavioral and Brain Sciences, 5, 661-675). Curio, E. (1993). Proximate and developmental aspects of antipredator behavior. Advances in the Study of Behavior, 22, 135-238).
Bu açılması kolay, kapanması zor olma özelliği evrimsel açıdan anlaşılabilir, çünkü tekrar eden yanlış alarmlar gelmekte olan gerçek tehlikeye karşı tek bir hatadan bile daha önemsizdirler. Bu sistem çocuklar ya da sürünün diğer elemanları için de aktive olur (Curio, 1993).
“Özellikle önem verilmesi gereken bir husus ta, Öhman and Mineka (2001)’nın ‘korku modulü’ adını verdiği korkuyu öğrenmeyi ve ondan kaçmayı, kaçınmayı düzenleyen sistem ile önleme almaya yönelik güvenlik dürtüsü sistemi arasındaki farktır”.
Öhman and Mineka (2001. Fears, phobias, and preparedness: toward an evolved module of fear and fear learning. Psychological Review, 108, 483-522) potansiyel olarak felaket taşıyan olayların … bazı ince ipuçları ile haber verilebileceğini belirtirler. “Örneğin, dikkatli bir gözlemciye, vahşi bir saldırgan ses veya koku olarak varlığını belli edebilir. Bu tür ipuçları ile potansiyel ölümcül sonuçları arasındakı karşılıklı eşleşme, merkezi korku dürtüsünü koşullayabilir”.
“Korku modülüne karşıt olarak güvenlik dürtü sistemi ‘potansiyel olarak ölümcül’ sonuçları olan durumlarla gerçekten karşılaşmaya dayanmaz, fakat daha başka, ince, açık bir tehlike olmayan durumlardaki ‘gizli riskleri’ belirten ve koşullanmaya dayanmayan iç uyarılar ile çalışır. Bir başka ayrım da güvenlik-dürütülü davranışın kötü bir kokuyu savmak yerine bilgi edinme ve toplamaya yönelik olmasıdır”.
“Obsessive-Compulsive Disorder as a Disturbance of Security Motivation
Henry Szechtman, Erik Woody” makalesinden yapmış olduğum çok sayıda alıntı ve özet göstermektedir ki güvenlik dürtü sistemimiz korku sistemimizden bile daha karmaşık ve soyuttur. Ucu-açık olmak zorunluluğu, dinamik olarak risk duygusunun ayarlanması, cognitive olmayan bir durdurma mekanizması ve bildiğini hissetmenin yalnız duygusal değil bilinçaltı ile ilişkisi, potansiyel tehlikenin aynı zamanda hafıza ve cognitive olan bir tetikleme mekanizması içermesi obsesif-kompulsif düzensizlik için uygun bir alt yapı oluşturmaktadır.
“Affect and Processing Dynamics- Perceptual Fluency Enhances Evaluations” makalesinde Winkielman et all. İşleme kolaylığı(hızlı iletişim) pozitif değerlendirmeye, çabuk duygusal tepki almanın karar vermede olumlu etkisine işaret eder. Literatürde duygusal durumun düşünme üzerine etkisi ile ilgili bir çok makale var.
Duygusal durumumuz güvenlik sistemimizin çalışmasını da etkiler. “Compulsive Checking Behaviors in Generalized Anxiety Disorder, Alexander J. Schut, Louis G. Castonguay,
and Thomas D. Borkovec” makalesi “tasalanma ile genel tasalanma düzensizliği ve kompulsif davranışlar özellikle kompulsif kontrol etme arasında bir ilişki olduğunu” göstermektedir.
Büyük sistemlerde, askeri projelerde proje süreci çoğunlukla katılanları belirsizlik içinde bırakan uzun bekleme dönemleri içerir. Bu dönemlerin kişiler üzerinde yaptığı tasalanma etkisi kişilerin psikolojik durumları ve OKD’ye maruz kalmaları açısından yüksek riskler içerir. Aşırı stresin kişilerin tuvalete gitme gibi küçük yaşlarında koşullandıkları alışkanlıklarının bozulmasına neden olduğu kolaylıkla gözlenebilir… Bu durum OKD etkisinin büyük sistemler çalışanları açısından ne kadar hassas bir konu olabileceğini gösterir.
Sorun, kişinin kontrol ettiği şeyi kontrol etmiş olduğu sonucuna varamamasıdır. Teknik eğitimden gelen kişilerin, mühendislerin çok başvurdukları bir çare, kontrol sayısını arttırmak, kontrol türünü (ses, hareket vb) değiştirmek, konsantrasyonu arttırmak, daha çok dikkat toplamak, kontrol ettiğini aklında tutmaya çalışmak, kağıtlara not tutmak vb… Sonuçta bunların hepsi bir noktadan sonra işe yaramaz… Çünkü mühendis formasyon itibarı ile olayı cognitive olarak çözmeye çalışır.
Oysa tamamlanma, kapanma duygusunu veren, kontrol ettiğini bilme duygusudur, yani bir duygudur. Çok kızdığınız zaman nasıl sakinleşirsiniz? Kızdığınızı fark ederek. Çünkü duygular sabun köpüğü gibidir… Farkına bilinciniz ile vardığınız an fikre dönüşürler his olarak yok olurlar… İmdi, kontrol sırasında, aşırı dikkat toplama, özellikle ek kontroller değişkenler kullanma kontrol sürecinde bilinçsel-cognitive ağırlığı arttırdığı için siz tamamlanma – kapanma hissi uyandıran bilme duygusunu öldürmüş olursunuz ve kaçınılmaz olarak tekrar kontrol etme ihtiyacı duyarsınız, bir çevrim halinde bu böyle devam eder…
Bir diğer önemli noktada güvenlik dürtüsü sistemimizin hard-coded yani fiziki olarak gömülü, kendi içinde kapalı bir sistem olmasıdır. Zihnimiz, beynimiz bir çok fiziksel ya da fonsiyonel alt sistemden oluşmaktadır. Aşırı dikkat toplayarak çalışmaya alışmış büyük sistem mühendisleri ya da hayati işlerle uğraşan kişiler, dikkatlerini kontrol ettikleri şeye benzer şekilde yoğunlaştırırlarsa güvenlik dürtüsü sistemlerini devre dışı bırakırlar. Düşünme hızımız ve dikkat toplama oranımız beynimizin kullandığı alt sistemi seçmemizi sağlar. Uzun süre aşırı dikkat toplayarak çalışan kişilerin beyinlerinin otomatik prosessor seçme özellikleri bozulabilir. Bu durum bu kişileri OKD’ye karşı hassas duruma getirebilir. Kapıyı kilitlerken aşırı dikkat toplamak yerine biraz yavaş hareket edip hiçbir şey düşünmemeye çalışarak göz ucuyla anahtara bakmak yeterli olabilir örneğin. Ayrıca günlük yaşamdaki her detayı bir hava trafik kontrolü sisteminin saniyeler mertebesindeki hassaslığı ve apaçık kesin doğruluğu ile hatırlamamızı beklemek fazla olmaz mı?
Ülkemizde yeni oluşmakta olan büyük sistem kültürüne katkısı olması dileği ile.
Ali Rıza SARAL
NOT: OKD normal insanlarda da zaman zaman görülebilen bir rahatsızlıktır. Derinliği ve tekrar sıklığı zaman ile artarsa şizofrenik görünümler alacak kadar ciddi ruhsal rahtsızlıklara dönüşebilir. Eğer kendiliğinden düzelmiyorsa bir psikiyatriste gözükmekte fayda vardır. Büyük sistemlerde ya da kendine- başkalarına hayati risk taşıyan işlerde çalışan kişilerin çok seyrek olmayan aralarla düzenli olarak doktor kontrolünden geçmesi gerekir. Bazı psikolojik rahatsızlıkların tanısı günümüz teknolojisi ile iki yılın üzerinde sürebilmektedir. Bu nedenle ve doktorun hastayı tanıma süresini kısaltmak amacı ile yüksek risk altında çalışan kişilerin önceden kontrol altında olması gerekir.
KARLDAP’ın sistem babası
Rolf MÜHLSTROH’un anısına…
KAPANMAYIŞLAR
Kapanışlar, kapanmayışlar, kapanamayışlar…
Herbirimizin bazen aklından çıkaramadığı, düşünmekten kendini alamadığı, kapatamadığı konular olur… Bazen işte halledemediğimiz bir problem akşam evde aklımızı kurcalar. Bazen halledemediğimiz bir sıkıntımız hiç alakası olmayan bir yerde, trafik tıkandığında hop diye aklımızda belirir… Bazen Arşimed gibi bir bilim adamı bir türlü çözemediği bir problemin çözümünü hamamda bulup sevinçten “Buldum buldum!” diye dışarı fırlar… Bazen stress altında çalışan bir mühendis evinden çıkar ama sokak kapısını kilitlediğine bir türlü emin olamadığından otobüsü kaçırıp işe geç kalır… Bazen evi terketmeden önce son anda elektrikleri, suyu ya da ütüyü açık unuttuğunuzu hatırlarsınız…
Bu saydıklarımı herbirimiz farklı şekillerde farklı durumlarda yaşarız. Hiç birimiz bunların ya da benzeri durumların hiçbirini yaşamamış olamaz. Çünkü kapanışlar, kapanmayışlar ve kapanamayışlar hepimize özgü, insana özgü olgular... Bazen bir yetenek, bazen hoş bir oyun, bazen sezgi, bazen içgüdü, bazen bir alışkanlık, bazen kişinin kendisi için henüz tanımlamadığı bir şey… Bir açık kapı belki…
Karşılaştığımız sorunları aşmak için kullandığımız bir yeteneğimiz, TUTKU… Ya da İngilizce OBSSESSION… Bir sorunu kolaylıkla aşamazsak, konu aklımıza takılır ve kendiliğinden aklımıza tekrar gelir, ilişkili ilişkisiz ortamlarda… Hatta başka bir nedenden ya da ortamdan sıkılıdığımızda o çözemediğimiz sorunu düşünürken buluruz kendimizi…
Obsesyon istenmeyen, tekrar eden ve akla kolayca gelen fikri sabit halindeki düşünceler, dürtüler ya da hayaller şeklinde beliriyor ise obsessif-kompulsif düzensizlik olarak değerlendirilir (Obsessive-Compulsive Disorder (OCD) by Amy Scholten, MPH). Kompulsiyon ise obsesyonlar ile ilgili oluşan baskıyı azaltmak için tekrarlanan hareketler veya zihinsel davranışlar şeklinde belirir.
Sık görülen obsesyonlar şunları içerir:
Kendine ya da sevdiklerine zarar geleceği korkusu
Gerçekçi olmayan kirlenme duygusu
Kabul edilemeyecek dini, şiddet içeren ya da cinsel düşünceler
Herşeyi doğru ve tam yapmak için aşırı ihtiyaç duymak
Sık görülen kompulsiyonlar şunları içerir:
Kapı kilitlerinin, sobaların, muslukların, elektrik düğmelerinin vb. kapatılıp kapatılmadığının aşırı kontrolü
Nesneleri defalarca listelemek, saymak, düzenlemek veya yerleştirmek.
İşe yaramayan nesneleri toplamak ve biriktirmek
Belirli bir hareket dizisini içi rahatlayıncaya kadar tekrar etmek
Gereksiz yere tekrar tekrar okumak ve yazmak
Zihinde belli kalıp cümleleri tekrar etmek
Elleri defalarca yıkamak
Meisner ‘The Paranoid Process’ adlı kitabının önsözünde, "çok ilkel ve rahatsız hastalarımızın psikotik süreçleri göreli olarak sağlıklı ve çok daha uyumlu insan varlıklarında da belirlenebilir” der. “Hiç birimizin kaçamayacağı, insan tecrübesi ve varlığının temel problemlerini tanımlamak ve çözmek çabası içinde, hepimizin insan olarak paylaştığı yeteneklerimizi kullanarak, hastalarım ve benim benzer sorunlarla uğraştığımızı gözlemledim.”
Aslında, obsesyon karşılaştığımız güçlükleri aşmamıza yardımcı olan olumlu bir yeteneğimiz… Sorun bu durumun istenmeyen konuları, tekrar tekrar getirmesi ve en ufak şeyin bile o fikri sabiti kolayca hatırlatması… Bir bakıma sorun çözme mekanizmamızın kontrolümüz dışına çıması sanki… Yukarıda obsesyon belirtisi için yaptığım alıntıya tekrar bakarsanız, kontrol kelimesinin titizlikle kullanılmadığını görürsünüz… Çünkü obsesyonun tanım olarak yaşamımızdaki fonksiyonu kontrol dışında olmayı da içerir… Arşimede ilham gelmesi için gerekli epistemology (çözüm sağlayıcı ortam) obsesyon tarafından sağlanır. Sezgi, ilham vb. yaratıcılık unsurlarının tetiklenebilmesi için obsesyonun biraz kontrol dışı olması gerekli sanki…
“In its inner nature, belief or the sense of reality, is a sort of feeling more allied to the emotions than anything else. … The true opposite of belief, psychologically considered, are doubt and inquiry, not disbelief.”
William James (1890, The principles of psychology. NewYork: H. Holt pp. 283-284) kitabında
“İnanç ya da gerçeklik duygusu, içsel tabiatında diğer herşeyden çok duygulara bağımlı bir algı çeşididir. … Psikolojik olarak inancın gerçek zıttı , inançsızlık değil şüphe ve sorgulamadır.” der.
Gerçek nedir? Nasıl inanırız bir şeyin gerçek olduğuna? Özellikle hayati risk içeren bir durumda… Woody, E., & Szechtman, H. (2000) Hypnotic hallucinations and yedasentience. ContemporaryHypnosis, (17, 26-31) adlı kitaplarında; “içimizden gelen bir ‘bilme hissi’ hedeflenen-amaca vardığımıza ait olgusal bir işaret sağlar ve bunun sonucunda kendimize veya diğer kişilere zarar gelmesinden çekinmemize neden olan harekete geçirici düşünce, fikir veya hareketlerin sona ermesine neden olur. Bu hissi oluşturamama ya da hissedememe tipik obssessif-kompulsif düzensizlik (OKD) belirtilerini oluşturur”, der.
Büyük sistemlerde test sistemi ana sistemin aynısı ya da çok benzeridir. Bu yüzden test yapabileceğiniz tek bir sistem vardır. 50 – 60 kişilik bir yazılım ekibinde herkes serbest test zamanı bulmak için rekabet halindedir. Bu durumda ufak bir hata yapmak sorumluluğunuzu üstlendiğiniz güvenlik önleminin gerçekleşmesini dolayısıyla çok sayıda insanın güvenliğini riske atar. Bu durumda teste girerken son kontrollerinizi yaparsınız.
Kapadığınız bir kumanda anahtarı kapanmış mıdır yoksa açık mı kalmıştır? Bakarsınız, tekrar bakarsınız, emin olmak için tekrar kaparsınız, bu boyle gider… Tıpkı güneydoğuda görev yapan bir helikopter pilotu dostum gibi, ya da bazen siz evinizden çıkarken kapıyı defaatle
kilitleyip kontrol etmeniz gibi… Yaptığımız kontrol bize somut bilgi sağlar, kapatmışızdır. Fakat bu bilgi gitmesi gereken yere ulaşamaz. Başlı başına bu bilgi “Evet, kapıyı kapattım ve kontrol ettim, şimdi işime gitmeliyim” demez bize… OKD’den rahatsız olan kişiler, hasta veya normal de olsalar problemli oldukları konuyu nesnel bir şekilde bilirler fakat subjektif şekilde o olguya inanamazlar. Anahtarı çevirdiklerini görürler ama kapıyı kilitlediklerine inanamazlar ya da kısa süre içinde unuturlar.
OKD hastalarının rahatsızlığının temelinde üç ayrı olgu yatar:
1. Onların ilgili davranış ve korkuları varlığımıza yönelmiş tehditleri değerlendiren güçlü bir özel bir güdü tarafından oluşturulurlar.
2. Bu güdü sistemi harici bir sonuçlandırıcı sistemi olmayan açık uçlu bir sistemdir.
3. Çevreden gelebilecek bu tür bir uyarıcı işaretin olmaması yüzünden hedefe varıldığının anlaşılması içten gelen sonlandırıcı (bildiğini hissetme şeklinde yaşanan) ile belli olmaktadır. OKD hastaları ya bu duygusal işareti oluşturamamakta ya da bu işaret oluşmuş bulunan dürtüyü bastırmaya yetmemektedir.
“’Bildiğini hissetme’ kişi o anda bir bilgiyi aklına getiremese bile onu bildiğini hissetmesi durumu için kullanılır, cognitive yazında…(Nelson, T. O., Gerler, D., & Narens, L. (1984). Accuracy of feeling-of-knowing judgments for predicting perceptual identification and relearning. Journal of Experimental Psychology: General, 113, 282-300.) Açlık veya cinsellik gibi dürtüler benzer özellik taşısa da güvenlik dürtüsü gerçeğe-dayanan sonuçlandırıcı uyarı taşımaması bakımından ayrıcalıklıdır ve açık-uçludur.
“Eğer türün vahşi düşmanlarının ve diğer tehlikelerin kontrol altında tutulması faaliyetlerinin duyularını harekete geçirecek gerçek uyarılar olmadan harekete geçtiği dikkate alınırsa problem daha da ağırlaşır – yani harekete geçirilen faaliyet potansiyel bir tehlikeye yönlendirilmektedir.”
“Benzer şekilde, içten gelen bilme duygusu yalnız hedefe-varıldığını belirten bir olgu işareti değil aynı zamanda güvenlik dürtüsünü kapatan bir fizyolojik mekanizmadır.” “OKD belirtileri özel bir ‘güvenlik’ sisteminin ifadesini oluşturur. ‘Güvenliği’ amaç olarak taşıyan bir dürtü klasik psikoloji tarafından tanınan açlık, acı, sex, analık ve araştırma dürtülerinden biri değildir (Hebb, D. O. (1966). A textbook of psychology. Philadelphia: Saunders)”. Trower ( Trower, P., Gilbert, P., & Sherling, G. (1990). Social anxiety, evolution, and self-presentation: An interdisciplinary perspective. In H. Leitenberg (Ed.), Handbook of social and evaluation) hem fiziksel hem de sosyal potensiyel tehditlerin tesbiti ve değerlendirilmesi ile ilgili temel dürtüsel nitelik taşıyan bir ‘güvenlik’ sistemi kavramını ileri sürmüştür.
Kendi veya diğerlerinin güvenliğini korumaya yönelik biyolojik tabanlı (‘hardwired’) türe-özgü davranışlar biyolojik olarak ilkel ve türün devamı için zorunlu bir eğilimin varlığını gösterir. “Bu tür moduler sistemler bünyesel olarak tanımlı ve yapıya gömülü(hardwired), belirli girdilere karşı yüksek hassasiyetli, göreli olarak otomatik ve otonom, ve “kendi içine kapalı” veya diğer sistemler tarafından üretilen bilgiden nispeten yalıtılmıştır”.
“Vahşilere kurban olma riskinde geçici değişiklikler bir çok hayvan için hayatın bir gerçeğidir ve yüzlerce çalışma hayvanların vahşilere kurban olma riskindeki değişimlere çabuk ve uyumlu bir şekilde yanıt verdiklerini gösterir. Bu riskteki değişimin sonucunda, hayvanlar beslenme ve vahşilere karşı korunma faaliyetlerini farklı risk durumularına karşı nasıl düzenlemeleri gerektiği problemi ile karşılaşırlar”.
“Koruma dürtüsü sistemi kolaylıkla aktive olur. Küçük bir tehlike olasılığı bile bu sistemi tetikleyebilir. Değerlendirme sürecini besleyen çevredeki koşullar değişse bile bir kere tetiklendi mi uzun bir yarılanma süresi vardır “(Masterson, F. A., & Crawford, M. (1982). The Defense Motivation System - A Theory of Avoidance-Behavior. Behavioral and Brain Sciences, 5, 661-675). Curio, E. (1993). Proximate and developmental aspects of antipredator behavior. Advances in the Study of Behavior, 22, 135-238).
Bu açılması kolay, kapanması zor olma özelliği evrimsel açıdan anlaşılabilir, çünkü tekrar eden yanlış alarmlar gelmekte olan gerçek tehlikeye karşı tek bir hatadan bile daha önemsizdirler. Bu sistem çocuklar ya da sürünün diğer elemanları için de aktive olur (Curio, 1993).
“Özellikle önem verilmesi gereken bir husus ta, Öhman and Mineka (2001)’nın ‘korku modulü’ adını verdiği korkuyu öğrenmeyi ve ondan kaçmayı, kaçınmayı düzenleyen sistem ile önleme almaya yönelik güvenlik dürtüsü sistemi arasındaki farktır”.
Öhman and Mineka (2001. Fears, phobias, and preparedness: toward an evolved module of fear and fear learning. Psychological Review, 108, 483-522) potansiyel olarak felaket taşıyan olayların … bazı ince ipuçları ile haber verilebileceğini belirtirler. “Örneğin, dikkatli bir gözlemciye, vahşi bir saldırgan ses veya koku olarak varlığını belli edebilir. Bu tür ipuçları ile potansiyel ölümcül sonuçları arasındakı karşılıklı eşleşme, merkezi korku dürtüsünü koşullayabilir”.
“Korku modülüne karşıt olarak güvenlik dürtü sistemi ‘potansiyel olarak ölümcül’ sonuçları olan durumlarla gerçekten karşılaşmaya dayanmaz, fakat daha başka, ince, açık bir tehlike olmayan durumlardaki ‘gizli riskleri’ belirten ve koşullanmaya dayanmayan iç uyarılar ile çalışır. Bir başka ayrım da güvenlik-dürütülü davranışın kötü bir kokuyu savmak yerine bilgi edinme ve toplamaya yönelik olmasıdır”.
“Obsessive-Compulsive Disorder as a Disturbance of Security Motivation
Henry Szechtman, Erik Woody” makalesinden yapmış olduğum çok sayıda alıntı ve özet göstermektedir ki güvenlik dürtü sistemimiz korku sistemimizden bile daha karmaşık ve soyuttur. Ucu-açık olmak zorunluluğu, dinamik olarak risk duygusunun ayarlanması, cognitive olmayan bir durdurma mekanizması ve bildiğini hissetmenin yalnız duygusal değil bilinçaltı ile ilişkisi, potansiyel tehlikenin aynı zamanda hafıza ve cognitive olan bir tetikleme mekanizması içermesi obsesif-kompulsif düzensizlik için uygun bir alt yapı oluşturmaktadır.
“Affect and Processing Dynamics- Perceptual Fluency Enhances Evaluations” makalesinde Winkielman et all. İşleme kolaylığı(hızlı iletişim) pozitif değerlendirmeye, çabuk duygusal tepki almanın karar vermede olumlu etkisine işaret eder. Literatürde duygusal durumun düşünme üzerine etkisi ile ilgili bir çok makale var.
Duygusal durumumuz güvenlik sistemimizin çalışmasını da etkiler. “Compulsive Checking Behaviors in Generalized Anxiety Disorder, Alexander J. Schut, Louis G. Castonguay,
and Thomas D. Borkovec” makalesi “tasalanma ile genel tasalanma düzensizliği ve kompulsif davranışlar özellikle kompulsif kontrol etme arasında bir ilişki olduğunu” göstermektedir.
Büyük sistemlerde, askeri projelerde proje süreci çoğunlukla katılanları belirsizlik içinde bırakan uzun bekleme dönemleri içerir. Bu dönemlerin kişiler üzerinde yaptığı tasalanma etkisi kişilerin psikolojik durumları ve OKD’ye maruz kalmaları açısından yüksek riskler içerir. Aşırı stresin kişilerin tuvalete gitme gibi küçük yaşlarında koşullandıkları alışkanlıklarının bozulmasına neden olduğu kolaylıkla gözlenebilir… Bu durum OKD etkisinin büyük sistemler çalışanları açısından ne kadar hassas bir konu olabileceğini gösterir.
Sorun, kişinin kontrol ettiği şeyi kontrol etmiş olduğu sonucuna varamamasıdır. Teknik eğitimden gelen kişilerin, mühendislerin çok başvurdukları bir çare, kontrol sayısını arttırmak, kontrol türünü (ses, hareket vb) değiştirmek, konsantrasyonu arttırmak, daha çok dikkat toplamak, kontrol ettiğini aklında tutmaya çalışmak, kağıtlara not tutmak vb… Sonuçta bunların hepsi bir noktadan sonra işe yaramaz… Çünkü mühendis formasyon itibarı ile olayı cognitive olarak çözmeye çalışır.
Oysa tamamlanma, kapanma duygusunu veren, kontrol ettiğini bilme duygusudur, yani bir duygudur. Çok kızdığınız zaman nasıl sakinleşirsiniz? Kızdığınızı fark ederek. Çünkü duygular sabun köpüğü gibidir… Farkına bilinciniz ile vardığınız an fikre dönüşürler his olarak yok olurlar… İmdi, kontrol sırasında, aşırı dikkat toplama, özellikle ek kontroller değişkenler kullanma kontrol sürecinde bilinçsel-cognitive ağırlığı arttırdığı için siz tamamlanma – kapanma hissi uyandıran bilme duygusunu öldürmüş olursunuz ve kaçınılmaz olarak tekrar kontrol etme ihtiyacı duyarsınız, bir çevrim halinde bu böyle devam eder…
Bir diğer önemli noktada güvenlik dürtüsü sistemimizin hard-coded yani fiziki olarak gömülü, kendi içinde kapalı bir sistem olmasıdır. Zihnimiz, beynimiz bir çok fiziksel ya da fonsiyonel alt sistemden oluşmaktadır. Aşırı dikkat toplayarak çalışmaya alışmış büyük sistem mühendisleri ya da hayati işlerle uğraşan kişiler, dikkatlerini kontrol ettikleri şeye benzer şekilde yoğunlaştırırlarsa güvenlik dürtüsü sistemlerini devre dışı bırakırlar. Düşünme hızımız ve dikkat toplama oranımız beynimizin kullandığı alt sistemi seçmemizi sağlar. Uzun süre aşırı dikkat toplayarak çalışan kişilerin beyinlerinin otomatik prosessor seçme özellikleri bozulabilir. Bu durum bu kişileri OKD’ye karşı hassas duruma getirebilir. Kapıyı kilitlerken aşırı dikkat toplamak yerine biraz yavaş hareket edip hiçbir şey düşünmemeye çalışarak göz ucuyla anahtara bakmak yeterli olabilir örneğin. Ayrıca günlük yaşamdaki her detayı bir hava trafik kontrolü sisteminin saniyeler mertebesindeki hassaslığı ve apaçık kesin doğruluğu ile hatırlamamızı beklemek fazla olmaz mı?
Ülkemizde yeni oluşmakta olan büyük sistem kültürüne katkısı olması dileği ile.
Ali Rıza SARAL
NOT: OKD normal insanlarda da zaman zaman görülebilen bir rahatsızlıktır. Derinliği ve tekrar sıklığı zaman ile artarsa şizofrenik görünümler alacak kadar ciddi ruhsal rahtsızlıklara dönüşebilir. Eğer kendiliğinden düzelmiyorsa bir psikiyatriste gözükmekte fayda vardır. Büyük sistemlerde ya da kendine- başkalarına hayati risk taşıyan işlerde çalışan kişilerin çok seyrek olmayan aralarla düzenli olarak doktor kontrolünden geçmesi gerekir. Bazı psikolojik rahatsızlıkların tanısı günümüz teknolojisi ile iki yılın üzerinde sürebilmektedir. Bu nedenle ve doktorun hastayı tanıma süresini kısaltmak amacı ile yüksek risk altında çalışan kişilerin önceden kontrol altında olması gerekir.
Subscribe to:
Posts (Atom)